作為一名后端工程師，工作中你肯定和 Redis 打過交道。Redis 為什么快，這點想必你也知道，至少為了面試也做過準備。很多人知道 Redis 快僅僅因為它是基于內存實現的，對于其它原因倒是模棱兩可。
那么今天就來一起看看：
- 思維導圖 -
這點在一開始就提到過了，這里再簡單說說。
Redis 是基于內存的數據庫，那不可避免的就要與磁盤數據庫做對比。對于磁盤數據庫來說，是需要將數據讀取到內存里的，這個過程會受到磁盤 I/O 的限制。
而對于內存數據庫來說，本身數據就存在于內存里，也就沒有了這方面的開銷。
Redis 中有多種數據類型，每種數據類型的底層都由一種或多種數據結構來支持。正是因為有了這些數據結構，Redis 在存儲與讀取上的速度才不受阻礙。這些數據結構有什么特別的地方，各位看官接著往下看：
1、簡單動態(tài)字符串
這個名詞可能你不熟悉，換成?SDS?肯定就知道了。這是用來處理字符串的。了解 C 語言的都知道，它是有處理字符串方法的。而 Redis 就是 C 語言實現的，那為什么還要重復造輪子？我們從以下幾點來看：
（1）字符串長度處理
這個圖是字符串在 C 語言中的存儲方式，想要獲取 「Redis」的長度，需要從頭開始遍歷，直到遇到 '\0' 為止。
Redis 中怎么操作呢？用一個 len 字段記錄當前字符串的長度。想要獲取長度只需要獲取 len 字段即可。你看，差距不言自明。前者遍歷的時間復雜度為 O(n)，Redis 中 O(1)?就能拿到，速度明顯提升。
（2）內存重新分配
C 語言中涉及到修改字符串的時候會重新分配內存。修改地越頻繁，內存分配也就越頻繁。而內存分配是會消耗性能的，那么性能下降在所難免。
而 Redis 中會涉及到字符串頻繁的修改操作，這種內存分配方式顯然就不適合了。于是 SDS 實現了兩種優(yōu)化策略：
空間預分配
對 SDS 修改及空間擴充時，除了分配所必須的空間外，還會額外分配未使用的空間。
具體分配規(guī)則是這樣的：SDS 修改后，len 長度小于 1M，那么將會額外分配與 len 相同長度的未使用空間。如果修改后長度大于 1M，那么將分配1M的使用空間。
惰性空間釋放
當然，有空間分配對應的就有空間釋放。
SDS 縮短時，并不會回收多余的內存空間，而是使用 free 字段將多出來的空間記錄下來。如果后續(xù)有變更操作，直接使用 free 中記錄的空間，減少了內存的分配。
（3）二進制安全
你已經知道了 Redis 可以存儲各種數據類型，那么二進制數據肯定也不例外。但二進制數據并不是規(guī)則的字符串格式，可能會包含一些特殊的字符，比如 '\0' 等。
前面我們提到過，C 中字符串遇到?'\0'?會結束，那?'\0'?之后的數據就讀取不上了。但在 SDS 中，是根據 len 長度來判斷字符串結束的。
看，二進制安全的問題就解決了。
2、雙端鏈表
列表 List 更多是被當作隊列或棧來使用的。隊列和棧的特性一個先進先出，一個先進后出。雙端鏈表很好的支持了這些特性。
- 雙端鏈表?-
（1）前后節(jié)點
鏈表里每個節(jié)點都帶有兩個指針，prev 指向前節(jié)點，next 指向后節(jié)點。這樣在時間復雜度為 O(1)?內就能獲取到前后節(jié)點。
（2）頭尾節(jié)點
你可能注意到了，頭節(jié)點里有 head 和 tail 兩個參數，分別指向頭節(jié)點和尾節(jié)點。這樣的設計能夠對雙端節(jié)點的處理時間復雜度降至 O(1)?，對于隊列和棧來說再適合不過。同時鏈表迭代時從兩端都可以進行。
（3）鏈表長度
頭節(jié)點里同時還有一個參數 len，和上邊提到的 SDS 里類似，這里是用來記錄鏈表長度的。因此獲取鏈表長度時不用再遍歷整個鏈表，直接拿到 len 值就可以了，這個時間復雜度是 O(1)。
你看，這些特性都降低了 List 使用時的時間開銷。
3、壓縮列表
雙端鏈表我們已經熟悉了。不知道你有沒有注意到一個問題：如果在一個鏈表節(jié)點中存儲一個小數據，比如一個字節(jié)。那么對應的就要保存頭節(jié)點，前后指針等額外的數據。
這樣就浪費了空間，同時由于反復申請與釋放也容易導致內存碎片化。這樣內存的使用效率就太低了。
于是，壓縮列表上場了！
它是經過特殊編碼，專門為了提升內存使用效率設計的。所有的操作都是通過指針與解碼出來的偏移量進行的。
并且壓縮列表的內存是連續(xù)分配的，遍歷的速度很快。
4、字典
Redis 作為 K-V 型數據庫，所有的鍵值都是用字典來存儲的。
日常學習中使用的字典你應該不會陌生，想查找某個詞通過某個字就可以直接定位到，速度非?？?。這里所說的字典原理上是一樣的，通過某個 key 可以直接獲取到對應的value。
字典又稱為哈希表，這點沒什么可說的。哈希表的特性大家都很清楚，能夠在?O(1)?時間復雜度內取出和插入關聯的值。
5、跳躍表
作為 Redis 中特有的數據結構-跳躍表，其在鏈表的基礎上增加了多級索引來提升查找效率。
這是跳躍表的簡單原理圖，每一層都有一條有序的鏈表，最底層的鏈表包含了所有的元素。這樣跳躍表就可以支持在?O(logN)?的時間復雜度里查找到對應的節(jié)點。
下面這張是跳表真實的存儲結構，和其它數據結構一樣，都在頭節(jié)點里記錄了相應的信息，減少了一些不必要的系統(tǒng)開銷。
對于每一種數據類型來說，底層的支持可能是多種數據結構，什么時候使用哪種數據結構，這就涉及到了編碼轉化的問題。
那我們就來看看，不同的數據類型是如何進行編碼轉化的：
String：存儲數字的話，采用int類型的編碼，如果是非數字的話，采用 raw 編碼；
List：字符串長度及元素個數小于一定范圍使用 ziplist 編碼，任意條件不滿足，則轉化為 linkedlist 編碼；
Hash：hash 對象保存的鍵值對內的鍵和值字符串長度小于一定值及鍵值對；
Set：保存元素為整數及元素個數小于一定范圍使用 intset 編碼，任意條件不滿足，則使用 hashtable 編碼；
Zset：zset 對象中保存的元素個數小于及成員長度小于一定值使用 ziplist 編碼，任意條件不滿足，則使用 skiplist 編碼。
Redis 快的原因還有一個是因為使用了合適的線程模型：
1、I/O多路復用模型
I/O?：網絡 I/O
多路：多個 TCP 連接
復用：共用一個線程或進程
生產環(huán)境中的使用，通常是多個客戶端連接 Redis，然后各自發(fā)送命令至 Redis 服務器，最后服務端處理這些請求返回結果。
應對大量的請求，Redis 中使用 I/O 多路復用程序同時監(jiān)聽多個套接字，并將這些事件推送到一個隊列里，然后逐個被執(zhí)行。最終將結果返回給客戶端。
2、避免上下文切換
你一定聽說過，Redis 是單線程的。那么單線程的 Redis 為什么會快呢？
因為多線程在執(zhí)行過程中需要進行 CPU 的上下文切換，這個操作比較耗時。Redis 又是基于內存實現的，對于內存來說，沒有上下文切換效率就是最高的。多次讀寫都在一個CPU 上，對于內存來說就是最佳方案。
3、單線程模型
順便提一下，為什么 Redis 是單線程的。
Redis 中使用了 Reactor 單線程模型，你可能對它并不熟悉。沒關系，只需要大概了解一下即可。
這張圖里，接收到用戶的請求后，全部推送到一個隊列里，然后交給文件事件分派器，而它是單線程的工作方式。Redis 又是基于它工作的，所以說 Redis 是單線程的。
基于內存實現
數據都存儲在內存里，減少了一些不必要的 I/O 操作，操作速率很快。
高效的數據結構
底層多種數據結構支持不同的數據類型，支持 Redis 存儲不同的數據；
不同數據結構的設計，使得數據存儲時間復雜度降到最低。
? ?
合理的數據編碼
根據字符串的長度及元素的個數適配不同的編碼格式。
合適的線程模型
I/O 多路復用模型同時監(jiān)聽客戶端連接；
單線程在執(zhí)行過程中不需要進行上下文切換，減少了耗時。
絮叨
推薦閱讀
天啦嚕！知道硬盤很慢，但沒想到比 CPU Cache 慢 10000000 倍
CPU 執(zhí)行程序的秘密，藏在了這 15 張圖里
面試官：如何寫出讓 CPU 跑得更快的代碼？
讀者問：小林你的 500 張圖是怎么畫的？
免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯系我們，謝謝！
下載文檔
