來源：suo.im/4Cx7ujava
線程模型web
連接管理redis
鎖機制編程
Active-Replica後端
今天給你們介紹的是KeyDB，KeyDB項目是從redis fork出來的分支。衆所周知redis是一個單線程的kv內存存儲系統，而KeyDB在100%兼容redis API的狀況下將redis改形成多線程。api
上次也跟你們說了，redis多線程正式版將在今年末發佈，你們拭目以待數組
線程模型
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經過管道在兩個線程中傳遞消息。
本地線程須要異步發送數據時，先檢查client是否屬於本地線程，非本地線程獲取到client專屬的線程ID，以後給專屬的線程管到發送AE_ASYNC_OP::CreateFileEvent的操做，要求添加寫socket事件。專屬線程在處理管道消息時將對應的請求添加到寫事件中，如圖所示：
redis有些關閉客戶端的請求並不是徹底是在連接所在的線程執行關閉，因此在這裏維護了一個全局的異步關閉鏈表。
鎖機制
KeyDB實現了一套相似spinlock的鎖機制，稱之爲fastlock。
fastlock的主要數據結構有：
int fdCmdWrite; //寫管道
int fdCmdRead; //讀管道
使用原子操做__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的時間戳版本號。
長按訂閱更多精彩▼
若有收穫，點個在看，誠摯感謝
本文分享自微信公衆號 - Java後端編程（java_hdbc）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。