共計(jì) 2154 個(gè)字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。
這篇文章主要介紹了 KeyDB 線程模型是怎樣的的相關(guān)知識(shí)，內(nèi)容詳細(xì)易懂，操作簡單快捷，具有一定借鑒價(jià)值，相信大家閱讀完這篇 KeyDB 線程模型是怎樣的文章都會(huì)有所收獲，下面我們一起來看看吧。
線程模型
KeyDB 將 Redis 原來的主線程拆分成了主線程和 worker 線程。每個(gè) worker 線程都是 io 線程，負(fù)責(zé)監(jiān)聽端口，accept 請求，讀取數(shù)據(jù)和解析協(xié)議。如圖所示：
KeyDB 使用了 SO_REUSEPORT 特性，多個(gè)線程可以綁定監(jiān)聽同個(gè)端口。
每個(gè) worker 線程做了 cpu 綁核，讀取數(shù)據(jù)也使用了 SO_INCOMING_CPU 特性，指定 cpu 接收數(shù)據(jù)。
解析協(xié)議之后每個(gè)線程都會(huì)去操作內(nèi)存中的數(shù)據(jù)，由一把全局鎖來控制多線程訪問內(nèi)存數(shù)據(jù)。
主線程其實(shí)也是一個(gè) worker 線程，包括了 worker 線程的工作內(nèi)容，同時(shí)也包括只有主線程才可以完成的工作內(nèi)容。在 worker 線程數(shù)組中下標(biāo)為 0 的就是主線程。
主線程的主要工作在實(shí)現(xiàn) serverCron，包括：
處理統(tǒng)計(jì)
客戶端鏈接管理
db 數(shù)據(jù)的 resize 和 reshard
處理 aof
replication 主備同步
cluster 模式下的任務(wù)
鏈接管理
在 Redis 中所有鏈接管理都是在一個(gè)線程中完成的。在 KeyDB 的設(shè)計(jì)中，每個(gè) worker 線程負(fù)責(zé)一組鏈接，所有的鏈接插入到本線程的鏈接列表中維護(hù)。鏈接的產(chǎn)生、工作、銷毀必須在同個(gè)線程中。每個(gè)鏈接新增一個(gè)字段
int iel; /* the event loop index we re registered with */
用來表示鏈接屬于哪個(gè)線程接管。
KeyDB 維護(hù)了三個(gè)關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)做鏈接管理：
clients_pending_write：線程專屬的鏈表，維護(hù)同步給客戶鏈接發(fā)送數(shù)據(jù)的隊(duì)列
clients_pending_asyncwrite：線程專屬的鏈表，維護(hù)異步給客戶鏈接發(fā)送數(shù)據(jù)的隊(duì)列
clients_to_close：全局鏈表，維護(hù)需要異步關(guān)閉的客戶鏈接
分成同步和異步兩個(gè)隊(duì)列，是因?yàn)?redis 有些聯(lián)動(dòng) api，比如 pub/sub，pub 之后需要給 sub 的客戶端發(fā)送消息，pub 執(zhí)行的線程和 sub 的客戶端所在線程不是同一個(gè)線程，為了處理這種情況，KeyDB 將需要給非本線程的客戶端發(fā)送數(shù)據(jù)維護(hù)在異步隊(duì)列中。
同步發(fā)送的邏輯比較簡單，都是在本線程中完成，以下圖來說明如何同步給客戶端發(fā)送數(shù)據(jù)：
如上文所提到的，一個(gè)鏈接的創(chuàng)建、接收數(shù)據(jù)、發(fā)送數(shù)據(jù)、釋放鏈接都必須在同個(gè)線程執(zhí)行。異步發(fā)送涉及到兩個(gè)線程之間的交互。KeyDB 通過管道在兩個(gè)線程中傳遞消息：
int fdCmdWrite; // 寫管道
int fdCmdRead; // 讀管道
本地線程需要異步發(fā)送數(shù)據(jù)時(shí)，先檢查 client 是否屬于本地線程，非本地線程獲取到 client 專屬的線程 ID，之后給專屬的線程管到發(fā)送 AE_ASYNC_OP::CreateFileEvent 的操作，要求添加寫 socket 事件。專屬線程在處理管道消息時(shí)將對(duì)應(yīng)的請求添加到寫事件中，如圖所示：
Redis 有些關(guān)閉客戶端的請求并非完全是在鏈接所在的線程執(zhí)行關(guān)閉，所以在這里維護(hù)了一個(gè)全局的異步關(guān)閉鏈表。
鎖機(jī)制
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 主動(dòng)交出 cpu，挪到 cpu 的任務(wù)末尾等待執(zhí)行。
在 KeyDB 中將 try_lock 和事件結(jié)合起來，來避免忙等的情況發(fā)生。每個(gè)客戶端有一個(gè)專屬的 lock，在讀取客戶端數(shù)據(jù)之前會(huì)先嘗試加鎖，如果失敗，則退出，因?yàn)閿?shù)據(jù)還未讀取，所以在下個(gè) epoll_wait 處理事件循環(huán)中可以再次處理。
Active-Replica
KeyDB 實(shí)現(xiàn)了多活的機(jī)制，每個(gè) replica 可設(shè)置成可寫非只讀，replica 之間互相同步數(shù)據(jù)。主要特性有：
每個(gè) replica 有個(gè) uuid 標(biāo)志，用來去除環(huán)形復(fù)制
新增加 rreplay API，將增量命令打包成 rreplay 命令，帶上本地的 uuid
key，value 加上時(shí)間戳版本號(hào)，作為沖突校驗(yàn)，如果本地有相同的 key 且時(shí)間戳版本號(hào)大于同步過來的數(shù)據(jù)，新寫入失敗。采用當(dāng)前時(shí)間戳向左移 20 位，再加上后 44 位自增的方式來獲取 key 的時(shí)間戳版本號(hào)。
關(guān)于“KeyDB 線程模型是怎樣的”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對(duì)“KeyDB 線程模型是怎樣的”知識(shí)都有一定的了解，大家如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。
