您好,登錄后才能下訂單哦!
今天給大家介紹的是KeyDB,KeyDB項目是從redis fork出來的分支。眾所周知redis是一個單線程的kv內(nèi)存存儲系統(tǒng),而KeyDB在100%兼容redis API的情況下將redis改造成多線程。
上次也跟大家說了,redis多線程正式版將在今年底發(fā)布,大家拭目以待。
KeyDB將redis原來的主線程拆分成了主線程和worker線程。每個worker線程都是io線程,負(fù)責(zé)監(jiān)聽端口,accept請求,讀取數(shù)據(jù)和解析協(xié)議。如圖所示:
image
KeyDB使用了SO_REUSEPORT特性,多個線程可以綁定監(jiān)聽同個端口。每個worker線程做了cpu綁核,讀取數(shù)據(jù)也使用了SO_INCOMING_CPU特性,指定cpu接收數(shù)據(jù)。解析協(xié)議之后每個線程都會去操作內(nèi)存中的數(shù)據(jù),由一把全局鎖來控制多線程訪問內(nèi)存數(shù)據(jù)。主線程其實(shí)也是一個worker線程,包括了worker線程的工作內(nèi)容,同時也包括只有主線程才可以完成的工作內(nèi)容。在worker線程數(shù)組中下標(biāo)為0的就是主線程。主線程的主要工作在實(shí)現(xiàn)serverCron,包括:
處理統(tǒng)計
客戶端鏈接管理
db數(shù)據(jù)的resize和reshard
處理aof
replication主備同步
cluster模式下的任務(wù)
在redis中所有鏈接管理都是在一個線程中完成的。在KeyDB的設(shè)計中,每個worker線程負(fù)責(zé)一組鏈接,所有的鏈接插入到本線程的鏈接列表中維護(hù)。鏈接的產(chǎn)生、工作、銷毀必須在同個線程中。每個鏈接新增一個字段
int iel; /* the event loop index we're registered with */用來表示鏈接屬于哪個線程接管。KeyDB維護(hù)了三個關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)做鏈接管理:
clients_pending_write:線程專屬的鏈表,維護(hù)同步給客戶鏈接發(fā)送數(shù)據(jù)的隊列
clients_pending_asyncwrite:線程專屬的鏈表,維護(hù)異步給客戶鏈接發(fā)送數(shù)據(jù)的隊列
clients_to_close:全局鏈表,維護(hù)需要異步關(guān)閉的客戶鏈接
分成同步和異步兩個隊列,是因?yàn)閞edis有些聯(lián)動api,比如pub/sub,pub之后需要給sub的客戶端發(fā)送消息,pub執(zhí)行的線程和sub的客戶端所在線程不是同一個線程,為了處理這種情況,KeyDB將需要給非本線程的客戶端發(fā)送數(shù)據(jù)維護(hù)在異步隊列中。同步發(fā)送的邏輯比較簡單,都是在本線程中完成,以下圖來說明如何同步給客戶端發(fā)送數(shù)據(jù):
image
如上文所提到的,一個鏈接的創(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事件。專屬線程在處理管道消息時將對應(yīng)的請求添加到寫事件中,如圖所示:
image
redis有些關(guān)閉客戶端的請求并非完全是在鏈接所在的線程執(zhí)行關(guān)閉,所以在這里維護(hù)了一個全局的異步關(guān)閉鏈表。
image
KeyDB實(shí)現(xiàn)了一套類似spinlock的鎖機(jī)制,稱之為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;?//當(dāng)前解鎖的線程id?volatile?int?m_depth;?//當(dāng)前線程重復(fù)加鎖的次數(shù)};
使用原子操作__atomic_load_2,__atomic_fetch_add,__atomic_compare_exchange來通過比較m_active=m_avail判斷是否可以獲取鎖。fastlock提供了兩種獲取鎖的方式:
try_lock:一次獲取失敗,直接返回
lock:忙等,每1024 * 1024次忙等后使用sched_yield 主動交出cpu,挪到cpu的任務(wù)末尾等待執(zhí)行。
在KeyDB中將try_lock和事件結(jié)合起來,來避免忙等的情況發(fā)生。每個客戶端有一個專屬的lock,在讀取客戶端數(shù)據(jù)之前會先嘗試加鎖,如果失敗,則退出,因?yàn)閿?shù)據(jù)還未讀取,所以在下個epoll_wait處理事件循環(huán)中可以再次處理。
image
KeyDB實(shí)現(xiàn)了多活的機(jī)制,每個replica可設(shè)置成可寫非只讀,replica之間互相同步數(shù)據(jù)。主要特性有:
每個replica有個uuid標(biāo)志,用來去除環(huán)形復(fù)制
新增加rreplay API,將增量命令打包成rreplay命令,帶上本地的uuid
key,value加上時間戳版本號,作為沖突校驗(yàn),如果本地有相同的key且時間戳版本號大于同步過來的數(shù)據(jù),新寫入失敗。采用當(dāng)前時間戳向左移20位,再加上后44位自增的方式來獲取key的時間戳版本號。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。