KeyDB線程模型是怎樣的

這篇文章主要介紹了KeyDB線程模型是怎樣的的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇KeyDB線程模型是怎樣的文章都會有所收獲，下面我們一起來看看吧。

線程模型

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

KeyDB使用了SO_REUSEPORT特性，多個線程可以綁定監聽同個端口。

每個worker線程做了cpu綁核，讀取數據也使用了SO_INCOMING_CPU特性，指定cpu接收數據。

解析協議之后每個線程都會去操作內存中的數據，由一把全局鎖來控制多線程訪問內存數據。

主線程其實也是一個worker線程，包括了worker線程的工作內容，同時也包括只有主線程才可以完成的工作內容。在worker線程數組中下標為0的就是主線程。

主線程的主要工作在實現serverCron，包括：

• 處理統計

• 客戶端鏈接管理

• db數據的resize和reshard

• 處理aof

• replication主備同步

• cluster模式下的任務

鏈接管理

在Redis中所有鏈接管理都是在一個線程中完成的。在KeyDB的設計中，每個worker線程負責一組鏈接，所有的鏈接插入到本線程的鏈接列表中維護。鏈接的產生、工作、銷毀必須在同個線程中。每個鏈接新增一個字段

int iel; /* the event loop index we're registered with */

用來表示鏈接屬于哪個線程接管。

KeyDB維護了三個關鍵的數據結構做鏈接管理：

• clients_pending_write：線程專屬的鏈表，維護同步給客戶鏈接發送數據的隊列

• clients_pending_asyncwrite：線程專屬的鏈表，維護異步給客戶鏈接發送數據的隊列

• clients_to_close：全局鏈表，維護需要異步關閉的客戶鏈接

分成同步和異步兩個隊列，是因為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來通過比較m_active=m_avail判斷是否可以獲取鎖。

fastlock提供了兩種獲取鎖的方式：

• try_lock：一次獲取失敗，直接返回

• lock：忙等，每1024 * 1024次忙等后使用sched_yield 主動交出cpu，挪到cpu的任務末尾等待執行。

• 
  

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

Active-Replica

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

• 每個replica有個uuid標志，用來去除環形復制

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

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

關于“KeyDB線程模型是怎樣的”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“KeyDB線程模型是怎樣的”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。