原文連結：10w+QPS 的 Redis 真的只是因為單執行緒和記憶體？360° 深入底層設計為你揭開 Redis 神祕面紗！
你以為 Redis 這麼快僅僅因為單執行緒和基於記憶體？
那麼你想得太少了，我個人認為 Redis 的快是基於多方面的：不但是單執行緒和記憶體，還有底層的資料結構設計，網路通訊的設計，主從、哨兵和叢集等等方面的設計~
下面，我將 360° 為你揭開 Redis QPS達到10萬/秒的神祕面紗。
一、底層資料結構設計
1、底層架構：
首先值得稱讚的第一點：Redis 底層使用的資料結構很多，但是卻沒有直接使用這些資料結構來實現鍵值對資料庫，而是基於資料結構建立了一個物件（redisObject）系統。（是不是覺得有點物件導向程式設計的意思 ? ~）
物件系統裡面包括了字串物件，列表物件，雜湊物件、集合物件和有序集合物件。
使用物件的好處：
- Redis 在執行命令之前，可以根據物件的型別判斷這個物件是否可以執行給定的命令。
- 可以針對不用的使用場景，為物件設定多種不同的資料結構實現，從而優化物件在不同場景下的使用效率。
一個物件怎麼設定不同的資料結構實現？
在講解前，我們必須要了解 Redis 物件的結構。
它三個重要的部分：type 屬性、encoding 屬性，和 ptr 屬性。
我們用字串物件為例：
我們都知道，Redis 的 SET 命令其實是針對字串的，但是它也可以設定數值。那底層是怎麼做的呢？
它會將 String 物件的 encoding 屬性標識為 REDIS_ENCODING_INT，表示這個鍵對應的值是 Long 型別的整數。
而當我們利用 APPEND 命令往值後面新增字串呢？
此時會將 String 物件的 encoding 屬性的標識為 REDIS_ENCODING_RAW，表示這個值此時是簡單動態字串。
正是因為使用物件，通過 type、encoding和prt 屬性，使得同一個物件可以適應在不同的場景下，使得不同的改變不需要建立新的鍵值對，這樣使得 Redis 的物件使用效率非常的高。
2、靈活的字串物件
Redis 的字串物件採用三種編碼：int、embstr 和 raw。
int 編碼就不用說了，就是為了相容 SET 命令可以設定數值。
而 embstr 和 raw 最大的區別就是記憶體分配操作次數：
- embstr 編碼專門用於儲存短字串，所以它是通過呼叫一次記憶體分配函式來分配一塊連續的空間，空間包含 redisObject 和 sdsshdr 兩個結構，這樣可以很好地利用快取帶來的優勢。
- raw 編碼則是用於儲存長字串，它通過呼叫兩次記憶體分配函式來分別建立 redisObject 結構和 sdshdr 結構
3、絕妙的字串優化策略
Redis 中字串物件的底層是使用 SDS （Simple Dynamic String）實現的。
SDS 有三部分：
-
len：記錄 buf 陣列中已使用位元組的數量，等於 SDS 鎖儲存字串的長度
-
free：記錄 buf 陣列中未使用位元組的數量
-
buf[]：位元組陣列，用於儲存字串
首先介紹一下使用 len 屬性和 free 屬性的好處：
得益於 SDS 有 len 屬性，獲取字串長度的複雜度為 O(1);
得益於 SDS 有 free 屬性，可以杜絕緩衝區溢位，字串擴充套件前可以根據 free 屬性來判斷是否滿足直接擴充套件，不滿足則需要先執行記憶體重分配操作，然後再擴充套件字串。
我們都知道修改字串長度很有可能導致觸發記憶體重分配操作，但是 Redis 對於記憶體重分配有兩個優化策略：
空間預分配：
-
空間預分配用於優化 SDS 的字串增長操作：當 SDS 的API對一個 SDS 進行修改，並且需要對 SDS 進行空間擴充套件的時候，程式不僅會為 SDS 分配修改所必須要的空間，還會為 SDS 分配額外的未使用空間，並使用 free 屬性來記錄這些額外分配的位元組的數量。
-
通過空間預分配策略，下次字串擴充套件時，可以充分利用上次預分配的未使用空間，而不用再觸發記憶體重分配操作了。
惰性空間釋放：
- 惰性空間釋放用於優化 SDS 的字串縮短操作：當 SDS 的API需要縮短 SDS 儲存的字串時，程式並不立即使用記憶體重分配來回收縮短後多出來的位元組，而是使用上面提到的 free 屬性將這些位元組的數量記錄起來，並等待將來使用。
- 通過惰性空間釋放策略，SDS 避免了縮短字串時所需的記憶體重分配操作，併為將來可能有的增長操作提供了優化。
4、字串變數的共享和適配
物件中使用數字是非常常見的，例如設定使用者的年齡、學生的分數、部落格中文章的排名等等。所以 Redis 為了避免重複建立數字對應的字串物件，它會將一個範圍的整數對應的字串物件用來共享。
目前來說，Redis 會在初始化伺服器時，建立一萬個字串物件，這些物件包含了從 0 到 9999 的所有整數值，當伺服器需要用到值為 0 到 9999 的字串物件時，伺服器就會使用這些共享物件，而不是新建立物件。
當然了，我們還可以通過修改 redis.h/REDIS_SHARED_INTEGERS 常量來修改建立共享字串物件的數量。
我們都知道 Redis 是使用 C 語言開發的，所以 SDS 一樣遵循 C 字串以空字元結尾的慣例，所以 SDS 可以重用很多 <string.h> 庫定義的函式。
5、強大的壓縮列表 ziplist
簡單介紹一下 ziplist 的結構：
- zlbytes：記錄整個壓縮列表佔用的記憶體位元組數；在對壓縮列表進行記憶體重分配時，或者計算 zlend 的位置時使用
- zltail：記錄壓縮列表表尾節點距離壓縮列表的起始地址有多少位元組；通過這個偏移量，程式無須遍歷真個壓縮列表就可以確定表尾節點的地址
- zlen：記錄了壓縮列表包含的節點數量；當這個屬性的值大於 UINT16_MAX(65535)時，節點的真實數量需要遍歷整個壓縮列表才能計算出來。
- entryX：壓縮列表的包含的各個節點，節點的長度由節點儲存的內容決定。
- zlend：特殊值0XFF（十進位制255），用於標記壓縮列表的末端。
壓縮列表是一種為節約記憶體而開發的順序型資料結構，所以在 Redis 裡面壓縮列表被用做列表鍵和雜湊鍵的底層實現之一。
- 當一個列表鍵只包含少量列表項，並且每個列表項要麼就是小整數值，要麼就是長度比較短的字串，那麼Redis就會使用壓縮列表來做列表鍵的底層實現。
- 當一個雜湊鍵只包含少量鍵值對，並且每個鍵值對的鍵和值要麼就是小整數值，要麼就是長度比較短的字串，那麼Redis就會使用壓縮列表來做雜湊鍵的底層實現。
正是利用壓縮列表，不但使得資料非常緊湊而節約記憶體，而且還可以利用它的結構來做到非常簡單的順序遍歷、逆序遍歷，O(1) 複雜度的獲取長度和所佔記憶體大小等等。
6、整數集合 intset 的升級策略
整數集合（intset）是 Redis 用於儲存整數值的集合抽象資料結構，它可以儲存型別為 int16_t、int32_t 或者 int64_t 的整數值，並且保證集合中不會出現重複元素。
我們先看看整數集合的結構：
typeof struct intset{
uint32_t encoding;
uint32_t length;
int8_t contents[];
} intset;
雖然 intset 結構將 contents 屬性宣告為 int8_t型別的陣列，但實際上 contents 陣列並不儲存任何 int8_t 型別的值，contents 陣列的真正型別取決於 encoding 屬性的值。
intset 一開始不會直接使用最大型別來定義陣列，而是利用升級操作，當元素的值達到一定長度時，會重新為陣列分配記憶體空間，並將陣列裡的舊元素的型別進行升級。
這樣做好處：
- 避免錯誤型別，能自適應新新增的新元素的長度。只要是升級了，那麼小於對應的長度的數值都可以存進來，而如果長度不足，大不了再升級一次即可。而且，intset 最多就升級兩次，不用擔心升級次數多而導致效能降低。
- 節約記憶體，只要當需要時才會進行升級操作，這樣可以很好地節省記憶體。
因為整數集合沒有降級操作，所以從另外一個角度看，升級操作其實也會浪費記憶體：如果整數集合裡只有一個數值是 int64_t ，而其他數值都是小於它的，但是整數集合的編碼將還是保持 INTSET_ENC_INT64，就是說，小於 int64_t 的整數還是會用 int64_t 的空間來儲存。
二、單機資料庫實現設計
1、Reactor的I/O多路複用
每當別人問 Redis 為啥這麼快？吐口而出的不是基於記憶體就是基於單執行緒。
Redis 使用基於 Reactor 模式實現的網路通訊，它使用 I/O 多路複用（multiplexing）程式來同時監聽多個套接字，並根據套接字目前執行的任務來為套接字關聯不同的事件處理器。
當被監聽的套接字準備好執行連線應答（accept）、讀取（read）、寫入（write）、關閉（close）等操作時，與操作相對應的檔案事件就會產生，這時檔案事件分派器就會呼叫套接字之前關聯好的事件處理器來處理這些事件。
因為 Redis 是單執行緒的，所以I/O多路複用程式會利用佇列來控制產生事件的套接字的併發；佇列中的套接字以有序、同步、每次一個的方式分派給檔案事件分派器。
多種 I/O 複用機制：
常見的 I/O 複用機制有很多種，例如 select、epoll、evport 和 kqueue 等等。
Redis 對上面的多種 I/O 複用機制都進行了各自的封裝，在程式編譯時會自動選擇系統中效能最高的 I/O 多路複用函式庫來作為 Redis 的 I/O 多路複用程式的底層實現。
2、同步處理的檔案事件和時間事件
我們都知道，檔案事件的發生都是隨機的，因為 Redis 伺服器永遠不可能知道客戶端下次傳送命令是什麼時候，所以程式也不可能一直阻塞著直到發生檔案事件。
畢竟 Redis 是單執行緒的，檔案事件的處理和時間事件的處理都在同一個執行緒裡，如果執行緒被 aeApiPoll 函式一直阻塞著，那麼即使時間事件的時間到了，也得不到資源來執行。
所以 Redis 有這麼一個策略，aeApiPoll 函式的最大阻塞時間由到達時間最接近當前時間的時間事件決定，這個方法既可以避免伺服器對時間事件進行頻繁的輪詢（忙等待），也可以確保 aeApiPoll 函式不會阻塞過長時間。
對檔案事件和時間事件的處理都是同步、有序、原子地執行的，伺服器不會中途中斷事件處理，也不會對事件進行搶佔，因此，不管是檔案事件的處理器，還是時間事件的處理器，它們都會盡可地減少程式的阻塞時間，並在有需要時主動讓出執行權，從而降低造成事件飢餓的可能性。
3、當前時間快取
Redis 伺服器中不少功能是要使用系統的當前時間的，而獲取系統當前時間需要執行一次系統呼叫。
為了減少系統呼叫，提升效能，伺服器狀態（redisServer）中的 unixtime 屬性和 mstime 屬性分別儲存了秒級精度的系統當前 UNIX 時間戳和毫秒級精度的系統當前 UNIX 時間戳；然後 serverCron 函式會每隔 100 毫秒更新一次這兩個屬性。
這兩個時間只會用在對時間精確度要求不高的功能上，例如列印日誌、計算伺服器上線時間等等。
像設定鍵過期時間、新增慢查詢日誌這種需要時間精確度高的功能上，伺服器還是會每次都呼叫系統來獲取。
三、多機資料庫實現設計
1、主從模式 -> 複製演算法優化
Redis 2.8 前的複製功能：
- 從伺服器向主伺服器傳送
SYNC命令。 - 主伺服器收到 SYNC 命令後，後臺生成一個 RDB 檔案（BGSAVE），並使用一個緩衝區記錄從現在開始執行的所有寫命令。
- 當主伺服器的
BGSAVE命令執行完畢，將生成的 RDB 檔案傳送給從伺服器；從伺服器接收並載入這個 RDB 檔案。 - 主伺服器將緩衝區裡的所有寫命令傳送給從伺服器；從伺服器執行這些寫命令。
- 至此，主從伺服器兩者的資料庫將達到一致狀態。
缺點：
假設主從伺服器斷開連線，當從伺服器重新連線上後，又要重新執行一遍同步（sync）操作；但是其實，從伺服器重新連線時，資料庫狀態和主伺服器大致是一樣的，缺少的只是斷開連線過程中，主伺服器接收到的寫命令；每次斷線後都需要重新執行一遍完整的同步操作，這樣會很浪費主伺服器的效能，畢竟 BGSAVE 命令要讀取此時主伺服器完整的資料庫狀態。
Redis 2.8 後對複製演算法進行了很大的優化：
利用 PSYNC 命令代替 SYNC 命令，將複製操作分為完整重同步和部分重同步。只有當從伺服器第一次複製或斷開時間過長時，才會執行完整重同步，而從伺服器短時間斷開重連後，只需要將自己的 offset（複製偏移量）傳送給主伺服器，主伺服器會根據從伺服器的 offset 和自己的 offset，然後從複製積壓緩衝區裡將從伺服器丟失的寫命令傳送給從伺服器，從伺服器只要接收並執行這些寫命令，就可以將資料庫更新至主伺服器當前所處的狀態。
2、主從模式 -> 心跳檢測
在命令傳播階段，從伺服器預設會以每秒一次的頻率，向主伺服器傳送命令：REPLCONF ACK <replication_offset>，其中 replication_offet 是從伺服器當前的複製偏移量。
心跳檢測的三大作用：
-
心跳檢測不但可以檢測主從伺服器之間的網路狀態。
-
從伺服器還會將它的複製偏移量傳送給主伺服器，讓主伺服器檢查從伺服器的命令是否丟失了。
-
心跳檢測還能輔助實現
min-slaves配置選項：
min-slaves-to-write 3
min-slaves-max-lag 10
解釋：那麼在從伺服器的數量少於3個，或者三個從伺服器的延遲（lag）值都大於或等於10秒時，主伺服器將拒絕執行寫命令，這裡的延遲值就是上面提到的INFO replication命令的lag值。
3、哨兵模式的訂閱連線設計
Sentinel 不但會與主從伺服器建立命令連線，還會建立訂閱連線。
在預設情況下，Sentinel會以每兩秒一次的頻率，通過命令連線向所有被監視的主伺服器和從伺服器傳送 PUBLISH 命令，命令附帶的是 Sentinel 本身的資訊和所監聽的主伺服器的資訊；接著接收到此命令的主從伺服器會向 _sentinel_:hello 頻道傳送這些資訊。
而其他所有都是監聽此主從伺服器的 Sentinel 可以通過訂閱連線獲取到上面的資訊。
這也就是說，對於每個與 Sentinel 的伺服器，Sentinel 既通過命令連線向伺服器的 __sentinel__:hello 頻道傳送資訊（PUBLISH），又通過訂閱連線從伺服器的 __sentinel__:hello 頻道接收資訊（SUBSCRIBE）。
通過這種方式，監聽同一個主伺服器的 Sentinel 們可以互相知道彼此的存在，並且可以根據頻道訊息更新主伺服器例項結構（sentinelRedisInstance）的 sentinels 字典，還可藉此與其他 Sentinel 建立命令連線，方便之後關於主伺服器下線檢查、選舉領頭 Sentinel 等等的通訊。
4、叢集模式中的 Gossip協議
Redis 叢集中的各個節點通過 Gossip 協議來交換各自關於不同節點的狀態資訊，其中 Gossip 協議由 MEET、PING、PONG 三種訊息實現，這三種訊息的正文都由兩個 cluster.h/clusterMsgDataGossip 結構組成。
利用 Gossip 協議，可以使得叢集中節點更新的資訊像病毒一樣擴散，這樣不但擴散速度快，而且不需要每個節點之間都傳送一次訊息才能同步叢集中最新的資訊。
四、總結
至此，我自己能想到的使得 Redis 效能優越的設計都在這裡了。當然了，它的厲害之處遠遠不止這些~
大家都知道，使用 Redis 是非常簡單的，來來去去就幾個命令，但是當你深入 Redis 底層的設計和實現，你會發現，這真的是一個非常值得大家深究的開源中介軟體！！！
參考資料：《Redis 設計與實現》，這是一本寫得非常好的書，通俗易懂~