大家都知道：由于單機(jī)數(shù)據(jù)庫(kù)在數(shù)據(jù)規(guī)模、并發(fā)訪問量等方面存在瓶頸，無(wú)法滿足大規(guī)模應(yīng)用的需求。因此才有了把數(shù)據(jù)切割分片，分布存儲(chǔ)分布處理在多個(gè)節(jié)點(diǎn)上的數(shù)據(jù)庫(kù)，也就是分布式數(shù)據(jù)庫(kù)的由來(lái)。

而為了實(shí)現(xiàn)數(shù)據(jù)庫(kù)的高可用，又有了多副本的概念，副本之間的數(shù)據(jù)需要用特定算法保持一致，從而可以隨時(shí)切換身份對(duì)外提供高可用服務(wù)——TDengine 就是一款這樣的分布式時(shí)序數(shù)據(jù)庫(kù)（Time Series Database）。

選擇什么樣的一致性或者共識(shí)算法，可以直接代表一款數(shù)據(jù)庫(kù)的產(chǎn)品思路。

一. Why RAFT

在 3.0 之前，結(jié)合時(shí)序數(shù)據(jù)的十大特點(diǎn)（《我為何要開發(fā)一個(gè)專用的物聯(lián)網(wǎng)大數(shù)據(jù)平臺(tái)，還開源它？》），我們針對(duì)性地創(chuàng)造了多項(xiàng)時(shí)序數(shù)據(jù)處理專利，使得 TDengine 對(duì)大時(shí)序數(shù)據(jù)的處理能力與當(dāng)時(shí)世界上的同類型產(chǎn)品拉開了巨大的性能優(yōu)勢(shì)。而在 3.0 ，我們則引入了標(biāo)準(zhǔn)的 RAFT 算法，以更通用標(biāo)準(zhǔn)的實(shí)現(xiàn)方式，去適用更廣泛的應(yīng)用場(chǎng)景。

通過(guò) RAFT 算法所保障數(shù)據(jù)一致的多個(gè)節(jié)點(diǎn)，被稱為一個(gè) RAFT 組(group)；這些節(jié)點(diǎn)，被稱為這個(gè)RAFT組的成員（member）節(jié)點(diǎn)。

在 RAFT 組中，每個(gè)節(jié)點(diǎn)都維護(hù)了一份連續(xù)的日志（Log），用于記錄數(shù)據(jù)寫入、變更、或刪除等操作的所有指令。日志是由一系列有序的日志條目 (Log Entry) 組成，每個(gè) Log Entry 都有唯一的編號(hào)（Index），用于標(biāo)識(shí)日志協(xié)商或執(zhí)行的進(jìn)度。

此外，每個(gè) RAFT 節(jié)點(diǎn)都有自己的角色，它們可以是 Follower（跟隨者）、Candidate（候選人）、Leader（領(lǐng)導(dǎo)者）。

二. Raft in TDengine

對(duì)于 TDengine 來(lái)說(shuō)，一個(gè)虛擬節(jié)點(diǎn)組（vgroup）就構(gòu)成了一個(gè) RAFT 組；而這個(gè)虛擬節(jié)點(diǎn)組的虛擬數(shù)據(jù)節(jié)點(diǎn)（vnode），便是該 RAFT 組的成員節(jié)點(diǎn)，我們也稱之為副本（全部管理節(jié)點(diǎn)（mnode）也構(gòu)成一個(gè) RAFT 組）。Leader 角色的 vnode/mnode 按照協(xié)議機(jī)制負(fù)責(zé)提供讀寫服務(wù)，在容忍故障節(jié)點(diǎn)不超過(guò)半數(shù)的情況下保證集群的高可用性；此外，即使發(fā)生了節(jié)點(diǎn)重啟及 Leader 節(jié)點(diǎn)重新選舉等事件后，RAFT 也能夠始終保證新產(chǎn)生的 Leader 節(jié)點(diǎn)可以提供已經(jīng)寫入成功的全部完整數(shù)據(jù)的讀寫服務(wù)。

對(duì)于 TDengine 來(lái)說(shuō)，每一次對(duì)數(shù)據(jù)庫(kù)的變更請(qǐng)求（ 比如 insert into test.d1 values(now,1,2,3) ），都對(duì)應(yīng)一個(gè) RAFT 日志記錄（Log Entry）。在持續(xù)寫入數(shù)據(jù)的過(guò)程中，TDengine 會(huì)按照協(xié)議機(jī)制在每個(gè)成員節(jié)點(diǎn)上產(chǎn)生完全相同的日志記錄，并且以相同的順序執(zhí)行數(shù)據(jù)變更操作，以 WAL 的形式，存儲(chǔ)在數(shù)據(jù)文件目錄中。

而每一個(gè) Log Entry 攜帶的 Index ，就代表此前講過(guò)的數(shù)據(jù)或數(shù)據(jù)變更的版本號(hào)（https://mp.weixin.qq.com/s/F-zWYr3FVqhpbfTqzD5PwA）。

當(dāng)一個(gè)數(shù)據(jù)寫入請(qǐng)求發(fā)出后，必定至少過(guò)半數(shù)節(jié)點(diǎn)上完成寫入才會(huì)把“寫入成功”返回給客戶端。這部分涉及 Log entry 的兩種重要的狀態(tài)，committed 和 applied。

對(duì)應(yīng)到 TDengine 中，只有當(dāng)過(guò)半數(shù)的節(jié)點(diǎn)把該條 SQL 的寫入信息追加到文件系統(tǒng)上的 WAL（即圖中的步驟 2），并且收到確認(rèn)消息之后，這條 Log entry 才會(huì)被 Leader 認(rèn)為是安全的。此時(shí)該日志進(jìn)入 committed 狀態(tài)，并通知 Follower 節(jié)點(diǎn)，完成數(shù)據(jù)的插入（即圖中的步驟 4），隨后該 Log Entry 便被標(biāo)記為 applied 的狀態(tài)。

applied——表示數(shù)據(jù)變更已經(jīng)被應(yīng)用，即該 SQL 執(zhí)行完畢。

數(shù)據(jù)的整體寫入流程可以參考官方文檔?https://docs.taosdata.com/tdinternal/arch/。如果需要更多了解 RAFT 細(xì)節(jié)可以參考論文《 In Search of an Understandable Consensus Algorithm?》

三. 注意事項(xiàng)

對(duì)于用戶而言，數(shù)據(jù)的同步方式其實(shí)是無(wú)需感知的，大家只需要關(guān)心最終結(jié)果即可。但是關(guān)于選主流程大家有必要了解一些，因?yàn)樗婕暗椒?wù)的壓力負(fù)載是否均衡，以及到遇到突發(fā)情況后解決問題的思路。

在 RAFT 的標(biāo)準(zhǔn)實(shí)現(xiàn)下，每個(gè)節(jié)點(diǎn)都擁有隨機(jī)的選舉超時(shí)時(shí)間（election timeout），當(dāng)任意一個(gè) Follower 超過(guò)這個(gè)時(shí)間沒有收到 Leader 發(fā)來(lái)的心跳后，便會(huì)變成 Candidate 并發(fā)起申請(qǐng)成為 Leader 的選舉請(qǐng)求。

可見，每一個(gè) Vgroup 的選舉結(jié)果都完全隨機(jī)的，所以這樣會(huì)低概率出現(xiàn)很多 Leader Vnode 集中在某一個(gè)節(jié)點(diǎn)的場(chǎng)景，比如在集群?jiǎn)?dòng)時(shí)、滾動(dòng)升級(jí)時(shí)（企業(yè)版）。由于 RAFT 的讀寫全部只能由 Leader 節(jié)點(diǎn)來(lái)提供（2.0 版本 TDengine 的 Follower 也可提供查詢服務(wù)），因此這會(huì)導(dǎo)致單個(gè)節(jié)點(diǎn)的工作壓力較大。

為了優(yōu)化這種特殊情況，企業(yè)版 TDengine 提供了一種簡(jiǎn)便易用的命令，能夠使集群的負(fù)載再次實(shí)現(xiàn)均衡。

balance vgroup Leader;

開源版則可以通過(guò)重啟服務(wù)重新選主刷新選舉結(jié)果。（相比 2.0 版本，優(yōu)化后的 3.0 即便是體量很大的集群也可以迅速啟停）

此外，由于 RAFT 的選舉流程規(guī)定只需得到半數(shù)以上節(jié)點(diǎn)的投票就可以選出 Leader，所以在 3.0 版本，原則上講，只需要半數(shù)以上節(jié)點(diǎn)正常便可以提供服務(wù)。（2.0 需要節(jié)點(diǎn)全部啟動(dòng)才可從無(wú)到有選出 Leader ，后續(xù)才會(huì)按照半數(shù)以上的多數(shù)派原則提供高可用服務(wù)）

四. 常見問題：

問題 1 ：“Sync leader is unreachable”（3.0.3.1 版本之前，該錯(cuò)誤碼為 sync not Leader ）

該報(bào)錯(cuò)的具體邏輯是：由于 RAFT 要求只有 Leader 才可以提供讀寫服務(wù)，一個(gè)請(qǐng)求發(fā)現(xiàn)自己訪問的 vnode/mnode 不是 Leader 后，會(huì)把請(qǐng)求重定向到新的 vnode/mnode 上 。 如果最終還是沒有找到Leader 才會(huì)返回客戶端錯(cuò)誤： “Sync leader is unreachable ”，所以本質(zhì)上這個(gè)報(bào)錯(cuò)是由于 Leader 不存在導(dǎo)致的。

問題現(xiàn)象及處理思路：

1. 數(shù)據(jù)庫(kù)/mnode 在沒有設(shè)置 3 副本的情況下出現(xiàn)故障：這時(shí)需要打開debugFlag 143 , 生成高級(jí)別日志，通過(guò)日志信息判斷問題所在，或者檢查硬件。
   
2. 多副本情況無(wú)法選出 Leader ：同樣需要打開debugFlag 143 , 生成高級(jí)別日志，通過(guò)日志信息判斷問題所在，或者檢查硬件。
   
3. 數(shù)據(jù)庫(kù)主程序出現(xiàn)bug導(dǎo)致程序無(wú)法啟動(dòng)，因此無(wú)法選出 Leader ：這種情況需要通過(guò)微信群或 github 聯(lián)系官方團(tuán)隊(duì)協(xié)助處理。

除此之外，但凡在日志中發(fā)現(xiàn) “not leader ” 相關(guān)字樣的報(bào)錯(cuò)信息，都可以按照上述思路排查。

常見問題 2 : Sync leader is restoring。

該報(bào)錯(cuò)的具體邏輯是：假如數(shù)據(jù)庫(kù)節(jié)點(diǎn)出現(xiàn)了斷電，或其他原因?qū)е聰?shù)據(jù)庫(kù)進(jìn)程異常中止。這樣內(nèi)存中的數(shù)便會(huì)被清空，數(shù)據(jù)庫(kù)需要把已經(jīng)寫入磁盤的 WAL 數(shù)據(jù)再次執(zhí)行，使內(nèi)存恢復(fù)到異常發(fā)生之前的狀態(tài)。（上圖紅色箭頭部分）

這個(gè)時(shí)候，該 vnode 便處于 restoring 的狀態(tài)，需要完全恢復(fù)后才可以正常提供服務(wù)，在恢復(fù)完成之前如果訪問了這個(gè) vnode 數(shù)據(jù)就會(huì)報(bào)錯(cuò) “Sync leader is restoring”。

通常我們不認(rèn)為這是一個(gè)異常情況，而是數(shù)據(jù)庫(kù)的正?；謴?fù)行為，此時(shí)我們可以觀察日志中該條輸出的 “items”，直到歸 0 即可恢復(fù)正常使用，如果恢復(fù)較慢，或中途出現(xiàn)其它問題，通過(guò)微信群或 github 聯(lián)系我們官方即可。

五. 結(jié)語(yǔ)

RAFT 的引入是 3.0 大規(guī)模重構(gòu)中最大的亮點(diǎn)之一，在保住了 TDengine 的性能優(yōu)勢(shì)的前提下，使得 TDengine 能以更標(biāo)準(zhǔn)的方式處理數(shù)據(jù)的一致性問題。

在存儲(chǔ)引擎，一致性協(xié)議，查詢引擎全部做了大規(guī)模重構(gòu)之后，TDengine 3.0 將會(huì)在更廣泛的時(shí)序數(shù)據(jù)處理場(chǎng)景中發(fā)揮作用，歡迎大家加入我們一起探索可能。