比Redis快5倍的中間件,為啥這么快?
作者：羽洵
原文鏈接：
http://suo.im/4Cx7u
今天給大家介紹的是KeyDB，KeyDB項目是從redis fork出來的分支。眾所周知redis是一個單線程的kv內(nèi)存存儲系統(tǒng)，而KeyDB在100%兼容redis API的情況下將redis改造成多線程。
上次也跟大家說了，redis多線程正式版將在今年底發(fā)布，大家拭目以待
處理統(tǒng)計
客戶端鏈接管理
db數(shù)據(jù)的resize和reshard
處理aof
replication主備同步
cluster模式下的任務
int iel; /* the event loop index we're registered with */
用來表示鏈接屬于哪個線程接管。KeyDB維護了三個關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)做鏈接管理：- clients_pending_write：線程專屬的鏈表，維護同步給客戶鏈接發(fā)送數(shù)據(jù)的隊列
- clients_pending_asyncwrite：線程專屬的鏈表，維護異步給客戶鏈接發(fā)送數(shù)據(jù)的隊列
- clients_to_close：全局鏈表，維護需要異步關(guān)閉的客戶鏈接
如上文所提到的，一個鏈接的創(chuàng)建、接收數(shù)據(jù)、發(fā)送數(shù)據(jù)、釋放鏈接都必須在同個線程執(zhí)行。異步發(fā)送涉及到兩個線程之間的交互。KeyDB通過管道在兩個線程中傳遞消息：
int?fdCmdWrite; //寫管道
int?fdCmdRead; //讀管道本地線程需要異步發(fā)送數(shù)據(jù)時，先檢查client是否屬于本地線程，非本地線程獲取到client專屬的線程ID，之后給專屬的線程管到發(fā)送AE_ASYNC_OP::CreateFileEvent的操作，要求添加寫socket事件。專屬線程在處理管道消息時將對應的請求添加到寫事件中，如圖所示：
redis有些關(guān)閉客戶端的請求并非完全是在鏈接所在的線程執(zhí)行關(guān)閉，所以在這里維護了一個全局的異步關(guān)閉鏈表。
KeyDB實現(xiàn)了一套類似spinlock的鎖機制，稱之為fastlock。
fastlock的主要數(shù)據(jù)結(jié)構(gòu)有：
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; //當前線程重復加鎖的次數(shù)
};使用原子操作__atomic_load_2，__atomic_fetch_add，__atomic_compare_exchange來通過比較m_active=m_avail判斷是否可以獲取鎖。
fastlock提供了兩種獲取鎖的方式：
try_lock：一次獲取失敗，直接返回
lock：忙等，每1024 * 1024次忙等后使用sched_yield 主動交出cpu，挪到cpu的任務末尾等待執(zhí)行。
在KeyDB中將try_lock和事件結(jié)合起來，來避免忙等的情況發(fā)生。每個客戶端有一個專屬的lock，在讀取客戶端數(shù)據(jù)之前會先嘗試加鎖，如果失敗，則退出，因為數(shù)據(jù)還未讀取，所以在下個epoll_wait處理事件循環(huán)中可以再次處理。
KeyDB實現(xiàn)了多活的機制，每個replica可設置成可寫非只讀，replica之間互相同步數(shù)據(jù)。主要特性有：
每個replica有個uuid標志，用來去除環(huán)形復制
新增加rreplay API，將增量命令打包成rreplay命令，帶上本地的uuid
key，value加上時間戳版本號，作為沖突校驗，如果本地有相同的key且時間戳版本號大于同步過來的數(shù)據(jù)，新寫入失敗。采用當前時間戳向左移20位，再加上后44位自增的方式來獲取key的時間戳版本號。
推薦閱讀：
喜歡我可以給我設為星標哦
好文章，我?在看?
