妈妈再也不担心我面试被 Redis 问得脸都绿了
??點擊上方?好好學java?，選擇?星標?公眾號
重磅資訊、干貨，第一時間送達 今日推薦：牛人 20000 字的 Spring Cloud 總結，太硬核了~Redis 作為一個開源的，高級的鍵值存儲和一個適用的解決方案，已經越來越在構建 「高性能」、「可擴展」 的 Web 應用上發揮著舉足輕重的作用。
當今互聯網技術架構中 Redis 已然成為了應用得最廣泛的中間件之一，它也是中高級后端工程 技術面試 中面試官最喜歡問的工程技能之一，不僅僅要求著我們對 基本的使用 進行掌握，更要深層次地理解 Redis 內部實現 的細節原理。
熟練掌握 Redis，甚至可以毫不夸張地說已經半只腳踏入心儀的公司了。下面我們一起來盤點回顧一下 Redis 的面試經典問題，就不要再被面試官問得 臉都綠了 呀！
Ps：我把 重要的知識點 都做成了 圖片，希望各位 "用餐愉快"。(不錯記得付餐費.. 點個贊留個言..)
一、基礎篇
■什么是 Redis ？
先解釋 Redis 基本概念
Redis (Remote Dictionary Server) 是一個使用 C 語言 編寫的，開源的 (BSD許可) 高性能 非關系型 (NoSQL) 的 鍵值對數據庫。
簡單提一下 Redis 數據結構
Redis 可以存儲 鍵 和 不同類型數據結構值 之間的映射關系。鍵的類型只能是字符串，而值除了支持最 基礎的五種數據類型 外，還支持一些 高級數據類型：
“一定要說出一些高級數據結構 (當然你自己也要了解.. 下面會說到的別擔心)，這樣面試官的眼睛才會亮。
Redis 小總結
與傳統數據庫不同的是 Redis 的數據是 存在內存 中的，所以 讀寫速度 非常 快，因此 Redis 被廣泛應用于 緩存 方向，每秒可以處理超過 10 萬次讀寫操作，是已知性能最快的 Key-Value 數據庫。另外，Redis 也經常用來做 分布式鎖。
除此之外，Redis 支持事務 、持久化、LUA腳本、LRU驅動事件、多種集群方案。
■Redis 優缺點
優點
讀寫性能優異， Redis能讀的速度是 110000 次/s，寫的速度是 81000 次/s。
支持數據持久化，支持 AOF 和 RDB 兩種持久化方式。
支持事務，Redis 的所有操作都是原子性的，同時 Redis 還支持對幾個操作合并后的原子性執行。
數據結構豐富，除了支持 string 類型的 value 外還支持 hash、set、zset、list 等數據結構。
支持主從復制，主機會自動將數據同步到從機，可以進行讀寫分離。
缺點
數據庫 容量受到物理內存的限制，不能用作海量數據的高性能讀寫，因此 Redis 適合的場景主要局限在較小數據量的高性能操作和運算上。
Redis 不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部分讀寫請求失敗，需要等待機器重啟或者手動切換前端的 IP 才能恢復。
主機宕機，宕機前有部分數據未能及時同步到從機，切換 IP 后還會引入數據不一致的問題，降低了 系統的可用性。
Redis 較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜。為避免這一問題，運維人員在系統上線時必須確保有足夠的空間，這對資源造成了很大的浪費。
■為什么要用緩存？為什么使用 Redis？
提一下現在 Web 應用的現狀
在日常的 Web 應用對數據庫的訪問中，讀操作的次數遠超寫操作，比例大概在 1:9 到 3:7，所以需要讀的可能性是比寫的可能大得多的。當我們使用 SQL 語句去數據庫進行讀寫操作時，數據庫就會 去磁盤把對應的數據索引取回來，這是一個相對較慢的過程。
使用 Redis or 使用緩存帶來的優勢
如果我們把數據放在 Redis 中，也就是直接放在內存之中，讓服務端直接去讀取內存中的數據，那么這樣 速度 明顯就會快上不少 (高性能)，并且會 極大減小數據庫的壓力 (特別是在高并發情況下)。
“記得是 兩個角度 啊.. 高性能 和 高并發..
也要提一下使用緩存的考慮
但是使用內存進行數據存儲開銷也是比較大的，限于成本 的原因，一般我們只是使用 Redis 存儲一些 常用和主要的數據，比如用戶登錄的信息等。
一般而言在使用 Redis 進行存儲的時候，我們需要從以下幾個方面來考慮：
業務數據常用嗎？命中率如何？ 如果命中率很低，就沒有必要寫入緩存；
該業務數據是讀操作多，還是寫操作多？ 如果寫操作多，頻繁需要寫入數據庫，也沒有必要使用緩存；
業務數據大小如何？ 如果要存儲幾百兆字節的文件，會給緩存帶來很大的壓力，這樣也沒有必要；
在考慮了這些問題之后，如果覺得有必要使用緩存，那么就使用它！
■使用緩存會出現什么問題？
一般來說有如下幾個問題，回答思路遵照 是什么 → 為什么 → 怎么解決：
緩存雪崩問題；
緩存穿透問題；
緩存和數據庫雙寫一致性問題；
緩存雪崩問題
另外對于 "Redis 掛掉了，請求全部走數據庫" 這樣的情況，我們還可以有如下的思路：
事發前：實現 Redis 的高可用(主從架構 + Sentinel 或者 Redis Cluster)，盡量避免 Redis 掛掉這種情況發生。
事發中：萬一 Redis 真的掛了，我們可以設置本地緩存(ehcache) + 限流(hystrix)，盡量避免我們的數據庫被干掉(起碼能保證我們的服務還是能正常工作的)
事發后：Redis 持久化，重啟后自動從磁盤上加載數據，快速恢復緩存數據。
緩存穿透問題
緩存與數據庫雙寫一致問題
雙寫一致性上圖還是稍微粗糙了些，你還需要知道兩種方案 (先操作數據庫和先操作緩存) 分別都有什么優勢和對應的問題，這里不作贅述，可以參考一下下方的文章，寫得非常詳細。
“面試前必須要知道的Redis面試題 | Java3y - https://mp.weixin.qq.com/s/3Fmv7h5p2QDtLxc9n1dp5A
■Redis 為什么早期版本選擇單線程？
官方解釋
因為 Redis 是基于內存的操作，CPU 不是 Redis 的瓶頸，Redis 的瓶頸最有可能是 機器內存的大小 或者 網絡帶寬。既然單線程容易實現，而且 CPU 不會成為瓶頸，那就順理成章地采用單線程的方案了。
簡單總結一下
使用單線程模型能帶來更好的 可維護性，方便開發和調試；
使用單線程模型也能 并發 的處理客戶端的請求；(I/O 多路復用機制)
Redis 服務中運行的絕大多數操作的 性能瓶頸都不是 CPU；
強烈推薦 各位親看一下這篇文章：
為什么 Redis 選擇單線程模型 · Why's THE Design? - https://draveness.me/whys-the-design-redis-single-thread
■Redis 為什么這么快？
簡單總結：
純內存操作：讀取不需要進行磁盤 I/O，所以比傳統數據庫要快上不少；(但不要有誤區說磁盤就一定慢，例如 Kafka 就是使用磁盤順序讀取但仍然較快)
單線程，無鎖競爭：這保證了沒有線程的上下文切換，不會因為多線程的一些操作而降低性能；
多路 I/O 復用模型，非阻塞 I/O：采用多路 I/O 復用技術可以讓單個線程高效的處理多個網絡連接請求（盡量減少網絡 IO 的時間消耗）；
高效的數據結構，加上底層做了大量優化：Redis 對于底層的數據結構和內存占用做了大量的優化，例如不同長度的字符串使用不同的結構體表示，HyperLogLog 的密集型存儲結構等等..
二、數據結構篇
■簡述一下 Redis 常用數據結構及實現？
首先在 Redis 內部會使用一個 RedisObject 對象來表示所有的 key 和 value：
其次 Redis 為了 平衡空間和時間效率，針對 value 的具體類型在底層會采用不同的數據結構來實現，下圖展示了他們之間的映射關系：(好像亂糟糟的，但至少能看清楚..)
■Redis 的 SDS 和 C 中字符串相比有什么優勢？
先簡單總結一下
C 語言使用了一個長度為 N+1 的字符數組來表示長度為 N 的字符串，并且字符數組最后一個元素總是 \0，這種簡單的字符串表示方式 不符合 Redis 對字符串在安全性、效率以及功能方面的要求。
再來說 C 語言字符串的問題
這樣簡單的數據結構可能會造成以下一些問題：
獲取字符串長度為 O(N) 級別的操作 → 因為 C 不保存數組的長度，每次都需要遍歷一遍整個數組；
不能很好的杜絕 緩沖區溢出/內存泄漏 的問題 → 跟上述問題原因一樣，如果執行拼接 or 縮短字符串的操作，如果操作不當就很容易造成上述問題；
C 字符串 只能保存文本數據 → 因為 C 語言中的字符串必須符合某種編碼（比如 ASCII），例如中間出現的 '\0' 可能會被判定為提前結束的字符串而識別不了；
Redis 如何解決的 | SDS 的優勢
如果去看 Redis 的源碼 sds.h/sdshdr 文件，你會看到 SDS 完整的實現細節，這里簡單來說一下 Redis 如何解決的：
多增加 len 表示當前字符串的長度：這樣就可以直接獲取長度了，復雜度 O(1)；
自動擴展空間：當 SDS 需要對字符串進行修改時，首先借助于 len 和 alloc 檢查空間是否滿足修改所需的要求，如果空間不夠的話，SDS 會自動擴展空間，避免了像 C 字符串操作中的覆蓋情況；
有效降低內存分配次數：C 字符串在涉及增加或者清除操作時會改變底層數組的大小造成重新分配，SDS 使用了 空間預分配 和 惰性空間釋放 機制，簡單理解就是每次在擴展時是成倍的多分配的，在縮容是也是先留著并不正式歸還給 OS；
二進制安全：C 語言字符串只能保存 ascii 碼，對于圖片、音頻等信息無法保存，SDS 是二進制安全的，寫入什么讀取就是什么，不做任何過濾和限制；
■字典是如何實現的？Rehash 了解嗎？
先總體聊一下 Redis 中的字典
字典是 Redis 服務器中出現最為頻繁的復合型數據結構。除了 hash 結構的數據會用到字典外，整個 Redis 數據庫的所有 key 和 value 也組成了一個 全局字典，還有帶過期時間的 key 也是一個字典。(存儲在 RedisDb 數據結構中)
說明字典內部結構和 rehash
Redis 中的字典相當于 Java 中的 HashMap，內部實現也差不多類似，都是通過 "數組 + 鏈表" 的 鏈地址法 來解決部分 哈希沖突，同時這樣的結構也吸收了兩種不同數據結構的優點。
字典結構內部包含 兩個 hashtable，通常情況下只有一個 hashtable 有值，但是在字典擴容縮容時，需要分配新的 hashtable，然后進行 漸進式搬遷 (rehash)，這時候兩個 hashtable 分別存儲舊的和新的 hashtable，待搬遷結束后，舊的將被刪除，新的 hashtable 取而代之。
擴縮容的條件
正常情況下，當 hash 表中 元素的個數等于第一維數組的長度時，就會開始擴容，擴容的新數組是 原數組大小的 2 倍。不過如果 Redis 正在做 bgsave(持久化命令)，為了減少內存也得過多分離，Redis 盡量不去擴容，但是如果 hash 表非常滿了，達到了第一維數組長度的 5 倍了，這個時候就會 強制擴容。
當 hash 表因為元素逐漸被刪除變得越來越稀疏時，Redis 會對 hash 表進行縮容來減少 hash 表的第一維數組空間占用。所用的條件是 元素個數低于數組長度的 10%，縮容不會考慮 Redis 是否在做 bgsave。
■跳躍表是如何實現的？原理？
“這是 Redis 中比較重要的一個數據結構，建議閱讀 之前寫過的文章，里面詳細介紹了原理和一些細節：
Redis(2)——跳躍表
■HyperLogLog 有了解嗎？
“建議閱讀 之前的系列文章：
Redis(4)——神奇的HyperLoglog解決統計問題
■布隆過濾器有了解嗎？
“建議閱讀 之前的系列文章：
Redis(5)——億級數據過濾和布隆過濾器
■GeoHash 了解嗎？
“建議閱讀 之前的系列文章：
Redis(6)——GeoHash查找附近的人
■壓縮列表了解嗎？
這是 Redis 為了節約內存 而使用的一種數據結構，zset 和 hash 容器對象會在元素個數較少的時候，采用壓縮列表（ziplist）進行存儲。壓縮列表是 一塊連續的內存空間，元素之間緊挨著存儲，沒有任何冗余空隙。
“因為之前自己也沒有學習過，所以找了一篇比較好比較容易理解的文章：
圖解Redis之數據結構篇——壓縮列表 - https://mp.weixin.qq.com/s/nba0FUEAVRs0vi24KUoyQg
這一篇稍微底層稍微硬核一點：http://www.web-lovers.com/redis-source-ziplist.html
■快速列表 quicklist 了解嗎？
Redis 早期版本存儲 list 列表數據結構使用的是壓縮列表 ziplist 和普通的雙向鏈表 linkedlist，也就是說當元素少時使用 ziplist，當元素多時用 linkedlist。但考慮到鏈表的附加空間相對較高，prev 和 next 指針就要占去 16 個字節（64 位操作系統占用 8 個字節），另外每個節點的內存都是單獨分配，會家具內存的碎片化，影響內存管理效率。
后來 Redis 新版本（3.2）對列表數據結構進行了改造，使用 quicklist 代替了 ziplist 和 linkedlist。
“同上..建議閱讀一下以下的文章：
Redis列表list 底層原理 - https://zhuanlan.zhihu.com/p/102422311
■Stream 結構有了解嗎？
Redis Stream 從概念上來說，就像是一個 僅追加內容 的 消息鏈表，把所有加入的消息都一個一個串起來，每個消息都有一個唯一的 ID 和內容，這很簡單，讓它復雜的是從 Kafka 借鑒的另一種概念：消費者組(Consumer Group) (思路一致，實現不同)：
上圖就展示了一個典型的 Stream 結構。每個 Stream 都有唯一的名稱，它就是 Redis 的 key，在我們首次使用 xadd 指令追加消息時自動創建。我們對圖中的一些概念做一下解釋：
Consumer Group：消費者組，可以簡單看成記錄流狀態的一種數據結構。消費者既可以選擇使用 XREAD 命令進行 獨立消費，也可以多個消費者同時加入一個消費者組進行 組內消費。同一個消費者組內的消費者共享所有的 Stream 信息，同一條消息只會有一個消費者消費到，這樣就可以應用在分布式的應用場景中來保證消息的唯一性。
last_delivered_id：用來表示消費者組消費在 Stream 上 消費位置 的游標信息。每個消費者組都有一個 Stream 內 唯一的名稱，消費者組不會自動創建，需要使用 XGROUP CREATE 指令來顯式創建，并且需要指定從哪一個消息 ID 開始消費，用來初始化 last_delivered_id 這個變量。
pending_ids：每個消費者內部都有的一個狀態變量，用來表示 已經 被客戶端 獲取，但是 還沒有 ack 的消息。記錄的目的是為了 保證客戶端至少消費了消息一次，而不會在網絡傳輸的中途丟失而沒有對消息進行處理。如果客戶端沒有 ack，那么這個變量里面的消息 ID 就會越來越多，一旦某個消息被 ack，它就會對應開始減少。這個變量也被 Redis 官方稱為 PEL (Pending Entries List)。
Stream 消息太多怎么辦？
很容易想到，要是消息積累太多，Stream 的鏈表豈不是很長，內容會不會爆掉就是個問題了。xdel 指令又不會刪除消息，它只是給消息做了個標志位。
Redis 自然考慮到了這一點，所以它提供了一個定長 Stream 功能。在 xadd 的指令提供一個定長長度 maxlen，就可以將老的消息干掉，確保最多不超過指定長度，使用起來也很簡單：
> XADD mystream MAXLEN 2 * value 1 1526654998691-0 > XADD mystream MAXLEN 2 * value 2 1526654999635-0 > XADD mystream MAXLEN 2 * value 3 1526655000369-0 > XLEN mystream (integer) 2 > XRANGE mystream - + 1) 1) 1526654999635-02) 1) "value"2) "2" 2) 1) 1526655000369-02) 1) "value"2) "3"如果使用 MAXLEN 選項，當 Stream 的達到指定長度后，老的消息會自動被淘汰掉，因此 Stream 的大小是恒定的。目前還沒有選項讓 Stream 只保留給定數量的條目，因為為了一致地運行，這樣的命令必須在很長一段時間內阻塞以淘汰消息。(例如在添加數據的高峰期間，你不得不長暫停來淘汰舊消息和添加新的消息)
另外使用 MAXLEN 選項的花銷是很大的，Stream 為了節省內存空間，采用了一種特殊的結構表示，而這種結構的調整是需要額外的花銷的。所以我們可以使用一種帶有 ~ 的特殊命令：
XADD mystream MAXLEN ~ 1000 * ... entry fields here ...它會基于當前的結構合理地對節點執行裁剪，來保證至少會有 1000 條數據，可能是 1010 也可能是 1030。
PEL 是如何避免消息丟失的？
在客戶端消費者讀取 Stream 消息時，Redis 服務器將消息回復給客戶端的過程中，客戶端突然斷開了連接，消息就丟失了。但是 PEL 里已經保存了發出去的消息 ID，待客戶端重新連上之后，可以再次收到 PEL 中的消息 ID 列表。不過此時 xreadgroup 的起始消息 ID 不能為參數 > ，而必須是任意有效的消息 ID，一般將參數設為 0-0，表示讀取所有的 PEL 消息以及自 last_delivered_id 之后的新消息。
和 Kafka 對比起來呢？
Redis 基于內存存儲，這意味著它會比基于磁盤的 Kafka 快上一些，也意味著使用 Redis 我們 不能長時間存儲大量數據。不過如果您想以 最小延遲 實時處理消息的話，您可以考慮 Redis，但是如果 消息很大并且應該重用數據 的話，則應該首先考慮使用 Kafka。
另外從某些角度來說，Redis Stream 也更適用于小型、廉價的應用程序，因為 Kafka 相對來說更難配置一些。
“推薦閱讀 之前的系列文章，里面 也對 Pub/ Sub 做了詳細的描述：
Redis(8)——發布/訂閱與Stream
三、持久化篇
■什么是持久化？
先簡單談一談是什么
Redis 的數據 全部存儲 在 內存 中，如果 突然宕機，數據就會全部丟失，因此必須有一套機制來保證 Redis 的數據不會因為故障而丟失，這種機制就是 Redis 的 持久化機制，它會將內存中的數據庫狀態 保存到磁盤 中。
解釋一下持久化發生了什么
我們來稍微考慮一下 Redis 作為一個 "內存數據庫" 要做的關于持久化的事情。通常來說，從客戶端發起請求開始，到服務器真實地寫入磁盤，需要發生如下幾件事情：
詳細版 的文字描述大概就是下面這樣：
客戶端向數據庫 發送寫命令 (數據在客戶端的內存中)
數據庫 接收 到客戶端的 寫請求 (數據在服務器的內存中)
數據庫 調用系統 API 將數據寫入磁盤 (數據在內核緩沖區中)
操作系統將 寫緩沖區 傳輸到 磁盤控控制器 (數據在磁盤緩存中)
操作系統的磁盤控制器將數據 寫入實際的物理媒介 中 (數據在磁盤中)
分析如何保證持久化安全
如果我們故障僅僅涉及到 軟件層面 (該進程被管理員終止或程序崩潰) 并且沒有接觸到內核，那么在 上述步驟 3 成功返回之后，我們就認為成功了。即使進程崩潰，操作系統仍然會幫助我們把數據正確地寫入磁盤。
如果我們考慮 停電/ 火災 等 更具災難性 的事情，那么只有在完成了第 5 步之后，才是安全的。
機房”火了“所以我們可以總結得出數據安全最重要的階段是：步驟三、四、五，即：
數據庫軟件調用寫操作將用戶空間的緩沖區轉移到內核緩沖區的頻率是多少？
內核多久從緩沖區取數據刷新到磁盤控制器？
磁盤控制器多久把數據寫入物理媒介一次？
注意： 如果真的發生災難性的事件，我們可以從上圖的過程中看到，任何一步都可能被意外打斷丟失，所以只能 盡可能地保證 數據的安全，這對于所有數據庫來說都是一樣的。
我們從 第三步 開始。Linux 系統提供了清晰、易用的用于操作文件的 POSIX file API，20 多年過去，仍然還有很多人對于這一套 API 的設計津津樂道，我想其中一個原因就是因為你光從 API 的命名就能夠很清晰地知道這一套 API 的用途：
int open(const char *path, int oflag, .../*,mode_t mode */); int close (int filedes);int remove( const char *fname ); ssize_t write(int fildes, const void *buf, size_t nbyte); ssize_t read(int fildes, void *buf, size_t nbyte);參考自：API 設計最佳實踐的思考 - https://www.cnblogs.com/yuanjiangw/p/10846560.html
所以，我們有很好的可用的 API 來完成 第三步，但是對于成功返回之前，我們對系統調用花費的時間沒有太多的控制權。
然后我們來說說 第四步。我們知道，除了早期對電腦特別了解那幫人 (操作系統就這幫人搞的)，實際的物理硬件都不是我們能夠 直接操作 的，都是通過 操作系統調用 來達到目的的。為了防止過慢的 I/O 操作拖慢整個系統的運行，操作系統層面做了很多的努力，譬如說 上述第四步 提到的 寫緩沖區，并不是所有的寫操作都會被立即寫入磁盤，而是要先經過一個緩沖區，默認情況下，Linux 將在 30 秒 后實際提交寫入。
但是很明顯，30 秒 并不是 Redis 能夠承受的，這意味著，如果發生故障，那么最近 30 秒內寫入的所有數據都可能會丟失。幸好 PROSIX API 提供了另一個解決方案：fsync，該命令會 強制 內核將 緩沖區 寫入 磁盤，但這是一個非常消耗性能的操作，每次調用都會 阻塞等待 直到設備報告 IO 完成，所以一般在生產環境的服務器中，Redis 通常是每隔 1s 左右執行一次 fsync 操作。
到目前為止，我們了解到了如何控制 第三步 和 第四步，但是對于 第五步，我們 完全無法控制。也許一些內核實現將試圖告訴驅動實際提交物理介質上的數據，或者控制器可能會為了提高速度而重新排序寫操作，不會盡快將數據真正寫到磁盤上，而是會等待幾個多毫秒。這完全是我們無法控制的。
“普通人簡單說一下第一條就過了，如果你詳細地對后面兩方面 侃侃而談，那面試官就會對你另眼相看了。
■Redis 中的兩種持久化方式？
方式一：快照
Redis 快照 是最簡單的 Redis 持久性模式。當滿足特定條件時，它將生成數據集的時間點快照，例如，如果先前的快照是在 2 分鐘前創建的，并且現在已經至少有 100 次新寫入，則將創建一個新的快照。此條件可以由用戶配置 Redis 實例來控制，也可以在運行時修改而無需重新啟動服務器。快照作為包含整個數據集的單個 .rdb 文件生成。
方式二：AOF
快照不是很持久。如果運行 Redis 的計算機停止運行，電源線出現故障或者您 kill -9 的實例意外發生，則寫入 Redis 的最新數據將丟失。盡管這對于某些應用程序可能不是什么大問題，但有些使用案例具有充分的耐用性，在這些情況下，快照并不是可行的選擇。
AOF(Append Only File - 僅追加文件) 它的工作方式非常簡單：每次執行 修改內存 中數據集的寫操作時，都會 記錄 該操作。假設 AOF 日志記錄了自 Redis 實例創建以來 所有的修改性指令序列，那么就可以通過對一個空的 Redis 實例 順序執行所有的指令，也就是 「重放」，來恢復 Redis 當前實例的內存數據結構的狀態。
Redis 4.0 的混合持久化
重啟 Redis 時，我們很少使用 rdb 來恢復內存狀態，因為會丟失大量數據。我們通常使用 AOF 日志重放，但是重放 AOF 日志性能相對 rdb 來說要慢很多，這樣在 Redis 實例很大的情況下，啟動需要花費很長的時間。
Redis 4.0 為了解決這個問題，帶來了一個新的持久化選項——混合持久化。將 rdb 文件的內容和增量的 AOF 日志文件存在一起。這里的 AOF 日志不再是全量的日志，而是 自持久化開始到持久化結束 的這段時間發生的增量 AOF 日志，通常這部分 AOF 日志很小：
于是在 Redis 重啟的時候，可以先加載 rdb 的內容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重啟效率因此大幅得到提升。
“關于兩種持久化方式的更多細節 (原理) 可以參考：
Redis(7)——持久化【一文了解】
■RDB 和 AOF 各自有什么優缺點？
RDB | 優點
只有一個文件 dump.rdb，方便持久化。
容災性好，一個文件可以保存到安全的磁盤。
性能最大化，fork 子進程來完成寫操作，讓主進程繼續處理命令，所以使 IO 最大化。使用單獨子進程來進行持久化，主進程不會進行任何 IO 操作，保證了 Redis 的高性能
相對于數據集大時，比 AOF 的 啟動效率 更高。
RDB | 缺點
數據安全性低。RDB 是間隔一段時間進行持久化，如果持久化之間 Redis 發生故障，會發生數據丟失。所以這種方式更適合數據要求不嚴謹的時候；
AOF | 優點
數據安全，aof 持久化可以配置 appendfsync 屬性，有 always，每進行一次命令操作就記錄到 aof 文件中一次。
通過 append 模式寫文件，即使中途服務器宕機，可以通過 redis-check-aof 工具解決數據一致性問題。
AOF 機制的 rewrite 模式。AOF 文件沒被 rewrite 之前（文件過大時會對命令 進行合并重寫），可以刪除其中的某些命令（比如誤操作的 flushall）
AOF | 缺點
AOF 文件比 RDB 文件大，且 恢復速度慢。
數據集大 的時候，比 rdb 啟動效率低。
■兩種方式如何選擇？
一般來說， 如果想達到足以媲美 PostgreSQL 的 數據安全性，你應該 同時使用兩種持久化功能。在這種情況下，當 Redis 重啟的時候會優先載入 AOF 文件來恢復原始的數據，因為在通常情況下 AOF 文件保存的數據集要比 RDB 文件保存的數據集要完整。
如果你非常關心你的數據， 但仍然 可以承受數分鐘以內的數據丟失，那么你可以 只使用 RDB 持久化。
有很多用戶都只使用 AOF 持久化，但并不推薦這種方式，因為定時生成 RDB 快照（snapshot）非常便于進行數據庫備份， 并且 RDB 恢復數據集的速度也要比 AOF 恢復的速度要快，除此之外，使用 RDB 還可以避免 AOF 程序的 bug。
如果你只希望你的數據在服務器運行的時候存在，你也可以不使用任何持久化方式。
■Redis 的數據恢復
Redis 的數據恢復有著如下的優先級：
如果只配置 AOF ，重啟時加載 AOF 文件恢復數據；
如果同時配置了 RDB 和 AOF ，啟動只加載 AOF 文件恢復數據；
如果只配置 RDB，啟動將加載 dump 文件恢復數據。
拷貝 AOF 文件到 Redis 的數據目錄，啟動 redis-server AOF 的數據恢復過程：Redis 虛擬一個客戶端，讀取 AOF 文件恢復 Redis 命令和參數，然后執行命令從而恢復數據，這些過程主要在 loadAppendOnlyFile() 中實現。
拷貝 RDB 文件到 Redis 的數據目錄，啟動 redis-server 即可，因為 RDB 文件和重啟前保存的是真實數據而不是命令狀態和參數。
四、集群篇
■主從同步了解嗎？
主從復制，是指將一臺 Redis 服務器的數據，復制到其他的 Redis 服務器。前者稱為 主節點(master)，后者稱為 從節點(slave)。且數據的復制是 單向 的，只能由主節點到從節點。Redis 主從復制支持 主從同步 和 從從同步 兩種，后者是 Redis 后續版本新增的功能，以減輕主節點的同步負擔。
主從復制主要的作用
數據冗余： 主從復制實現了數據的熱備份，是持久化之外的一種數據冗余方式。
故障恢復： 當主節點出現問題時，可以由從節點提供服務，實現快速的故障恢復 (實際上是一種服務的冗余)。
負載均衡： 在主從復制的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務 （即寫 Redis 數據時應用連接主節點，讀 Redis 數據時應用連接從節點），分擔服務器負載。尤其是在寫少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高 Redis 服務器的并發量。
高可用基石： 除了上述作用以外，主從復制還是哨兵和集群能夠實施的 基礎，因此說主從復制是 Redis 高可用的基礎。
實現原理
為了節省篇幅，我把主要的步驟都 濃縮 在了上圖中，其實也可以 簡化成三個階段：準備階段-數據同步階段-命令傳播階段。
“更多細節 推薦閱讀 之前的系列文章，不僅有原理講解，還有實戰環節：
Redis(9)——史上最強【集群】入門實踐教程
■哨兵模式了解嗎？
上圖 展示了一個典型的哨兵架構圖，它由兩部分組成，哨兵節點和數據節點：
哨兵節點： 哨兵系統由一個或多個哨兵節點組成，哨兵節點是特殊的 Redis 節點，不存儲數據；
數據節點： 主節點和從節點都是數據節點；
在復制的基礎上，哨兵實現了 自動化的故障恢復 功能，下方是官方對于哨兵功能的描述：
監控（Monitoring）： 哨兵會不斷地檢查主節點和從節點是否運作正常。
自動故障轉移（Automatic failover）： 當 主節點 不能正常工作時，哨兵會開始 自動故障轉移操作，它會將失效主節點的其中一個 從節點升級為新的主節點，并讓其他從節點改為復制新的主節點。
配置提供者（Configuration provider）： 客戶端在初始化時，通過連接哨兵來獲得當前 Redis 服務的主節點地址。
通知（Notification）： 哨兵可以將故障轉移的結果發送給客戶端。
其中，監控和自動故障轉移功能，使得哨兵可以及時發現主節點故障并完成轉移。而配置提供者和通知功能，則需要在與客戶端的交互中才能體現。
新的主服務器是怎樣被挑選出來的？
故障轉移操作的第一步 要做的就是在已下線主服務器屬下的所有從服務器中，挑選出一個狀態良好、數據完整的從服務器，然后向這個從服務器發送 slaveof no one 命令，將這個從服務器轉換為主服務器。但是這個從服務器是怎么樣被挑選出來的呢？
簡單來說 Sentinel 使用以下規則來選擇新的主服務器：
在失效主服務器屬下的從服務器當中， 那些被標記為主觀下線、已斷線、或者最后一次回復 PING 命令的時間大于五秒鐘的從服務器都會被 淘汰。
在失效主服務器屬下的從服務器當中， 那些與失效主服務器連接斷開的時長超過 down-after 選項指定的時長十倍的從服務器都會被 淘汰。
在 經歷了以上兩輪淘汰之后 剩下來的從服務器中， 我們選出 復制偏移量（replication offset）最大 的那個 從服務器 作為新的主服務器；如果復制偏移量不可用，或者從服務器的復制偏移量相同，那么 帶有最小運行 ID 的那個從服務器成為新的主服務器。
更多細節 推薦閱讀 之前的系列文章，不僅有原理講解，還有實戰環節：
Redis(9)——史上最強【集群】入門實踐教程
■Redis 集群使用過嗎？原理？
上圖 展示了 Redis Cluster 典型的架構圖，集群中的每一個 Redis 節點都 互相兩兩相連，客戶端任意 直連 到集群中的 任意一臺，就可以對其他 Redis 節點進行 讀寫 的操作。
基本原理
Redis 集群中內置了 16384 個哈希槽。當客戶端連接到 Redis 集群之后，會同時得到一份關于這個 集群的配置信息，當客戶端具體對某一個 key 值進行操作時，會計算出它的一個 Hash 值，然后把結果對 16384 ?求余數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，Redis 會根據節點數量 大致均等 的將哈希槽映射到不同的節點。
再結合集群的配置信息就能夠知道這個 key 值應該存儲在哪一個具體的 Redis 節點中，如果不屬于自己管，那么就會使用一個特殊的 MOVED 命令來進行一個跳轉，告訴客戶端去連接這個節點以獲取數據：
GET x -MOVED 3999 127.0.0.1:6381MOVED 指令第一個參數 3999 是 key 對應的槽位編號，后面是目標節點地址，MOVED 命令前面有一個減號，表示這是一個錯誤的消息。客戶端在收到 MOVED 指令后，就立即糾正本地的 槽位映射表，那么下一次再訪問 key 時就能夠到正確的地方去獲取了。
集群的主要作用
數據分區： 數據分區 (或稱數據分片) 是集群最核心的功能。集群將數據分散到多個節點，一方面 突破了 Redis 單機內存大小的限制，存儲容量大大增加；另一方面 每個主節點都可以對外提供讀服務和寫服務，大大提高了集群的響應能力。Redis 單機內存大小受限問題，在介紹持久化和主從復制時都有提及，例如，如果單機內存太大，bgsave 和 bgrewriteaof 的 fork 操作可能導致主進程阻塞，主從環境下主機切換時可能導致從節點長時間無法提供服務，全量復制階段主節點的復制緩沖區可能溢出……
高可用： 集群支持主從復制和主節點的 自動故障轉移 （與哨兵類似），當任一節點發生故障時，集群仍然可以對外提供服務。
■集群中數據如何分區？
Redis 采用方案三。
方案一：哈希值 % 節點數
哈希取余分區思路非常簡單：計算 key 的 hash 值，然后對節點數量進行取余，從而決定數據映射到哪個節點上。
不過該方案最大的問題是，當新增或刪減節點時，節點數量發生變化，系統中所有的數據都需要 重新計算映射關系，引發大規模數據遷移。
方案二：一致性哈希分區
一致性哈希算法將 整個哈希值空間 組織成一個虛擬的圓環，范圍是 [0 - 232 - 1]，對于每一個數據，根據 key 計算 hash 值，確數據在環上的位置，然后從此位置沿順時針行走，找到的第一臺服務器就是其應該映射到的服務器：
與哈希取余分區相比，一致性哈希分區將 增減節點的影響限制在相鄰節點。以上圖為例，如果在 node1 和 node2 之間增加 node5，則只有 node2 中的一部分數據會遷移到 node5；如果去掉 node2，則原 node2 中的數據只會遷移到 node4 中，只有 node4 會受影響。
一致性哈希分區的主要問題在于，當 節點數量較少 時，增加或刪減節點，對單個節點的影響可能很大，造成數據的嚴重不平衡。還是以上圖為例，如果去掉 node2，node4 中的數據由總數據的 1/4 左右變為 1/2 左右，與其他節點相比負載過高。
方案三：帶有虛擬節點的一致性哈希分區
該方案在 一致性哈希分區的基礎上，引入了 虛擬節點 的概念。Redis 集群使用的便是該方案，其中的虛擬節點稱為 槽（slot）。槽是介于數據和實際節點之間的虛擬概念，每個實際節點包含一定數量的槽，每個槽包含哈希值在一定范圍內的數據。
在使用了槽的一致性哈希分區中，槽是數據管理和遷移的基本單位。槽 解耦 了 數據和實際節點 之間的關系，增加或刪除節點對系統的影響很小。仍以上圖為例，系統中有 4 個實際節點，假設為其分配 16 個槽(0-15)；
槽 0-3 位于 node1；4-7 位于 node2；以此類推....
如果此時刪除 node2，只需要將槽 4-7 重新分配即可，例如槽 4-5 分配給 node1，槽 6 分配給 node3，槽 7 分配給 node4；可以看出刪除 node2 后，數據在其他節點的分布仍然較為均衡。
■節點之間的通信機制了解嗎？
集群的建立離不開節點之間的通信，例如我們在 快速體驗 中剛啟動六個集群節點之后通過 redis-cli 命令幫助我們搭建起來了集群，實際上背后每個集群之間的兩兩連接是通過了 CLUSTER MEET <ip> <port> 命令發送 MEET 消息完成的，下面我們展開詳細說說。
兩個端口
在 哨兵系統 中，節點分為 數據節點 和 哨兵節點：前者存儲數據，后者實現額外的控制功能。在 集群 中，沒有數據節點與非數據節點之分：所有的節點都存儲數據，也都參與集群狀態的維護。為此，集群中的每個節點，都提供了兩個 TCP 端口：
普通端口： 即我們在前面指定的端口 (7000等)。普通端口主要用于為客戶端提供服務 （與單機節點類似）；但在節點間數據遷移時也會使用。
集群端口： 端口號是普通端口 + 10000 （10000是固定值，無法改變），如 7000 節點的集群端口為 17000。集群端口只用于節點之間的通信，如搭建集群、增減節點、故障轉移等操作時節點間的通信；不要使用客戶端連接集群接口。為了保證集群可以正常工作，在配置防火墻時，要同時開啟普通端口和集群端口。
Gossip 協議
節點間通信，按照通信協議可以分為幾種類型：單對單、廣播、Gossip 協議等。重點是廣播和 Gossip 的對比。
廣播是指向集群內所有節點發送消息。優點 是集群的收斂速度快(集群收斂是指集群內所有節點獲得的集群信息是一致的)，缺點 是每條消息都要發送給所有節點，CPU、帶寬等消耗較大。
Gossip 協議的特點是：在節點數量有限的網絡中，每個節點都 “隨機” 的與部分節點通信 （并不是真正的隨機，而是根據特定的規則選擇通信的節點），經過一番雜亂無章的通信，每個節點的狀態很快會達到一致。Gossip 協議的 優點 有負載 (比廣播) 低、去中心化、容錯性高 (因為通信有冗余) 等；缺點 主要是集群的收斂速度慢。
消息類型
集群中的節點采用 固定頻率（每秒10次） 的 定時任務 進行通信相關的工作：判斷是否需要發送消息及消息類型、確定接收節點、發送消息等。如果集群狀態發生了變化，如增減節點、槽狀態變更，通過節點間的通信，所有節點會很快得知整個集群的狀態，使集群收斂。
節點間發送的消息主要分為 5 種：meet 消息、ping 消息、pong 消息、fail 消息、publish 消息。不同的消息類型，通信協議、發送的頻率和時機、接收節點的選擇等是不同的：
MEET 消息： 在節點握手階段，當節點收到客戶端的 CLUSTER MEET 命令時，會向新加入的節點發送 MEET 消息，請求新節點加入到當前集群；新節點收到 MEET 消息后會回復一個 PONG 消息。
PING 消息： 集群里每個節點每秒鐘會選擇部分節點發送 PING 消息，接收者收到消息后會回復一個 PONG 消息。PING 消息的內容是自身節點和部分其他節點的狀態信息，作用是彼此交換信息，以及檢測節點是否在線。PING 消息使用 Gossip 協議發送，接收節點的選擇兼顧了收斂速度和帶寬成本，具體規則如下：(1)隨機找 5 個節點，在其中選擇最久沒有通信的 1 個節點；(2)掃描節點列表，選擇最近一次收到 PONG 消息時間大于 cluster_node_timeout / 2 的所有節點，防止這些節點長時間未更新。
PONG消息： PONG 消息封裝了自身狀態數據。可以分為兩種：第一種 是在接到 MEET/PING 消息后回復的 PONG 消息；第二種 是指節點向集群廣播 PONG 消息，這樣其他節點可以獲知該節點的最新信息，例如故障恢復后新的主節點會廣播 PONG 消息。
FAIL 消息： 當一個主節點判斷另一個主節點進入 FAIL 狀態時，會向集群廣播這一 FAIL 消息；接收節點會將這一 FAIL 消息保存起來，便于后續的判斷。
PUBLISH 消息： 節點收到 PUBLISH 命令后，會先執行該命令，然后向集群廣播這一消息，接收節點也會執行該 PUBLISH 命令。
■集群數據如何存儲的有了解嗎？
節點需要專門的數據結構來存儲集群的狀態。所謂集群的狀態，是一個比較大的概念，包括：集群是否處于上線狀態、集群中有哪些節點、節點是否可達、節點的主從狀態、槽的分布……
節點為了存儲集群狀態而提供的數據結構中，最關鍵的是 clusterNode 和 clusterState 結構：前者記錄了一個節點的狀態，后者記錄了集群作為一個整體的狀態。
clusterNode 結構
clusterNode 結構保存了 一個節點的當前狀態，包括創建時間、節點 id、ip 和端口號等。每個節點都會用一個 clusterNode 結構記錄自己的狀態，并為集群內所有其他節點都創建一個 clusterNode 結構來記錄節點狀態。
下面列舉了 clusterNode 的部分字段，并說明了字段的含義和作用：
typedef struct clusterNode {//節點創建時間mstime_t ctime;//節點idchar name[REDIS_CLUSTER_NAMELEN];//節點的ip和端口號char ip[REDIS_IP_STR_LEN];int port;//節點標識：整型，每個bit都代表了不同狀態，如節點的主從狀態、是否在線、是否在握手等int flags;//配置紀元：故障轉移時起作用，類似于哨兵的配置紀元uint64_t configEpoch;//槽在該節點中的分布：占用16384/8個字節，16384個比特；每個比特對應一個槽：比特值為1，則該比特對應的槽在節點中；比特值為0，則該比特對應的槽不在節點中unsigned char slots[16384/8];//節點中槽的數量int numslots;………… } clusterNode;除了上述字段，clusterNode 還包含節點連接、主從復制、故障發現和轉移需要的信息等。
clusterState 結構
clusterState 結構保存了在當前節點視角下，集群所處的狀態。主要字段包括：
typedef struct clusterState {//自身節點clusterNode *myself;//配置紀元uint64_t currentEpoch;//集群狀態：在線還是下線int state;//集群中至少包含一個槽的節點數量int size;//哈希表，節點名稱->clusterNode節點指針dict *nodes;//槽分布信息：數組的每個元素都是一個指向clusterNode結構的指針；如果槽還沒有分配給任何節點，則為NULLclusterNode *slots[16384];………… } clusterState;除此之外，clusterState 還包括故障轉移、槽遷移等需要的信息。
五、其他問題
■Redis 如何實現分布式鎖？
“推薦閱讀 之前的系列文章：Redis(3)——分布式鎖深入探究
■Redis 過期鍵的刪除策略？
簡單描述
先拋開 Redis 想一下幾種可能的刪除策略：
定時刪除:在設置鍵的過期時間的同時，創建一個定時器 timer). 讓定時器在鍵的過期時間來臨時，立即執行對鍵的刪除操作。
惰性刪除:放任鍵過期不管，但是每次從鍵空間中獲取鍵時，都檢查取得的鍵是否過期，如果過期的話，就刪除該鍵;如果沒有過期，就返回該鍵。
定期刪除:每隔一段時間程序就對數據庫進行一次檢查，刪除里面的過期鍵。至于要刪除多少過期鍵，以及要檢查多少個數據庫，則由算法決定。
在上述的三種策略中定時刪除和定期刪除屬于不同時間粒度的 主動刪除，惰性刪除屬于 被動刪除。
三種策略都有各自的優缺點
定時刪除對內存使用率有優勢，但是對 CPU 不友好；
惰性刪除對內存不友好，如果某些鍵值對一直不被使用，那么會造成一定量的內存浪費；
定期刪除是定時刪除和惰性刪除的折中。
Redis 中的實現
Reids 采用的是 惰性刪除和定時刪除 的結合，一般來說可以借助最小堆來實現定時器，不過 Redis 的設計考慮到時間事件的有限種類和數量，使用了無序鏈表存儲時間事件，這樣如果在此基礎上實現定時刪除，就意味著 O(N) 遍歷獲取最近需要刪除的數據。
■Redis 的淘汰策略有哪些？
Redis 有六種淘汰策略
| volatile-lru | 從已設置過期時間的 KV 集中優先對最近最少使用(less recently used)的數據淘汰 |
| volitile-ttl | 從已設置過期時間的 KV 集中優先對剩余時間短(time to live)的數據淘汰 |
| volitile-random | 從已設置過期時間的 KV 集中隨機選擇數據淘汰 |
| allkeys-lru | 從所有 KV 集中優先對最近最少使用(less recently used)的數據淘汰 |
| allKeys-random | 從所有 KV 集中隨機選擇數據淘汰 |
| noeviction | 不淘汰策略，若超過最大內存，返回錯誤信息 |
4.0 版本后增加以下兩種
volatile-lfu：從已設置過期時間的數據集(server.db[i].expires)中挑選最不經常使用的數據淘汰
allkeys-lfu：當內存不足以容納新寫入數據時，在鍵空間中，移除最不經常使用的 key
■Redis常見性能問題和解決方案？
Master 最好不要做任何持久化工作，包括內存快照和 AOF 日志文件，特別是不要啟用內存快照做持久化。
如果數據比較關鍵，某個 Slave 開啟 AOF 備份數據，策略為每秒同步一次。
為了主從復制的速度和連接的穩定性，Slave 和 Master 最好在同一個局域網內。
盡量避免在壓力較大的主庫上增加從庫。
Master 調用 BGREWRITEAOF 重寫 AOF 文件，AOF 在重寫的時候會占大量的 CPU 和內存資源，導致服務 load 過高，出現短暫服務暫停現象。
為了 Master 的穩定性，主從復制不要用圖狀結構，用單向鏈表結構更穩定，即主從關系為：Master<–Slave1<–Slave2<–Slave3…，這樣的結構也方便解決單點故障問題，實現 Slave 對 Master 的替換，也即，如果 Master 掛了，可以立馬啟用 Slave1 做 Master，其他不變。
■假如Redis里面有1億個key，其中有10w個key是以某個固定的已知的前綴開頭的，如何將它們全部找出來？
使用 keys 指令可以掃出指定模式的 key 列表。但是要注意 keys 指令會導致線程阻塞一段時間，線上服務會停頓，直到指令執行完畢，服務才能恢復。這個時候可以使用 scan 指令，scan 指令可以無阻塞的提取出指定模式的 key 列表，但是會有一定的重復概率，在客戶端做一次去重就可以了，但是整體所花費的時間會比直接用 keys 指令長。
■More..
參考資料
3w字深度好文|Redis面試全攻略，讀完這個就可以和面試官大戰幾個回合了 - https://mp.weixin.qq.com/s/f9N13fnyTtnu2D5sKZiu9
大廠面試！我和面試官之間關于Redis的一場對弈！- https://mp.weixin.qq.com/s/DHTPSfmWTZpdTmlytzLz1
Redis面試題（2020最新版） - https://blog.csdn.net/ThinkWon/article/details/103522351
總結
以上是生活随笔為你收集整理的妈妈再也不担心我面试被 Redis 问得脸都绿了的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何更优雅的编码？
- 下一篇： 看一遍就理解，图解单链表反转