?前言

在 Java 后端的面試中，redis 應該是目前所有框架/中間件中被問到頻率最高的，至少也是之一，

就算把范圍擴大到整個 Java 后端面試知識體系，面試中出現頻率比 redis 高的也不多，可能就那么幾個：HashMap、執行緒池之類的，

綜上，redis 在面試中的重要程度評分可以給到9分，接近滿分，

由于比較重要，知識點也比較多，所以這邊預計分為三篇來呈現，

除了本文之外，另外兩篇，一篇圍繞高可用，主要是持久化、主從復制、哨兵、集群模式等，

另一篇圍繞 redis 的實踐，主要是分布式鎖、快取穿透、快取雪崩、快取擊穿等，

正文

redis 是單執行緒還是多執行緒

這個問題應該已經看到過無數次了，最近 redis 6 出來之后又被翻出來了，

redis 4.0 之前，redis 是完全單執行緒的，

redis 4.0 時，redis 引入了多執行緒，但是額外的執行緒只是用于后臺處理，例如：洗掉物件，核心流程還是完全單執行緒的，這也是為什么有些人說 4.0 是單執行緒的，因為他們指的是核心流程是單執行緒的，

這邊的核心流程指的是 redis 正常處理客戶端請求的流程，通常包括：接收命令、決議命令、執行命令、回傳結果等，

而在最近，redis 6.0 版本又一次引入了多執行緒概念，與 4.0 不同的是，這次的多執行緒會涉及到上述的核心流程，

redis 6.0 中，多執行緒主要用于網路 I/O 階段，也就是接收命令和寫回結果階段，而在執行命令階段，還是由單執行緒串行執行，由于執行時還是串行，因此無需考慮并發安全問題，

值得注意的時，redis 中的多執行緒組不會同時存在“讀”和“寫”，這個多執行緒組只會同時“讀”或者同時“寫”，

redis 6.0 加入多執行緒 I/O 之后，處理命令的核心流程如下:

1、當有讀事件到來時，主執行緒將該客戶端連接放到全域等待讀佇列

2、讀取資料：1）主執行緒將等待讀佇列的客戶端連接通過輪詢調度演算法分配給 I/O 執行緒處理；2）同時主執行緒也會自己負責處理一個客戶端連接的讀事件；3）當主執行緒處理完該連接的讀事件后，會自旋等待所有 I/O 執行緒處理完畢

3、命令執行：主執行緒按照事件被加入全域等待讀佇列的順序（這邊保證了執行順序是正確的），串行執行客戶端命令，然后將客戶端連接放到全域等待寫佇列

4、寫回結果：跟等待讀佇列處理類似，主執行緒將等待寫佇列的客戶端連接使用輪詢調度演算法分配給 I/O 執行緒處理，同時自己也會處理一個，當主執行緒處理完畢后，會自旋等待所有 I/O 執行緒處理完畢，最后清空佇列，

大致流程圖如下：

相關原始碼在 networking.c，核心的方法是：

IOThreadMain、handleClientsWithPendingReadsUsingThreads、

handleClientsWithPendingWritesUsingThreads

為什么 redis 是單執行緒

在 redis 6.0 之前，redis 的核心操作是單執行緒的，

因為 redis 是完全基于記憶體操作的，通常情況下CPU不會是redis的瓶頸，redis 的瓶頸最有可能是機器記憶體的大小或者網路帶寬，

既然CPU不會成為瓶頸，那就順理成章地采用單執行緒的方案了，因為如果使用多執行緒的話會更復雜，同時需要引入背景關系切換、加鎖等等，會帶來額外的性能消耗，

而隨著近些年互聯網的不斷發展，大家對于快取的性能要求也越來越高了，因此 redis 也開始在逐漸往多執行緒方向發展，

最近的 6.0 版本就對核心流程引入了多執行緒，主要用于解決 redis 在網路 I/O 上的性能瓶頸，而對于核心的命令執行階段，目前還是單執行緒的，

redis 為什么使用單行程、單執行緒也很快

1、基于記憶體的操作

2、使用了 I/O 多路復用模型，select、epoll 等，基于 reactor 模式開發了自己的網路事件處理器

3、單執行緒可以避免不必要的背景關系切換和競爭條件，減少了這方面的性能消耗，

4、以上這三點是 redis 性能高的主要原因，其他的還有一些小優化，例如：對資料結構進行了優化，簡單動態字串、壓縮串列等，

專案中使用的 redis 版本

這個問題是我在面試某大廠真實碰到過的，所以大家平時在使用中間件和框架時可以留意下自使用的版本，

下圖是從 redis 官方 github 截的圖，包含了 redis 2.2 之后的所有版本，目前常用的應該是：3.2.*、4.0.*、5.0.*，

redis 在專案中的使用場景

快取、分布式鎖、排行榜（zset）、計數（incrby）、訊息佇列（stream）、地理位置（geo）、訪客統計（hyperloglog）等，

redis常見的資料結構

常見的5種：

String：字串，最基礎的資料型別，
List：串列，
Hash：哈希物件，
Set：集合，
Sorted Set：有序集合，Set 的基礎上加了個分值，

高級的4種：

HyperLogLog：通常用于基數統計，使用少量固定大小的記憶體，來統計集合中唯一元素的數量，統計結果不是精確值，而是一個帶有0.81%標準差（standard error）的近似值，所以，HyperLogLog適用于一些對于統計結果精確度要求不是特別高的場景，例如網站的UV統計，
Geo：redis 3.2 版本的新特性，可以將用戶給定的地理位置資訊儲存起來，并對這些資訊進行操作：獲取2個位置的距離、根據給定地理位置坐標獲取指定范圍內的地理位置集合，

Bitmap：位圖，
Stream：主要用于訊息佇列，類似于 kafka，可以認為是 pub/sub 的改進版，提供了訊息的持久化和主備復制功能，可以讓任何客戶端訪問任何時刻的資料，并且能記住每一個客戶端的訪問位置，還能保證訊息不丟失，

Redis的字串（SDS）和C語言的字串區別

C字串	SDS
獲取字串長度的復雜度為O(N)	獲取字串長度的復雜度為O(1)
API是不安全的，可能會造成緩沖區溢位	API是安全的，不會造成緩沖區溢位
修改字串長度N次必然需要執行N次記憶體重分配	修改字串長度N次最多需要執行N次記憶體重分配
只能保存文本資料	可以保存文本資料或者二進制資料
可以使用所有的<string.h>庫中的函式	可以使用一部分<string.h>庫中的函式

Sorted Set底層資料結構

Sorted Set（有序集合）當前有兩種編碼：ziplist、skiplist

ziplist：使用壓縮串列實作，當保存的元素長度都小于64位元組，同時數量小于128時，使用該編碼方式，否則會使用 skiplist，這兩個引數可以通過 zset-max-ziplist-entries、zset-max-ziplist-value 來自定義修改，

skiplist：zset實作，一個zset同時包含一個字典（dict）和一個跳躍表（zskiplist）

Sorted Set為什么同時使用字典和跳躍表？

主要是為了性能，

單獨使用字典：在執行范圍型操作，比如zrank、zrange，字典需要進行排序，至少需要O(NlogN)的時間復雜度及額外O(N)的記憶體空間，

單獨使用跳躍表：根據成員查找分值操作的復雜度從O(1)上升為O(logN)，

Sorted Set為什么使用跳躍表，而不是紅黑樹？

1）跳表的性能和紅黑樹差不多，

2）跳表更容易實作和除錯，

網上有同學說是因為作者不會紅黑樹，我覺得挺有可能的，

Hash 物件底層結構

Hash 物件當前有兩種編碼：ziplist、hashtable

ziplist：使用壓縮串列實作，每當有新的鍵值對要加入到哈希物件時，程式會先將保存了鍵的節點推入到壓縮串列的表尾，然后再將保存了值的節點推入到壓縮串列表尾，

因此：1）保存了同一鍵值對的兩個節點總是緊挨在一起，保存鍵的節點在前，保存值的節點在后；2）先添加到哈希物件中的鍵值對會被放在壓縮串列的表頭方向，而后來添加的會被放在表尾方向，

hashtable：使用字典作為底層實作，哈希物件中的每個鍵值對都使用一個字典鍵值來保存，跟 java 中的 HashMap 類似，

Hash 物件的擴容流程

hash 物件在擴容時使用了一種叫“漸進式 rehash”的方式，步驟如下：

1、計算新表 size、掩碼，為新表 ht[1] 分配空間，讓字典同時持有 ht[0] 和 ht[1] 兩個哈希表，

2、將 rehash 索引計數器變數 rehashidx 的值設定為0，表示 rehash 正式開始，

3、在 rehash 進行期間，每次對字典執行添加、洗掉、査找、更新操作時，程式除了執行指定的操作以外，還會觸發額外的 rehash 操作，在原始碼中的 _dictRehashStep 方法，

_dictRehashStep：從名字也可以看出來，大意是 rehash 一步，也就是 rehash 一個索引位置，

該方法會從 ht[0] 表的 rehashidx 索引位置上開始向后查找，找到第一個不為空的索引位置，將該索引位置的所有節點 rehash 到 ht[1]，當本次 rehash 作業完成之后，將 ht[0] 的 rehashidx 位置清空，同時將 rehashidx 屬性的值加一，

4、將 rehash 分攤到每個操作上確實是非常妙的方式，但是萬一此時服務器比較空閑，一直沒有什么操作，難道 redis 要一直持有兩個哈希表嗎？

答案當然不是的，我們知道，redis 除了檔案事件外，還有時間事件，redis 會定期觸發時間事件，這些時間事件用于執行一些后臺操作，其中就包含 rehash 操作：當 redis 發現有字典正在進行 rehash 操作時，會花費1毫秒的時間，一起幫忙進行 rehash，

5、隨著操作的不斷執行，最終在某個時間點上，ht[0] 的所有鍵值對都會被 rehash 至 ht[1]，此時 rehash 流程完成，會執行最后的清理作業：釋放 ht[0] 的空間、將 ht[0] 指向 ht[1]、重置 ht[1]、重置 rehashidx 的值為 -1，

相關原始碼在 dict.c，核心方法是：dictExpand、dictRehashMilliseconds、dictRehash、dictFind、

漸進式 rehash 的優點

漸進式 rehash 的好處在于它采取分而治之的方式，將 rehash 鍵值對所需的計算作業均攤到對字典的每個添加、洗掉、查找和更新操作上，從而避免了集中式 rehash 而帶來的龐大計算量，

在進行漸進式 rehash 的程序中，字典會同時使用 ht[0] 和 ht[1] 兩個哈希表，所以在漸進式 rehash 進行期間，字典的洗掉、査找、更新等操作會在兩個哈希表上進行，例如，要在字典里面査找一個鍵的話，程式會先在 ht[0] 里面進行査找，如果沒找到的話，就會繼續到 ht[1] 里面進行査找，諸如此類，

另外，在漸進式 rehash 執行期間，新增的鍵值對會被直接保存到 ht[1], ht[0] 不再進行任何添加操作，這樣就保證了 ht[0] 包含的鍵值對數量會只減不增，并隨著 rehash 操作的執行而最終變成空表，

rehash 流程在資料量大的時候會有什么問題嗎

1、擴容期開始時，會先給 ht[1] 申請空間，所以在整個擴容期間，會同時存在 ht[0] 和 ht[1]，會占用額外的空間，

2、擴容期間同時存在 ht[0] 和 ht[1]，查找、洗掉、更新等操作有概率需要操作兩張表，耗時會增加，

3、redis 在記憶體使用接近 maxmemory 并且有設定驅逐策略的情況下，出現 rehash 會使得記憶體占用超過 maxmemory，觸發驅逐淘汰操作，導致 master/slave 均有有大量的 key 被驅逐淘汰，從而出現 master/slave 主從不一致，

Redis的事件處理器

redis 基于 reactor 模式開發了自己的網路事件處理器，由4個部分組成：套接字、I/O 多路復用程式、檔案事件分派器（dispatcher）、以及事件處理器，

套接字：socket 連接，也就是客戶端連接，當一個套接字準備好執行連接、寫入、讀取、關閉等操作時，就會產生一個相應的檔案事件，因為一個服務器通常會連接多個套接字，所以多個檔案事件有可能會并發地出現，

I/O 多路復用程式：提供 select、epoll、evport、kqueue 的實作，會根據當前系統自動選擇最佳的方式，負責監聽多個套接字，當套接字產生事件時，會向檔案事件分派器傳送那些產生了事件的套接字，

當多個檔案事件并發出現時， I/O 多路復用程式會將所有產生事件的套接字都放到一個佇列里面，然后通過這個佇列，以有序、同步、每次一個套接字的方式向檔案事件分派器傳送套接字：當上一個套接字產生的事件被處理完畢之后，才會繼續傳送下一個套接字，

檔案事件分派器：接收 I/O 多路復用程式傳來的套接字，并根據套接字產生的事件的型別，呼叫相應的事件處理器，

事件處理器：事件處理器就是一個個函式，定義了某個事件發生時，服務器應該執行的動作，例如：建立連接、命令查詢、命令寫入、連接關閉等等，

Redis 洗掉過期鍵的策略（快取失效策略、資料過期策略）

定時洗掉：在設定鍵的過期時間的同時，創建一個定時器，讓定時器在鍵的過期時間來臨時，立即執行對鍵的洗掉操作，對記憶體最友好，對 CPU 時間最不友好，

惰性洗掉：放任鍵過期不管，但是每次獲取鍵時，都檢査鍵是否過期，如果過期的話，就洗掉該鍵；如果沒有過期，就回傳該鍵，對 CPU 時間最優化，對記憶體最不友好，

定期洗掉：每隔一段時間，默認100ms，程式就對資料庫進行一次檢査，洗掉里面的過期鍵，至于要洗掉多少過期鍵，以及要檢査多少個資料庫，則由演算法決定，前兩種策略的折中，對 CPU 時間和記憶體的友好程度較平衡，

Redis 使用惰性洗掉和定期洗掉，

Redis 的記憶體驅逐（淘汰）策略

當 redis 的記憶體空間（maxmemory 引數配置）已經用滿時，redis 將根據配置的驅逐策略（maxmemory-policy 引數配置），進行相應的動作，

當前 redis 的淘汰策略有以下8種，

noeviction：默認策略，不淘汰任何 key，直接回傳錯誤

allkeys-lru：在所有的 key 中，使用 LRU 演算法淘汰部分 key

allkeys-lfu：在所有的 key 中，使用 LFU 演算法淘汰部分 key

allkeys-random：在所有的 key 中，隨機淘汰部分 key

volatile-lru：在設定了過期時間的 key 中，使用 LRU 演算法淘汰部分 key

volatile-lfu：在設定了過期時間的 key 中，使用 LFU 演算法淘汰部分 key

volatile-random：在設定了過期時間的 key 中，隨機淘汰部分 key

volatile-ttl：在設定了過期時間的 key 中，挑選 TTL（time to live，剩余時間）短的 key 淘汰

最后

我不能保證所寫的每個地方都是對的，但是至少能保證所寫每一句話、每一行代碼都經過了認真的推敲、仔細的斟酌，

如果你覺得本文寫的還不錯，對你有幫助，請通過【點贊】讓我知道，支持我寫出更好的文章，這對我很重要，如果有什么問題和建議，也歡迎【留言】一起交流探討，

面試必問的 Redis：資料結構和基礎概念

?前言

正文

最后

推薦閱讀