Redis 爲何這麼快？這纔是最完美的回答

做爲一名服務端工程師，工做中你確定和 Redis 打過交道。Redis 爲何快，這點想必你也知道，至少爲了面試也作過準備。不少人知道 Redis 快僅僅由於它是基於內存實現的，對於其它緣由卻是模棱兩可。

那麼今天就和小萊一塊兒看看：

​

• 思惟導圖 -

基於內存實現

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

Redis 是基於內存的數據庫，那不可避免的就要與磁盤數據庫作對比。對於磁盤數據庫來講，是須要將數據讀取到內存裏的，這個過程會受到磁盤 I/O 的限制。

而對於內存數據庫來講，自己數據就存在於內存裏，也就沒有了這方面的開銷。

高效的數據結構

Redis 中有多種數據類型，每種數據類型的底層都由一種或多種數據結構來支持。正是由於有了這些數據結構，Redis 在存儲與讀取上的速度纔不受阻礙。這些數據結構有什麼特別的地方，各位看官接着往下看：

​

一、簡單動態字符串

這個名詞可能你不熟悉，換成 SDS 確定就知道了。這是用來處理字符串的。瞭解 C 語言的都知道，它是有處理字符串方法的。而 Redis 就是 C 語言實現的，那爲何還要重複造輪子？咱們從如下幾點來看：

（1）字符串長度處理

​

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

​

Redis 中怎麼操做呢？用一個 len 字段記錄當前字符串的長度。想要獲取長度只須要獲取 len 字段便可。你看，差距不言自明。前者遍歷的時間複雜度爲 O(n)，Redis 中 O(1) 就能拿到，速度明顯提高。

（2）內存從新分配

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

而 Redis 中會涉及到字符串頻繁的修改操做，這種內存分配方式顯然就不適合了。因而 SDS 實現了兩種優化策略：

• 空間預分配

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

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

• 惰性空間釋放

固然，有空間分配對應的就有空間釋放。

SDS 縮短時，並不會回收多餘的內存空間，而是使用 free 字段將多出來的空間記錄下來。若是後續有變動操做，直接使用 free 中記錄的空間，減小了內存的分配。

（3）二進制安全

你已經知道了 Redis 能夠存儲各類數據類型，那麼二進制數據確定也不例外。但二進制數據並非規則的字符串格式，可能會包含一些特殊的字符，好比 '0' 等。

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

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

二、雙端鏈表

列表 List 更可能是被看成隊列或棧來使用的。隊列和棧的特性一個先進先出，一個先進後出。雙端鏈表很好的支持了這些特性。

​

- 雙端鏈表 -

（1）先後節點

​

鏈表裏每一個節點都帶有兩個指針，prev 指向前節點，next 指向後節點。這樣在時間複雜度爲 O(1) 內就能獲取到先後節點。

（2）頭尾節點

​

你可能注意到了，頭節點裏有 head 和 tail 兩個參數，分別指向頭節點和尾節點。這樣的設計可以對雙端節點的處理時間複雜度降至 O(1) ，對於隊列和棧來講再適合不過。同時鏈表迭代時從兩端均可以進行。

（3）鏈表長度

頭節點裏同時還有一個參數 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 是單線程的。

總結

基於內存實現

• 數據都存儲在內存裏，減小了一些沒必要要的 I/O 操做，操做速率很快。

高效的數據結構

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

合理的數據編碼

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

合適的線程模型

• I/O 多路複用模型同時監聽客戶端鏈接；
• 單線程在執行過程當中不須要進行上下文切換，減小了耗時。

=

推薦閱讀：

MySQL從入門到進階教程，主講老師：馬士兵、連鵬舉

字節跳動總結的設計模式 PDF 火了，完整版開放分享

刷Github時發現了一本阿里大神的算法筆記！標星70.5K

若是能聽懂這個網約車實戰，哪怕接私活你均可以月入40K

爲何阿里巴巴的程序員成長速度這麼快，看完他們的內部資料我懂了

程序員達到50W年薪所須要具有的知識體系。

關於【暴力遞歸算法】你所不知道的思路

看完三件事❤️

若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：

點贊，轉發，有大家的 『點贊和評論』，纔是我創造的動力。

關注公衆號 『 Java鬥帝 』，不按期分享原創知識。

同時能夠期待後續文章ing🚀