作為一名服務端工程師，工作中你肯定和 Redis 打過交道。Redis 為什么快，這點想必你也知道，至少為了面試也做過準備。很多人知道 Redis 快僅僅因為它是基于內存實現的，對于其他原因倒是模棱兩可。

[[349387]]

 圖片來自 Pexels

那么今天就和我一起看看：

 

思維導圖

基于內存實現

這點在一開始就提到過了，這里再簡單說說。

Redis 是基于內存的數據庫，那不可避免的就要與磁盤數據庫做對比。對于磁盤數據庫來說，是需要將數據讀取到內存里的，這個過程會受到磁盤 I/O 的限制。

而對于內存數據庫來說，本身數據就存在于內存里，也就沒有了這方面的開銷。

高效的數據結構

Redis 中有多種數據類型，每種數據類型的底層都由一種或多種數據結構來支持。

正是因為有了這些數據結構，Redis 在存儲與讀取上的速度才不受阻礙。這些數據結構有什么特別的地方，各位看官接著往下看：

 

簡單動態字符串

這個名詞可能你不熟悉，換成 SDS 肯定就知道了。這是用來處理字符串的。了解 C 語言的都知道，它是有處理字符串方法的。

而 Redis 就是 C 語言實現的，那為什么還要重復造輪子?我們從以下幾點來看：

①字符串長度處理

 

這個圖是字符串在 C 語言中的存儲方式，想要獲取 Redis 的長度，需要從頭開始遍歷，直到遇到 '\0' 為止。

 

Redis 中怎么操作呢?用一個 len 字段記錄當前字符串的長度。想要獲取長度只需要獲取 len 字段即可。

你看，差距不言自明。前者遍歷的時間復雜度為 O(n)，Redis 中 O(1) 就能拿到，速度明顯提升。

②內存重新分配

C 語言中涉及到修改字符串的時候會重新分配內存。修改地越頻繁，內存分配也就越頻繁。而內存分配是會消耗性能的，那么性能下降在所難免。

而 Redis 中會涉及到字符串頻繁的修改操作，這種內存分配方式顯然就不適合了。

于是 SDS 實現了兩種優化策略：

空間預分配：對 SDS 修改及空間擴充時，除了分配所必須的空間外，還會額外分配未使用的空間。

具體分配規則是這樣的：SDS 修改后，len 長度小于 1M，那么將會額外分配與 len 相同長度的未使用空間。如果修改后長度大于 1M，那么將分配 1M 的使用空間。

惰性空間釋放：當然，有空間分配對應的就有空間釋放。

SDS 縮短時，并不會回收多余的內存空間，而是使用 free 字段將多出來的空間記錄下來。如果后續有變更操作，直接使用 free 中記錄的空間，減少了內存的分配。

③二進制安全

你已經知道了 Redis 可以存儲各種數據類型，那么二進制數據肯定也不例外。但二進制數據并不是規則的字符串格式，可能會包含一些特殊的字符，比如 '\0' 等。

前面我們提到過，C 中字符串遇到 '\0' 會結束，那 '\0' 之后的數據就讀取不上了。但在 SDS 中，是根據 len 長度來判斷字符串結束的。

看，二進制安全的問題就解決了。

雙端鏈表

列表 List 更多是被當作隊列或棧來使用的。隊列和棧的特性一個先進先出，一個先進后出。雙端鏈表很好的支持了這些特性。

 

雙端鏈表

①前后節點

 

鏈表里每個節點都帶有兩個指針，prev 指向前節點，next 指向后節點。這樣在時間復雜度為 O(1) 內就能獲取到前后節點。 

②頭尾節點

 

你可能注意到了，頭節點里有 head 和 tail 兩個參數，分別指向頭節點和尾節點。

這樣的設計能夠對雙端節點的處理時間復雜度降至 O(1) ，對于隊列和棧來說再適合不過。同時鏈表迭代時從兩端都可以進行。

③鏈表長度

頭節點里同時還有一個參數 len，和上邊提到的 SDS 里類似，這里是用來記錄鏈表長度的。

因此獲取鏈表長度時不用再遍歷整個鏈表，直接拿到 len 值就可以了，這個時間復雜度是 O(1)。

你看，這些特性都降低了 List 使用時的時間開銷。

壓縮列表

雙端鏈表我們已經熟悉了。不知道你有沒有注意到一個問題：如果在一個鏈表節點中存儲一個小數據，比如一個字節。那么對應的就要保存頭節點，前后指針等額外的數據。

這樣就浪費了空間，同時由于反復申請與釋放也容易導致內存碎片化。這樣內存的使用效率就太低了。

于是，壓縮列表上場了!

它是經過特殊編碼，專門為了提升內存使用效率設計的。所有的操作都是通過指針與解碼出來的偏移量進行的。 

并且壓縮列表的內存是連續分配的，遍歷的速度很快。

字典

Redis 作為 K-V 型數據庫，所有的鍵值都是用字典來存儲的。

日常學習中使用的字典你應該不會陌生，想查找某個詞通過某個字就可以直接定位到，速度非常快。

這里所說的字典原理上是一樣的，通過某個 key 可以直接獲取到對應的 value。

字典又稱為哈希表，這點沒什么可說的。哈希表的特性大家都很清楚，能夠在 O(1) 時間復雜度內取出和插入關聯的值。

跳躍表

作為 Redis 中特有的數據結構-跳躍表，其在鏈表的基礎上增加了多級索引來提升查找效率。

 

這是跳躍表的簡單原理圖，每一層都有一條有序的鏈表，最底層的鏈表包含了所有的元素。這樣跳躍表就可以支持在 O(logN) 的時間復雜度里查找到對應的節點。

下面這張是跳表真實的存儲結構，和其它數據結構一樣，都在頭節點里記錄了相應的信息，減少了一些不必要的系統開銷。

 

合理的數據編碼

對于每一種數據類型來說，底層的支持可能是多種數據結構，什么時候使用哪種數據結構，這就涉及到了編碼轉化的問題。

那我們就來看看，不同的數據類型是如何進行編碼轉化的：

• String：存儲數字的話，采用 int 類型的編碼，如果是非數字的話，采用 raw 編碼。
• List：字符串長度及元素個數小于一定范圍使用 ziplist 編碼，任意條件不滿足，則轉化為 linkedlist 編碼。
• Hash：hash 對象保存的鍵值對內的鍵和值字符串長度小于一定值及鍵值對。
• Set：保存元素為整數及元素個數小于一定范圍使用 intset 編碼，任意條件不滿足，則使用 hashtable 編碼。
• Zset：zset 對象中保存的元素個數小于及成員長度小于一定值使用 ziplist 編碼，任意條件不滿足，則使用 skiplist 編碼。

合適的線程模型

Redis 快的原因還有一個是因為使用了合適的線程模型：

 

I/O 多路復用模型

I/O ：網絡 I/O;多路：多個 TCP 連接;復用：共用一個線程或進程。

生產環境中的使用，通常是多個客戶端連接 Redis，然后各自發送命令至 Redis 服務器，最后服務端處理這些請求返回結果。

應對大量的請求，Redis 中使用 I/O 多路復用程序同時監聽多個套接字，并將這些事件推送到一個隊列里，然后逐個被執行。最終將結果返回給客戶端。 

避免上下文切換

你一定聽說過，Redis 是單線程的。那么單線程的 Redis 為什么會快呢?

因為多線程在執行過程中需要進行 CPU 的上下文切換，這個操作比較耗時。

Redis 又是基于內存實現的，對于內存來說，沒有上下文切換效率就是最高的。多次讀寫都在一個CPU 上，對于內存來說就是最佳方案。

單線程模型

順便提一下，為什么 Redis 是單線程的。

Redis 中使用了 Reactor 單線程模型，你可能對它并不熟悉。沒關系，只需要大概了解一下即可。

 

這張圖里，接收到用戶的請求后，全部推送到一個隊列里，然后交給文件事件分派器，而它是單線程的工作方式。Redis 又是基于它工作的，所以說 Redis 是單線程的。

Redis 單線程與多線程

Redis是單線程的，這話擱以前，是橫著走的，誰都知道的真理。現在不一樣，Redis 變了。再說這句話，多少得有質疑的語氣來跟你辯駁一番。意志不堅定的，可能就繳械投降，順著別人走了。

到底是什么樣的，各位看官請跟小萊一起往下看：

 

Reactor 模式

反應器模式，你可能不太認識，如果看完上文的話應該會有點印象。涉及到 Redis 線程它是一個繞不過去的話題。

①傳統阻塞 IO 模型

在講反應器模式前，這里有必要提一下傳統阻塞 IO 模型的處理方式。

在傳統阻塞 IO 模型中，由一個獨立的 Acceptor 線程來監聽客戶端的連接，每當有客戶端請求過來時，它就會為客戶端分配一個新的線程來進行處理。

當同時有多個請求過來，服務端對應的就會分配相應數量的線程。這就會導致 CPU 頻繁切換，浪費資源。

有的連接請求過來不做任何事情，但服務端還會分配對應的線程，這樣就會造成不必要的線程開銷。

這就好比你去餐廳吃飯，你拿著菜單看了半天發現真他娘的貴，然后你就走人了。

這段時間等你點菜的服務員就相當于一個對應的線程，你要點菜可以看作一個連接請求。

 

同時，每次建立連接后，當線程調用讀寫方法時，線程會被阻塞，直到有數據可讀可寫，在此期間線程不能做其它事情。

還是上邊餐廳吃飯的例子，你出去轉了一圈發現還是這家性價比最高。回到這家餐廳又拿著菜單看了半天，服務員也在旁邊等你點完菜為止。

這個過程中服務員什么也不能做，只能這么干等著，這個過程相當于阻塞。

 

你看這樣的方式，每來一個請求就要分配一個線程，并且還得阻塞地等線程處理完。

有的請求還只是過來連接下，什么操作也不干，還得為它分配一個線程，對服務器資源要求那得多高啊。

遇到高并發場景，不敢想象。對于連接數目比較小的的固定架構倒是可以考慮。

②偽異步 IO 模型

你可能了解過一種通過線程池優化的解決方案，采用線程池和任務隊列的方式。這種被稱作偽異步 IO 模型。

當有客戶端接入時，將客戶端的請求封裝成一個 task 投遞到后端線程池中來處理。線程池維護一個消息隊列和多個活躍線程，對消息隊列中的任務進行處理。

 

這種解決方案，避免了為每個請求創建一個線程導致的線程資源耗盡問題。但是底層仍然是同步阻塞模型。

如果線程池內的所有線程都阻塞了，那么對于更多請求就無法響應了。因此這種模式會限制最大連接數，并不能從根本上解決問題。

我們繼續用上邊的餐廳來舉例，餐廳老板在經營了一段時間后，顧客多了起來，原本店里的 5 個服務員一對一服務的話根本對付不過來。

于是老板采用 5 個人線程池的方式。服務員服務完一個客人后立刻去服務另一個。

這時問題出現了，有的客人點菜特別慢，服務員就得等待很長時間，直到客人點完為止。

如果 5 個客人都點的特別慢的話，這 5 個服務員就得一直等下去，就會導致其余的顧客沒有人服務的狀態。這就是我們上邊所說的線程池所有線程都被阻塞的情況。

那么這種問題該如何解決呢?別急， Reactor 模式就要出場了。

③Reactor 設計模式

Reactor 模式的基本設計思想是基于 I/O 復用模型來實現的。

這里說下 I/O 復用模型。和傳統 IO 多線程阻塞不同，I/O 復用模型中多個連接共用一個阻塞對象，應用程序只需要在一個阻塞對象等待。

當某個連接有新的數據可以處理時，操作系統通知應用程序，線程從阻塞狀態返回，開始進行業務處理。

什么意思呢?餐廳老板也發現了顧客點餐慢的問題，于是他采用了一種大膽的方式，只留了一個服務員。

當客人點餐的時候，這個服務員就去招待別的客人，客人點好餐后直接喊服務員來進行服務。

這里的顧客和服務員可以分別看作多個連接和一個線程。服務員阻塞在一個顧客那里，當有別的顧客點好餐后，她就立刻去服務其他的顧客。

了解了 Reactor 的設計思想后，我們再來看下今天的主角單 Reactor 單線程的實現方案：

 

Reactor 通過 I/O 復用程序監控客戶端請求事件，收到事件后通過任務分派器進行分發。

針對建立連接請求事件，通過 Acceptor 處理，并建立對應的 handler 負責后續業務處理。

針對非連接事件，Reactor 會調用對應的 handler 完成 read→業務處理→write 處理流程，并將結果返回給客戶端。

整個過程都在一個線程里完成：

 

單線程時代

了解了 Reactor 模式后，你可能會有一個疑問，這個和我們今天的主題有什么關系呢。可能你不知道的是，Redis 是基于 Reactor 單線程模式來實現的。

IO多路復用程序接收到用戶的請求后，全部推送到一個隊列里，交給文件分派器。

對于后續的操作，和在 Reactor 單線程實現方案里看到的一樣，整個過程都在一個線程里完成，因此 Redis 被稱為是單線程的操作。 

 

對于單線程的 Redis 來說，基于內存，且命令操作時間復雜度低，因此讀寫速率是非常快的。

多線程時代

Redis6 版本中引入了多線程。上邊已經提到過 Redis 單線程處理有著很快的速度，那為什么還要引入多線程呢?單線程的瓶頸在什么地方?

我們先來看第二個問題，在 Redis 中，單線程的性能瓶頸主要在網絡IO操作上。

也就是在讀寫網絡 read/write 系統調用執行期間會占用大部分 CPU 時間。如果你要對一些大的鍵值對進行刪除操作的話，在短時間內是刪不完的，那么對于單線程來說就會阻塞后邊的操作。

回想下上邊講得 Reactor 模式中單線程的處理方式。針對非連接事件，Reactor 會調用對應的 handler 完成 read→業務處理→write 處理流程，也就是說這一步會造成性能上的瓶頸。

Redis 在設計上采用將網絡數據讀寫和協議解析通過多線程的方式來處理，對于命令執行來說，仍然使用單線程操作。

總結

基于內存實現：

• 數據都存儲在內存里，減少了一些不必要的 I/O 操作，操作速率很快。

高效的數據結構：

• 底層多種數據結構支持不同的數據類型，支持 Redis 存儲不同的數據。
• 不同數據結構的設計，使得數據存儲時間復雜度降到最低。

合理的數據編碼：

• 根據字符串的長度及元素的個數適配不同的編碼格式。

合適的線程模型：

• I/O 多路復用模型同時監聽客戶端連接;
• 單線程在執行過程中不需要進行上下文切換，減少了耗時。

Reactor 模式：

• 傳統阻塞 IO 模型客戶端與服務端線程 1:1 分配，不利于進行擴展。
• 偽異步 IO 模型采用線程池方式，但是底層仍然使用同步阻塞方式，限制了最大連接數。
• Reactor 通過 I/O 復用程序監控客戶端請求事件，通過任務分派器進行分發。

單線程時代：

• 基于 Reactor 單線程模式實現，通過 IO 多路復用程序接收到用戶的請求后，全部推送到一個隊列里，交給文件分派器進行處理。

多線程時代：

• 單線程性能瓶頸主要在網絡 IO 上。
• 將網絡數據讀寫和協議解析通過多線程的方式來處理 ，對于命令執行來說，仍然使用單線程操作。

作者：小萊，一枚后端工程師

編輯：陶家龍

出處：轉載自公眾號IT界農民工(ID：kejishuqian)