青出於藍 | 比Redis快5倍的KeyDB - ⎝⎛CodingNote.cc ⎞⎠

青出於藍 | 比Redis快5倍的KeyDB

2019 年 10 月 31 日
筆記

Redis是單執行緒的，而KeyDB是Redis的高性能分支版本，專註於多執行緒，記憶體效率和高吞吐量。除了多執行緒之外，在相同的硬體上，KeyDB每秒執行的查詢數量是Redis的兩倍，延遲降低60％。

KeyDB與Redis協議，模組和腳本完全兼容。這包括對事務的完全支援和腳本的原子執行。

KeyDB項目是從Redis fork出來的分支。眾所周知Redis是一個單執行緒的kv記憶體存儲系統，而KeyDB在100%兼容Redis API的情況下將Redis改造成多執行緒。

項目git地址：

https://github.com/JohnSully/KeyDB

網上公開的技術細節比較少，本文基本是通過閱讀源碼總結出來的，如有錯漏之處歡迎指正。

多執行緒架構

執行緒模型

KeyDB將Redis原來的主執行緒拆分成了主執行緒和worker執行緒。每個worker執行緒都是io執行緒，負責監聽埠，accept請求，讀取數據和解析協議。如圖所示：

KeyDB使用了SOREUSEPORT特性，多個執行緒可以綁定監聽同個埠。每個worker執行緒做了cpu綁核，讀取數據也使用了SOINCOMING_CPU特性，指定cpu接收數據。解析協議之後每個執行緒都會去操作記憶體中的數據，由一把全局鎖來控制多執行緒訪問記憶體數據。主執行緒其實也是一個worker執行緒，包括了worker執行緒的工作內容，同時也包括只有主執行緒才可以完成的工作內容。在worker執行緒數組中下標為0的就是主執行緒。主執行緒的主要工作在實現serverCron，包括：

1、處理統計

2、客戶端鏈接管理

3、db數據的resize和reshard

4、處理aof

5、replication主備同步

6、cluster模式下的任務

鏈接管理

在Redis中所有鏈接管理都是在一個執行緒中完成的。在KeyDB的設計中，每個worker執行緒負責一組鏈接，所有的鏈接插入到本執行緒的鏈接列表中維護。鏈接的產生、工作、銷毀必須在同個執行緒中。每個鏈接新增一個欄位 intiel;/* the event loop index we're registered with */用來表示鏈接屬於哪個執行緒接管。KeyDB維護了三個關鍵的數據結構做鏈接管理：

1、clientspendingwrite：執行緒專屬的鏈表，維護同步給客戶鏈接發送數據的隊列

2、clientspendingasyncwrite：執行緒專屬的鏈表，維護非同步給客戶鏈接發送數據的隊列

3、clientstoclose：全局鏈表，維護需要非同步關閉的客戶鏈接

分成同步和非同步兩個隊列，是因為Redis有些聯動api，比如pub/sub，pub之後需要給sub的客戶端發送消息，pub執行的執行緒和sub的客戶端所在執行緒不是同一個執行緒，為了處理這種情況，KeyDB將需要給非本執行緒的客戶端發送數據維護在非同步隊列中。同步發送的邏輯比較簡單，都是在本執行緒中完成，以下圖來說明如何同步給客戶端發送數據：

如上文所提到的，一個鏈接的創建、接收數據、發送數據、釋放鏈接都必須在同個執行緒執行。非同步發送涉及到兩個執行緒之間的交互。KeyDB通過管道在兩個執行緒中傳遞消息：

int fdCmdWrite; //寫管道  int fdCmdRead; //讀管道

本地執行緒需要非同步發送數據時，先檢查client是否屬於本地執行緒，非本地執行緒獲取到client專屬的執行緒ID，之後給專屬的執行緒管到發送 AE_ASYNC_OP::CreateFileEvent的操作，要求添加寫socket事件。專屬執行緒在處理管道消息時將對應的請求添加到寫事件中，如圖所示：

Redis有些關閉客戶端的請求並非完全是在鏈接所在的執行緒執行關閉，所以在這裡維護了一個全局的非同步關閉鏈表。

鎖機制

KeyDB實現了一套類似spinlock的鎖機制，稱之為fastlock。fastlock的主要數據結構有：

struct ticket  {      uint16_t m_active;  //解鎖+1      uint16_t m_avail;  //加鎖+1  };  struct fastlock  {      volatile struct ticket m_ticket;        volatile int m_pidOwner; //當前解鎖的執行緒id      volatile int m_depth; //當前執行緒重複加鎖的次數  };

使用原子操作 __atomic_load_2，__atomic_fetch_add，__atomic_compare_exchange來通過比較mactive=mavail判斷是否可以獲取鎖。fastlock提供了兩種獲取鎖的方式：

1、trylock：一次獲取失敗，直接返回

2、lock：忙等，每1024 * 1024次忙等後使用schedyield 主動交出cpu，挪到cpu的任務末尾等待執行。

在KeyDB中將trylock和事件結合起來，來避免忙等的情況發生。每個客戶端有一個專屬的lock，在讀取客戶端數據之前會先嘗試加鎖，如果失敗，則退出，因為數據還未讀取，所以在下個epollwait處理事件循環中可以再次處理。

Active-Replica

KeyDB實現了多活的機制，每個replica可設置成可寫非只讀，replica之間互相同步數據。主要特性有：

1、每個replica有個uuid標誌，用來去除環形複製

2、新增加rreplay API，將增量命令打包成rreplay命令，帶上本地的uuid

3、key，value加上時間戳版本號，作為衝突校驗，如果本地有相同的key且時間戳版本號大於同步過來的數據，新寫入失敗。採用當前時間戳向左移20位，再加上後44位自增的方式來獲取key的時間戳版本號。