[[411752]]

一直以來(lái)，在多地多中心的消息發(fā)送場(chǎng)景下，如何保障數(shù)據(jù)的完整性和一致性是一個(gè)技術(shù)難點(diǎn)。在 RocketMQ 4.5 版本之前，RocketMQ 只有 Master/Slave 一種部署方式，一組 broker 中有一個(gè) Master ，有零到多個(gè)

Slave，Slave 通過(guò)同步復(fù)制或異步復(fù)制的方式去同步 Master 數(shù)據(jù)。Master/Slave 部署模式，提供了一定的高可用性。

但這樣的部署模式，有一定缺陷。比如故障轉(zhuǎn)移方面，如果主節(jié)點(diǎn)掛了，還需要人為手動(dòng)進(jìn)行重啟或者切換，無(wú)法自動(dòng)將一個(gè)從節(jié)點(diǎn)轉(zhuǎn)換為主節(jié)點(diǎn)。那么什么樣的多副本架構(gòu)可以來(lái)解決這個(gè)問(wèn)題呢?首先我們來(lái)看看多副本技術(shù)的演進(jìn)。

多副本技術(shù)的演進(jìn)

Master/Slave

多副本最早的是 Master/Slave 架構(gòu)，即簡(jiǎn)單地用 Slave 去同步 Master 的數(shù)據(jù)，RocketMQ 最早也是這種實(shí)現(xiàn)。分為同步模式(Sync Mode)和異步模式(Async Mode)，區(qū)別就是 Master 是否等數(shù)據(jù)同步到 Slave 之后再返回 Client。這兩種方式目前在 RocketMQ 社區(qū)廣泛使用的版本中都有支持，也可以看我前面分享的文章。

基于 Zookeeper 服務(wù)

隨著分布式領(lǐng)域開(kāi)啟了快速發(fā)展。在 Hadoop 生態(tài)中，誕生了一個(gè)基于 Paxos 算法選舉 Leader 的分布式協(xié)調(diào)服務(wù) ZooKeeper。

由于 ZooKeeper 本身?yè)碛懈呖捎煤透呖煽康奶匦?，隨之誕生了很多基于 ZooKeeper 的高可用高可靠的系統(tǒng)。

具體做法如下圖所示：

Based on Zookeeper/Etcd

如圖所示，假如系統(tǒng)里有 3 個(gè)節(jié)點(diǎn)，通過(guò) ZooKeeper 提供的一些接口，可以從 3 個(gè)節(jié)點(diǎn)中自動(dòng)的選出一個(gè) Master 來(lái)。選出一個(gè) Master 后，另外兩個(gè)沒(méi)成功的就自然變成 Slave。選完之后，后續(xù)過(guò)程與傳統(tǒng)實(shí)現(xiàn)方式中的復(fù)制一樣。故基于 ZooKeeper 的系統(tǒng)與基于 Master/Slave 系統(tǒng)最大的區(qū)別就是：選 Master 的過(guò)程由手動(dòng)選舉變成依賴一個(gè)第三方的服務(wù)(比如 ZooKeeper 或 Etcd)的選舉。

但是基于 ZooKeeper 的服務(wù)也帶來(lái)一個(gè)比較嚴(yán)重的問(wèn)題：依賴加重。因?yàn)檫\(yùn)維 ZooKeeper 是一件很復(fù)雜的事情。

基于 Raft 服務(wù)方式

因?yàn)?ZooKeeper 的復(fù)雜性，又有了以下 Raft 的方式。Raft 可以認(rèn)為是 Paxos 的簡(jiǎn)化版?；?Raft 的方式如下圖 4 所示，與上述兩種方式最大的區(qū)別是：leader 的選舉是由自己完成的。比如一個(gè)系統(tǒng)有 3 個(gè)節(jié)點(diǎn)，這 3 個(gè)節(jié)點(diǎn)的 leader 是利用 Raft 的算法通過(guò)協(xié)調(diào)選舉自己去完成的，選舉完成之后，Master 到 Slave 同步的過(guò)程仍然與傳統(tǒng)方式類似。最大的好處就是去除了依賴，即本身變得很簡(jiǎn)單，可以自己完成自己的協(xié)調(diào)

實(shí)現(xiàn)高可靠和高可用的方法優(yōu)劣對(duì)比

Master/Slave，Based on ZooKeeper/Etcd 和 Raft，這三種是目前分布式系統(tǒng)中，做到高可靠和高可用的基本的實(shí)現(xiàn)方法，各有優(yōu)劣。

Master/Slave

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單

缺點(diǎn)：不能自動(dòng)控制節(jié)點(diǎn)切換，一旦出了問(wèn)題，需要人為介入。

基于 Zookeeper/Etcd

優(yōu)點(diǎn)：可以自動(dòng)切換節(jié)點(diǎn)

缺點(diǎn)：運(yùn)維成本很高，因?yàn)?ZooKeeper 本身就很難運(yùn)維。

Raft

優(yōu)點(diǎn)：可以自己協(xié)調(diào)，并且去除依賴。

缺點(diǎn)：實(shí)現(xiàn) Raft，在編碼上比較困難。

多副本架構(gòu)首先需要解決自動(dòng)故障轉(zhuǎn)移的問(wèn)題，本質(zhì)上來(lái)說(shuō)是自動(dòng)選主的問(wèn)題。這個(gè)問(wèn)題的解決方案基本可以分為兩種：

• 利用第三方協(xié)調(diào)服務(wù)集群完成選主，比如 zookeeper 或者 etcd。這種方案會(huì)引入了重量級(jí)外部組件，加重部署，運(yùn)維和故障診斷成本，比如在維護(hù) RocketMQ 集群還需要維護(hù) zookeeper 集群，并且 zookeeper 集群故障會(huì)影響到 RocketMQ 集群。
• 利用 raft 協(xié)議來(lái)完成一個(gè)自動(dòng)選主，raft 協(xié)議相比前者的優(yōu)點(diǎn)是不需要引入外部組件，自動(dòng)選主邏輯集成到各個(gè)節(jié)點(diǎn)的進(jìn)程中，節(jié)點(diǎn)之間通過(guò)通信就可以完成選主。

目前很多中間件都使用了raft 協(xié)議或使用了變種的raft協(xié)議，如mongodb .還有新版的kafka,放棄了zookeeper,

將元數(shù)據(jù)存儲(chǔ)在 Kafka 本身，而不是存儲(chǔ) ZooKeeper 這樣的外部系統(tǒng)中。新版kafka的Quorum 控制器使用新的 KRaft 協(xié)議來(lái)確保元數(shù)據(jù)在仲裁中被精確地復(fù)制。這個(gè)協(xié)議在很多方面與 ZooKeeper 的 ZAB 協(xié)議和 Raft 相似。

RocketMQ也選擇用 raft 協(xié)議來(lái)解決這個(gè)問(wèn)題。

關(guān)于Raft

我們知道在分布式領(lǐng)域，始終都要面臨的一個(gè)挑戰(zhàn)就是：數(shù)據(jù)一致性.

Paxos。如今它是業(yè)界公認(rèn)此類問(wèn)題的最有效解。雖然Paxos在理論界得到了高度認(rèn)可，但是卻給工程界帶來(lái)了難題。因?yàn)檫@個(gè)算法本身比較晦澀，并且抽象，缺少很多實(shí)現(xiàn)細(xì)節(jié)。這讓許多工程師大為頭疼

Raft是為解決Paxos難以理解和實(shí)現(xiàn)的問(wèn)題而提出的。

Raft 算法的工作流程主要包含五個(gè)部分：

• 領(lǐng)導(dǎo)選舉(Leader election)：在集群初始化或者舊領(lǐng)導(dǎo)異常情況下，選舉出一個(gè)新的領(lǐng)導(dǎo)。
• 日志復(fù)制(Log replication): 當(dāng)有新的日志寫(xiě)入時(shí)，領(lǐng)導(dǎo)能把它復(fù)制到集群中大多數(shù)節(jié)點(diǎn)上。
• 集群成員變更(Cluster Membership changes): 當(dāng)集群有擴(kuò)容或者縮容的需求，集群各節(jié)點(diǎn)能準(zhǔn)確感知哪些節(jié)點(diǎn)新加入或者被去除。
• 日志壓縮(Log compaction): 當(dāng)寫(xiě)入的日志文件越來(lái)越大，重啟時(shí)節(jié)點(diǎn)回放(replay)日志的時(shí)間將無(wú)限延長(zhǎng)，并且新節(jié)點(diǎn)加入集群時(shí)傳送日志文件也會(huì)無(wú)限拉大。需要定期對(duì)日志文件進(jìn)行重整壓縮。
• 讀寫(xiě)一致性(Read/write consistency): 客戶端作為集群的外部組件，當(dāng)一個(gè)客戶端寫(xiě)入新數(shù)據(jù)時(shí)，能保證后續(xù)所有客戶端都能讀到最新的值。

數(shù)據(jù)一致性的幾層語(yǔ)義：

• 數(shù)據(jù)的寫(xiě)入順序要保持一致。否則可能出現(xiàn)很多不預(yù)期的情況，比如：舊值覆蓋新值。先刪后增變成先增后刪，數(shù)據(jù)消失了
• 對(duì)成功寫(xiě)入的數(shù)據(jù)供認(rèn)不諱。如果數(shù)據(jù)被集群表明寫(xiě)入成功，那么集群各節(jié)點(diǎn)都應(yīng)該認(rèn)可并接受這個(gè)結(jié)果，而不會(huì)出現(xiàn)某些節(jié)點(diǎn)不知情的情況。
• 數(shù)據(jù)寫(xiě)入成功保證持久化的。如果集群表明數(shù)據(jù)寫(xiě)入成功，數(shù)據(jù)卻沒(méi)落盤(pán)。這時(shí)宕機(jī)了，那么數(shù)據(jù)就丟失了。

Raft在 保序性、共識(shí)性、持久性都能很好的支持這就能證明：

在假定領(lǐng)導(dǎo)永不宕機(jī)的前提下，Raft是能夠保證集群數(shù)據(jù)一致性的。

Leader在非正常運(yùn)行情況下，推選出的新Leader至少擁有所有已提交的日志，從而保證數(shù)據(jù)一致性。

因?yàn)镽aft規(guī)定：一切寫(xiě)入操作必須由Leader管控，所以選主這段時(shí)間客戶端的寫(xiě)入會(huì)被告知失敗或者進(jìn)行不斷重試。這里其實(shí)一定程度上犧牲了集群的可用性來(lái)保證一致性。然而就像CAP定理告訴我們的，分布式系統(tǒng)不能既保證一致性C，又保證可用性A。而Raft集群選擇了 C和 P，也就一定程度失去了A。

所以，Raft算法能保證集群的數(shù)據(jù)一致性。

什么是 DLedger

Dledger 的定位

DLedger 就是一個(gè)基于 raft 協(xié)議的 commitlog 存儲(chǔ)庫(kù)，

Dledger 作為一個(gè)輕量級(jí)的 Java Library，它的作用就是將 Raft 有關(guān)于算法方面的內(nèi)容全部抽象掉，開(kāi)發(fā)人員只需要關(guān)心業(yè)務(wù)即可也是 RocketMQ 實(shí)現(xiàn)新的高可用多副本架構(gòu)的關(guān)鍵。

如上圖所示，Dledger 只做一件事情，就是 CommitLog。Etcd 雖然也實(shí)現(xiàn)了 Raft 協(xié)議，但它是自己封裝的一個(gè)服務(wù)，對(duì)外提供的接口全是跟它自己的業(yè)務(wù)相關(guān)的。在這種對(duì) Raft 的抽象中，可以簡(jiǎn)單理解為有一個(gè) StateMachine 和 CommitLog。CommitLog 是具體的寫(xiě)入日志、操作記錄，StateMachine 是根據(jù)這些操作記錄構(gòu)建出來(lái)的系統(tǒng)的狀態(tài)。在這樣抽象之后，Etcd 對(duì)外提供的是自己的 StateMachine 的一些服務(wù)。Dledger 的定位就是把上一層的 StateMachine 給去除，只留下 CommitLog。這樣的話，系統(tǒng)就只需要實(shí)現(xiàn)一件事：就是把操作日志變得高可用和高可靠。

Dledger 的架構(gòu)

從前面介紹的多副本技術(shù)的演進(jìn)可以知道，我們要做的主要有兩件事：選舉和復(fù)制，對(duì)應(yīng)到上面的架構(gòu)圖中，也就是兩個(gè)核心類：DLedgerLeaderElector 和 DLedgerStore，選舉和文件存儲(chǔ)。選出 leader 后，再由 leader 去接收數(shù)據(jù)的寫(xiě)入，同時(shí)同步到其他的 follower，這樣就完成了整個(gè) Raft 的寫(xiě)入過(guò)程。

DLedger 的優(yōu)化

Raft 協(xié)議復(fù)制過(guò)程可以分為四步，先是發(fā)送消息給 leader，leader 除了本地存儲(chǔ)之外，會(huì)把消息復(fù)制給 follower，然后等待follower 確認(rèn)，如果得到多數(shù)節(jié)點(diǎn)確認(rèn)，該消息就可以被提交，并向客戶端返回發(fā)送成功的確認(rèn)。

DLedger對(duì)于復(fù)制過(guò)程有以下優(yōu)化：

• 1、對(duì)于復(fù)制過(guò)程，DLedger 采用一個(gè)異步線程模型提高吞吐量和性能。
• 2、DLedger 中，leader 向所有 follower 發(fā)送日志也是完全相互獨(dú)立和并發(fā)的，leader 為每個(gè) follower 分配一個(gè)線程去復(fù)制日志 這是一個(gè)獨(dú)立并發(fā)的復(fù)制過(guò)程。
• 3、在獨(dú)立并發(fā)的復(fù)制過(guò)程內(nèi)，DLedger設(shè)計(jì)并實(shí)現(xiàn)日志并行復(fù)制的方案，不再需要等待前一個(gè)日志復(fù)制完成再?gòu)?fù)制下一個(gè)日志，只需在 follower 中維護(hù)一個(gè)按照日志索引排序請(qǐng)求列表， follower 線程按照索引順序串行處理這些復(fù)制請(qǐng)求。而對(duì)于并行復(fù)制后可能出現(xiàn)數(shù)據(jù)缺失問(wèn)題，可以通過(guò)少量數(shù)據(jù)重傳解決。

通過(guò)以上3點(diǎn)，優(yōu)化這一復(fù)制過(guò)程。

在可靠性方面DLedger也對(duì)網(wǎng)絡(luò)分區(qū)做了優(yōu)化，而且也對(duì)DLedger 做了可靠性測(cè)試：

DLedger對(duì)網(wǎng)絡(luò)分區(qū)的優(yōu)化

如果出現(xiàn)上圖的網(wǎng)絡(luò)分區(qū)，n2與集群中的其他節(jié)點(diǎn)發(fā)生了網(wǎng)絡(luò)隔離，按照 raft 論文實(shí)現(xiàn)，n2會(huì)一直請(qǐng)求投票，但得不到多數(shù)的投票，term 一直增大。一旦網(wǎng)絡(luò)恢復(fù)后，n2就會(huì)去打斷正在正常復(fù)制的n1和n3，進(jìn)行重新選舉。為了解決這種情況，DLedger 的實(shí)現(xiàn)改進(jìn)了 raft 協(xié)議，請(qǐng)求投票過(guò)程分成了多個(gè)階段，其中有兩個(gè)重要階段：WAIT_TO_REVOTE和WAIT_TO_VOTE_NEXT。WAIT_TO_REVOTE是初始狀態(tài)，這個(gè)狀態(tài)請(qǐng)求投票時(shí)不會(huì)增加 term，WAIT_TO_VOTE_NEXT則會(huì)在下一輪請(qǐng)求投票開(kāi)始前增加 term。對(duì)于圖中n2情況，當(dāng)有效的投票數(shù)量沒(méi)有達(dá)到多數(shù)量時(shí)。可以將節(jié)點(diǎn)狀態(tài)設(shè)置WAIT_TO_REVOTE，term 就不會(huì)增加。通過(guò)這個(gè)方法，提高了Dledger對(duì)網(wǎng)絡(luò)分區(qū)的容忍性。

DLedger 可靠性測(cè)試

官方不僅測(cè)試對(duì)稱網(wǎng)絡(luò)分區(qū)故障，還測(cè)試了其他故障下 Dledger 表現(xiàn)情況，包括隨機(jī)殺死節(jié)點(diǎn)，隨機(jī)暫停一些節(jié)點(diǎn)的進(jìn)程模擬慢節(jié)點(diǎn)的狀況，以及 bridge、partition-majorities-ring 等復(fù)雜的非對(duì)稱網(wǎng)絡(luò)分區(qū)。在這些故障下，DLedger 都保證了一致性，驗(yàn)證了 DLedger 有很好可靠性。

Dledger 的應(yīng)用

在 RocketMQ 上的應(yīng)用

RocketMQ 4.5 版本發(fā)布后，可以采用 RocketMQ on DLedger 方式進(jìn)行部署。DLedger commitlog 代替了原來(lái)的 commitlog，使得 commitlog 擁有了選舉復(fù)制能力，然后通過(guò)角色透?jìng)鞯姆绞剑瑀aft 角色透?jìng)鹘o外部 broker 角色，leader 對(duì)應(yīng)原來(lái)的 master，follower 和 candidate 對(duì)應(yīng)原來(lái)的 slave。

因此 RocketMQ 的 broker 擁有了自動(dòng)故障轉(zhuǎn)移的能力。在一組 broker 中， Master 掛了以后，依靠 DLedger 自動(dòng)選主能力，會(huì)重新選出 leader，然后通過(guò)角色透?jìng)髯兂尚碌?Master。

Dledger構(gòu)建高可用的嵌入式 KV 存儲(chǔ)

DLedger 還可以構(gòu)建高可用的嵌入式 KV 存儲(chǔ)。

我們沒(méi)有一個(gè)嵌入式且高可用的解決方案。RocksDB 可以直接用，但是它本身不支持高可用。(Rocks DB 是Facebook開(kāi)源的單機(jī)版數(shù)據(jù)庫(kù))

有了 DLedger 之后，我們把對(duì)一些數(shù)據(jù)的操作記錄到 DLedger 中，然后根據(jù)數(shù)據(jù)量或者實(shí)際需求，恢復(fù)到hashmap 或者 rocksdb 中，從而構(gòu)建一致的、高可用的 KV 存儲(chǔ)系統(tǒng)，應(yīng)用到元信息管理等場(chǎng)景。

參考：

https://developer.aliyun.com/article/713017

https://blog.csdn.net/csdn_lhs/article/details/108029978