RDB和AOF機制
首先刑巧，我們必須清楚的一點喧兄，Redis是內存數(shù)據(jù)庫，如果不進行持久化啊楚，服務器在宕機或退出的時候吠冤，數(shù)據(jù)就會丟失，所以需要實現(xiàn)持久化恭理。
- RDB(Redis Database)通過快照的形式將數(shù)據(jù)保存到磁盤中拯辙。RDB的實現(xiàn)是先fork出一個子進程，在指定的時間間隔內將內存中的數(shù)據(jù)集快照寫入臨時文件中蚯斯，寫入成功后薄风，覆蓋最終的RDB文件，用二進制壓縮存儲拍嵌。默認文件名為dump.rdb遭赂。RDB也是Redis默認的持久化機制。
- AOF(Append Only-file)持久化的實現(xiàn)横辆，是將所有的寫命令都記錄下來撇他，以aof文件的形式進行記錄（在aof文件中，我們可以看到具體的命令）狈蚤，在redis啟動之后困肩，會讀取該文件，重新構建出內存中的數(shù)據(jù)脆侮，默認情況下AOF機制是關閉的锌畸，需要使用的時候需要進行配置。
Redis持久化的兩種方式：RDB與AOF（詳解）
Redis的數(shù)據(jù)結構有哪幾種?
- string（字符串）
- list（列表）
- hash（字典）
- set（集合）
- zset（有序集合）
Redis的過期鍵的刪除策略靖避？
對于過期鍵一般有三種刪除策略
- 定時刪除：在設置鍵的過期時間的同時潭枣，創(chuàng)建一個定時器(timer)比默，讓定時器在鍵的過期時間來臨時，立即執(zhí)行對鍵的刪除操作盆犁；
- 惰性刪除：放任鍵過期不管命咐，但是每次從鍵空間中獲取鍵時，都檢查取得的鍵是否過期谐岁，如果過期的話醋奠，就刪除該鍵；如果沒有過期伊佃，那就返回該鍵窜司；
- 定期刪除：每隔一段時間，程序就對數(shù)據(jù)庫進行一次檢查航揉，刪除里面的過期鍵例证。至于刪除多少過期鍵，以及要檢查多少個數(shù)據(jù)庫迷捧，則由算法決定织咧。
三種策略的優(yōu)缺比較：
- 定時刪除策略對內存是最友好的：通過使用定時器，定時刪除策略可以保證過期鍵會盡可能快地被刪除漠秋，并釋放過期鍵所占用的內存笙蒙；但另一方面，定時刪除策略的缺點是庆锦，他對CPU是最不友好的：在過期鍵比較多的情況下捅位，刪除過期鍵這一行為可能會占用相當一部分CPU時間，在內存不緊張但是CPU時間非常緊張的情況下搂抒，將CPU時間用在刪除和當前任務無關的過期鍵上艇搀，無疑會對服務器的響應時間和吞吐量造成影響；
- 惰性刪除策略對CPU時間來說是最友好的：程序只會在取出鍵時才對鍵進行過期檢查求晶，這可以保證刪除過期鍵的操作只會在非做不可的情況下進行焰雕；惰性刪除策略的缺點是，它對內存是最不友好的：如果一個鍵已經(jīng)過期芳杏，而這個鍵又仍然保留在數(shù)據(jù)庫中矩屁，那么只要這個過期鍵不被刪除，它所占用的內存就不會釋放爵赵；
- 定時刪除占用太多CPU時間吝秕，影響服務器的響應時間和吞吐量；惰性刪除浪費太多內存空幻，有內存泄漏的危險烁峭。定期刪除策略是前兩種策略的一種整合和折中：
1.定期刪除策略每隔一段時間執(zhí)行一次刪除過期鍵操作，并通過限制刪除操作執(zhí)行的時長和頻率來減少刪除操作對CPU時間的影響秕铛；
2.通過定期刪除過期鍵约郁，定期刪除策略有效地減少了因為過期鍵而帶來的內存浪費耘柱；
3.定期刪除策略的難點是確定刪除操作執(zhí)行的時長和頻率。
Redis線程模型棍现，單線程為什么快？
1.Redis線程模型镜遣？
多路I/O復用模型是利用 select己肮、poll、epoll 可以同時監(jiān)察多個流的 I/O 事件的能力悲关，在空閑的時候谎僻，會把當前線程阻塞掉，當有一個或多個流有 I/O 事件時寓辱，就從阻塞態(tài)中喚醒艘绍，于是程序就會輪詢一遍所有的流（epoll 是只輪詢那些真正發(fā)出了事件的流），并且只依次順序的處理就緒的流秫筏，這種做法就避免了大量的無用操作诱鞠。
這里“多路”指的是多個網(wǎng)絡連接，“復用”指的是復用同一個線程这敬。采用多路 I/O 復用技術可以讓單個線程高效的處理多個連接請求（盡量減少網(wǎng)絡 IO 的時間消耗）航夺，且 Redis 在內存中操作數(shù)據(jù)的速度非常快崔涂，也就是說內存內的操作不會成為影響Redis性能的瓶頸阳掐，主要由以上幾點造就了 Redis 具有很高的吞吐量。
2.Redis為什么這么快
- 完全基于內存冷蚂，絕大部分請求是純粹的內存操作缭保，非常快速蝙茶。數(shù)據(jù)存在內存中艺骂，類似于HashMap，HashMap的優(yōu)勢就是查找和操作的時間復雜度都是O(1)隆夯；
- 數(shù)據(jù)結構簡單彻亲，對數(shù)據(jù)操作也簡單，Redis中的數(shù)據(jù)結構是專門進行設計的吮廉；
- 采用單線程苞尝，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU宦芦，不用去考慮各種鎖的問題宙址，不存在加鎖釋放鎖操作，沒有因為可能出現(xiàn)死鎖而導致的性能消耗调卑；
- 使用多路I/O復用模型抡砂，非阻塞IO大咱；
- 使用底層模型不同，它們之間底層實現(xiàn)方式以及與客戶端之間通信的應用協(xié)議不一樣注益，Redis直接自己構建了VM 機制 碴巾，因為一般的系統(tǒng)調用系統(tǒng)函數(shù)的話，會浪費一定的時間去移動和請求丑搔；
3.為什么Redis是單線程的厦瓢？
官方FAQ表示，因為Redis是基于內存的操作啤月，CPU不是Redis的瓶頸煮仇，Redis的瓶頸最有可能是機器內存的大小或者網(wǎng)絡帶寬。既然單線程容易實現(xiàn)谎仲，而且CPU不會成為瓶頸浙垫，那就順理成章地采用單線程的方案了（畢竟采用多線程會有很多麻煩！）郑诺。
參考為什么說Redis是單線程的以及Redis為什么這么快夹姥！
緩存穿透 緩存擊穿 緩存雪崩
- 緩存穿透是指緩存和數(shù)據(jù)庫中都沒有的數(shù)據(jù)，而用戶不斷發(fā)起請求辙诞，如發(fā)起為id為“-1”的數(shù)據(jù)或id為特別大不存在的數(shù)據(jù)佃声。這時的用戶很可能是攻擊者，攻擊會導致數(shù)據(jù)庫壓力過大倘要。
- 緩存擊穿是指緩存中沒有但數(shù)據(jù)庫中有的數(shù)據(jù)（一般是緩存時間到期）圾亏，這時由于并發(fā)用戶特別多，同時讀緩存沒讀到數(shù)據(jù)封拧，又同時去數(shù)據(jù)庫去取數(shù)據(jù)志鹃，引起數(shù)據(jù)庫壓力瞬間增大，造成過大壓力
- 緩存雪崩是指緩存中數(shù)據(jù)大批量到過期時間泽西，而查詢數(shù)據(jù)量巨大曹铃，引起數(shù)據(jù)庫壓力過大甚至down機。和緩存擊穿不同的是捧杉， 緩存擊穿指并發(fā)查同一條數(shù)據(jù)陕见，緩存雪崩是不同數(shù)據(jù)都過期了，很多數(shù)據(jù)都查不到從而查數(shù)據(jù)庫味抖。
簡述redis事物實現(xiàn)评甜？
Redis事務的實現(xiàn)原理
Redis通過MULTI、EXEC仔涩、WATCH忍坷、DISCARD等命令來實現(xiàn)事務功能。主要有以下三個階段：
- 事務開始：MULTI命令的執(zhí)行，標識著一個事務的開始佩研。MULTI命令會將客戶端狀態(tài)的flags屬性中打開REDIS_MULTI標識來完成的柑肴。
- 命令入隊：當一個客戶端切換到事務狀態(tài)之后，服務器會根據(jù)這個客戶端發(fā)送來的命令來執(zhí)行不同的操作旬薯。如果客戶端發(fā)送的命令為MULTI晰骑、EXEC、WATCH绊序、DISCARD中的一個硕舆，立即執(zhí)行這個命令，否則將命令放入一個事務隊列里面政模，然后向客戶端返回QUEUED回復
- 事務執(zhí)行：當一個處于事務狀態(tài)的客戶端向服務器發(fā)送EXEC命令時，服務器會遍歷這個客戶端的事務隊列蚂会，執(zhí)行隊列中保存的所有命令淋样，最后將執(zhí)行完的結果全部返回給客戶端（每個命令對應一個返回）
- WATCH命令的實現(xiàn)：WATCH命令是一個樂觀鎖，它可以在EXEC命令執(zhí)行之前胁住，監(jiān)視任意數(shù)量的數(shù)據(jù)庫鍵趁猴，并在執(zhí)行EXEC命令時，檢查被監(jiān)視的鍵是否至少有一個已經(jīng)被修改彪见，如果有儡司，服務器拒絕執(zhí)行事務，向客戶端返回代表事務執(zhí)行失敗的空回復
Redis事務的ACID性質
- 原子性：對于Redis的事務功能來說余指，事務隊列中的命令要么就全部執(zhí)行捕犬，要么就一個都不執(zhí)行，但是Redis的事務是不支持回滾操作的酵镜；
-
一致性：Redis通過謹慎的錯誤檢測和簡單的設計保證事務的一致性碉碉。Redis事務可能出錯的地方以及解決方案：
1.入隊錯誤：如果一個事務在入隊命令的過程中發(fā)現(xiàn)命令不存在或者命令格式不正確，Redis將拒絕執(zhí)行這個事務淮韭；
2.執(zhí)行錯誤：事務在執(zhí)行的過程中發(fā)生錯誤的命令會被服務器識別出來垢粮，并進行相應的錯誤處理，所以這些出錯的命令不會對數(shù)據(jù)庫做任何修改靠粪，也不會對事務的一致性產生任何影響蜡吧；
3.服務器停機：如果Redis服務器在執(zhí)行事務的過程中停機，且服務器運行在任意模式下（無持久化的內存模式占键、RDB模式或者AOF模式）昔善，事務執(zhí)行中途發(fā)生的停機都不會影響數(shù)據(jù)庫的一致性； -
隔離性：Redis使用單線程的方式執(zhí)行事務畔乙，并且服務器保證在執(zhí)行事務期間不會對事務進行中斷耀鸦，因此，Redis的事務總是串行的方式運行，并且事務總是具有隔離性的袖订；
4.耐久性：當服務器運行在AOF持久化模式下氮帐，并且appendfsync選項的值是always時，事務是具有耐久性的洛姑，其他情況不具有耐久性;
Redis集群方案上沐？
Redis主從復制的核心原理？
1.什么是主從復制楞艾？
主從復制参咙，是指將一臺Redis服務器的數(shù)據(jù)，復制到其他的Redis服務器硫眯。前者稱為主節(jié)點(master)蕴侧，后者稱為從節(jié)點(slave)；
2.為什么要主從復制两入？
- 數(shù)據(jù)冗余：主從復制實現(xiàn)了數(shù)據(jù)的熱備份净宵，是持久化之外的一種數(shù)據(jù)冗余方式。
- 故障恢復：當主節(jié)點出現(xiàn)問題時裹纳，可以由從節(jié)點提供服務择葡，實現(xiàn)快速的故障恢復；實際上是一種服務的冗余剃氧。
- 負載均衡：在主從復制的基礎上敏储，配合讀寫分離，可以由主節(jié)點提供寫服務朋鞍，由從節(jié)點提供讀服務（即寫Redis數(shù)據(jù)時應用連接主節(jié)點已添，讀Redis數(shù)據(jù)時應用連接從節(jié)點），分擔服務器負載滥酥；尤其是在寫少讀多的場景下酝碳，通過多個從節(jié)點分擔讀負載，可以大大提高Redis服務器的并發(fā)量恨狈。
- 高可用基石：主從復制還是哨兵和集群能夠實施的基礎疏哗，因此說主從復制是Redis高可用的基礎。
3.主從復制可能會造成的問題禾怠？
4.主從復制的核心原理返奉？
CAP理論 BASE理論
負載均衡算法、類型吗氏？
負載均衡（Load balancing）是一種計算機技術芽偏，用來在多個計算機（計算機集群）、網(wǎng)絡連接弦讽、CPU污尉、磁盤驅動器或其他資源中分配負載膀哲，以達到最優(yōu)化資源使用、最大化吞吐率被碗、最小化響應時間驳阎、同時避免過載的目的木柬。 使用帶有負載均衡的多個服務器組件疯特，取代單一的組件荆姆，可以通過冗余提高可靠性。負載均衡服務通常是由專用軟件和硬件來完成焚志。 主要作用是將大量作業(yè)合理地分攤到多個操作單元上進行執(zhí)行衣迷，用于解決互聯(lián)網(wǎng)架構中的高并發(fā)和高可用的問題。
類型
- 輪詢法：每個請求按時間順序逐一分配到不同的后端服務器酱酬，如果服務器down掉壶谒，能自動剔除。
- weight（權重）:指定輪詢幾率膳沽，weight和訪問比率成正比汗菜，用于服務器性能不均的情況。
- ip_hash：每個請求按訪問ip的hash結果分配贵少，這樣每個訪客固定訪問一個服務器呵俏，可以解決session的問題堆缘。
- fair（第三方）：按服務器的響應時間來分配請求滔灶，響應時間短的優(yōu)先分配。
- url_hash（第三方）：按訪問url的hash結果來分配請求吼肥，使每個url定向到同一個服務器录平，服務器為緩存時比較有效。在upstream中加入hash語句缀皱，server語句中不能寫入weight等其他的參數(shù)斗这，hash_method使用的是hash算法。
分布式架構下啤斗，session共享有什么方案表箭？
簡述你對RPC免钻、RMI的理解？
分布式id的生成方案崔拥？
- 數(shù)據(jù)庫自增長序列或字段
- UUID
- UUID的變種：為了解決UUID不可讀极舔，可以使用UUID to Int64的方法。
- Redis生成ID
- Twitter的snowflake算法
- 利用zookeeper生成唯一ID
- MongoDB的ObjectId
- TiDB的主鍵
分布式鎖解決方案链瓦？
- 數(shù)據(jù)庫
- redis
- zookeeper
分布式事務解決方案拆魏？
如何實現(xiàn)接口冪等性？
冪等性說的是：如何防止接口的重復無效請求。
對于一個接口而言渤刃，無論調用了多少次拥峦，最終得到的結果都是一樣的。
四種解決方法：
前端攔截溪掀。不安全事镣，可能被專業(yè)人士修改，跳過該過程揪胃。
使用數(shù)據(jù)庫實現(xiàn)冪等性
使用 JVM 鎖實現(xiàn)冪等性璃哟。缺點：只能引用于單機環(huán)境
使用分布式鎖實現(xiàn)冪等性。通常使用redis或者zookeeper實現(xiàn)分布式鎖喊递。保證分布式鎖的key是業(yè)務id的唯一標識随闪。
