建站
咨詢
售后
建站咨詢
新聞中心
一直以來，在多地多中心的消息發(fā)送場景下，如何保障數(shù)據(jù)的完整性和一致性是一個技術(shù)難點(diǎn)。在 RocketMQ 4.5 版本之前，RocketMQ 只有 Master/Slave 一種部署方式，一組 broker 中有一個 Master ，有零到多個
為白云等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及白云網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站制作、成都網(wǎng)站建設(shè)、白云網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
Slave，Slave 通過同步復(fù)制或異步復(fù)制的方式去同步 Master 數(shù)據(jù)。Master/Slave 部署模式，提供了一定的高可用性。
但這樣的部署模式，有一定缺陷。比如故障轉(zhuǎn)移方面，如果主節(jié)點(diǎn)掛了，還需要人為手動進(jìn)行重啟或者切換，無法自動將一個從節(jié)點(diǎn)轉(zhuǎn)換為主節(jié)點(diǎn)。那么什么樣的多副本架構(gòu)可以來解決這個問題呢?首先我們來看看多副本技術(shù)的演進(jìn)。
多副本技術(shù)的演進(jìn)
Master/Slave
多副本最早的是 Master/Slave 架構(gòu)，即簡單地用 Slave 去同步 Master 的數(shù)據(jù)，RocketMQ 最早也是這種實現(xiàn)。分為同步模式(Sync Mode)和異步模式(Async Mode)，區(qū)別就是 Master 是否等數(shù)據(jù)同步到 Slave 之后再返回 Client。這兩種方式目前在 RocketMQ 社區(qū)廣泛使用的版本中都有支持，也可以看我前面分享的文章。
基于 Zookeeper 服務(wù)
隨著分布式領(lǐng)域開啟了快速發(fā)展。在 Hadoop 生態(tài)中，誕生了一個基于 Paxos 算法選舉 Leader 的分布式協(xié)調(diào)服務(wù) ZooKeeper。
由于 ZooKeeper 本身擁有高可用和高可靠的特性，隨之誕生了很多基于 ZooKeeper 的高可用高可靠的系統(tǒng)。
具體做法如下圖所示：
Based on Zookeeper/Etcd
如圖所示，假如系統(tǒng)里有 3 個節(jié)點(diǎn)，通過 ZooKeeper 提供的一些接口，可以從 3 個節(jié)點(diǎn)中自動的選出一個 Master 來。選出一個 Master 后，另外兩個沒成功的就自然變成 Slave。選完之后，后續(xù)過程與傳統(tǒng)實現(xiàn)方式中的復(fù)制一樣。故基于 ZooKeeper 的系統(tǒng)與基于 Master/Slave 系統(tǒng)最大的區(qū)別就是：選 Master 的過程由手動選舉變成依賴一個第三方的服務(wù)(比如 ZooKeeper 或 Etcd)的選舉。
但是基于 ZooKeeper 的服務(wù)也帶來一個比較嚴(yán)重的問題：依賴加重。因為運(yùn)維 ZooKeeper 是一件很復(fù)雜的事情。
基于 Raft 服務(wù)方式
因為 ZooKeeper 的復(fù)雜性，又有了以下 Raft 的方式。Raft 可以認(rèn)為是 Paxos 的簡化版。基于 Raft 的方式如下圖 4 所示，與上述兩種方式最大的區(qū)別是：leader 的選舉是由自己完成的。比如一個系統(tǒng)有 3 個節(jié)點(diǎn)，這 3 個節(jié)點(diǎn)的 leader 是利用 Raft 的算法通過協(xié)調(diào)選舉自己去完成的，選舉完成之后，Master 到 Slave 同步的過程仍然與傳統(tǒng)方式類似。最大的好處就是去除了依賴，即本身變得很簡單，可以自己完成自己的協(xié)調(diào)
實現(xiàn)高可靠和高可用的方法優(yōu)劣對比
Master/Slave，Based on ZooKeeper/Etcd 和 Raft，這三種是目前分布式系統(tǒng)中，做到高可靠和高可用的基本的實現(xiàn)方法，各有優(yōu)劣。
Master/Slave
優(yōu)點(diǎn)：實現(xiàn)簡單
缺點(diǎn)：不能自動控制節(jié)點(diǎn)切換，一旦出了問題，需要人為介入。
基于 Zookeeper/Etcd
優(yōu)點(diǎn)：可以自動切換節(jié)點(diǎn)
缺點(diǎn)：運(yùn)維成本很高，因為 ZooKeeper 本身就很難運(yùn)維。
Raft
優(yōu)點(diǎn)：可以自己協(xié)調(diào)，并且去除依賴。
缺點(diǎn)：實現(xiàn) Raft，在編碼上比較困難。
多副本架構(gòu)首先需要解決自動故障轉(zhuǎn)移的問題，本質(zhì)上來說是自動選主的問題。這個問題的解決方案基本可以分為兩種：
- 利用第三方協(xié)調(diào)服務(wù)集群完成選主，比如 zookeeper 或者 etcd。這種方案會引入了重量級外部組件，加重部署，運(yùn)維和故障診斷成本，比如在維護(hù) RocketMQ 集群還需要維護(hù) zookeeper 集群，并且 zookeeper 集群故障會影響到 RocketMQ 集群。
- 利用 raft 協(xié)議來完成一個自動選主，raft 協(xié)議相比前者的優(yōu)點(diǎn)是不需要引入外部組件，自動選主邏輯集成到各個節(jié)點(diǎn)的進(jìn)程中，節(jié)點(diǎn)之間通過通信就可以完成選主。
目前很多中間件都使用了raft 協(xié)議或使用了變種的raft協(xié)議，如mongodb .還有新版的kafka,放棄了zookeeper,
將元數(shù)據(jù)存儲在 Kafka 本身，而不是存儲 ZooKeeper 這樣的外部系統(tǒng)中。新版kafka的Quorum 控制器使用新的 KRaft 協(xié)議來確保元數(shù)據(jù)在仲裁中被精確地復(fù)制。這個協(xié)議在很多方面與 ZooKeeper 的 ZAB 協(xié)議和 Raft 相似。
RocketMQ也選擇用 raft 協(xié)議來解決這個問題。
關(guān)于Raft
我們知道在分布式領(lǐng)域，始終都要面臨的一個挑戰(zhàn)就是：數(shù)據(jù)一致性.
Paxos。如今它是業(yè)界公認(rèn)此類問題的最有效解。雖然Paxos在理論界得到了高度認(rèn)可，但是卻給工程界帶來了難題。因為這個算法本身比較晦澀，并且抽象，缺少很多實現(xiàn)細(xì)節(jié)。這讓許多工程師大為頭疼
Raft是為解決Paxos難以理解和實現(xiàn)的問題而提出的。
Raft 算法的工作流程主要包含五個部分：
- 領(lǐng)導(dǎo)選舉(Leader election)：在集群初始化或者舊領(lǐng)導(dǎo)異常情況下，選舉出一個新的領(lǐng)導(dǎo)。
- 日志復(fù)制(Log replication): 當(dāng)有新的日志寫入時，領(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)寫入的日志文件越來越大，重啟時節(jié)點(diǎn)回放(replay)日志的時間將無限延長，并且新節(jié)點(diǎn)加入集群時傳送日志文件也會無限拉大。需要定期對日志文件進(jìn)行重整壓縮。
- 讀寫一致性(Read/write consistency): 客戶端作為集群的外部組件，當(dāng)一個客戶端寫入新數(shù)據(jù)時，能保證后續(xù)所有客戶端都能讀到最新的值。
數(shù)據(jù)一致性的幾層語義：
- 數(shù)據(jù)的寫入順序要保持一致。否則可能出現(xiàn)很多不預(yù)期的情況，比如：舊值覆蓋新值。先刪后增變成先增后刪，數(shù)據(jù)消失了
- 對成功寫入的數(shù)據(jù)供認(rèn)不諱。如果數(shù)據(jù)被集群表明寫入成功，那么集群各節(jié)點(diǎn)都應(yīng)該認(rèn)可并接受這個結(jié)果，而不會出現(xiàn)某些節(jié)點(diǎn)不知情的情況。
- 數(shù)據(jù)寫入成功保證持久化的。如果集群表明數(shù)據(jù)寫入成功，數(shù)據(jù)卻沒落盤。這時宕機(jī)了，那么數(shù)據(jù)就丟失了。
Raft在 保序性、共識性、持久性都能很好的支持這就能證明：
在假定領(lǐng)導(dǎo)永不宕機(jī)的前提下，Raft是能夠保證集群數(shù)據(jù)一致性的。
Leader在非正常運(yùn)行情況下，推選出的新Leader至少擁有所有已提交的日志，從而保證數(shù)據(jù)一致性。
因為Raft規(guī)定：一切寫入操作必須由Leader管控，所以選主這段時間客戶端的寫入會被告知失敗或者進(jìn)行不斷重試。這里其實一定程度上犧牲了集群的可用性來保證一致性。然而就像CAP定理告訴我們的，分布式系統(tǒng)不能既保證一致性C，又保證可用性A。而Raft集群選擇了 C和 P，也就一定程度失去了A。
所以，Raft算法能保證集群的數(shù)據(jù)一致性。
什么是 DLedger
Dledger 的定位
DLedger 就是一個基于 raft 協(xié)議的 commitlog 存儲庫，
Dledger 作為一個輕量級的 Java Library，它的作用就是將 Raft 有關(guān)于算法方面的內(nèi)容全部抽象掉，開發(fā)人員只需要關(guān)心業(yè)務(wù)即可也是 RocketMQ 實現(xiàn)新的高可用多副本架構(gòu)的關(guān)鍵。
如上圖所示，Dledger 只做一件事情，就是 CommitLog。Etcd 雖然也實現(xiàn)了 Raft 協(xié)議，但它是自己封裝的一個服務(wù)，對外提供的接口全是跟它自己的業(yè)務(wù)相關(guān)的。在這種對 Raft 的抽象中，可以簡單理解為有一個 StateMachine 和 CommitLog。CommitLog 是具體的寫入日志、操作記錄，StateMachine 是根據(jù)這些操作記錄構(gòu)建出來的系統(tǒng)的狀態(tài)。在這樣抽象之后，Etcd 對外提供的是自己的 StateMachine 的一些服務(wù)。Dledger 的定位就是把上一層的 StateMachine 給去除，只留下 CommitLog。這樣的話，系統(tǒng)就只需要實現(xiàn)一件事：就是把操作日志變得高可用和高可靠。
Dledger 的架構(gòu)
從前面介紹的多副本技術(shù)的演進(jìn)可以知道，我們要做的主要有兩件事：選舉和復(fù)制，對應(yīng)到上面的架構(gòu)圖中，也就是兩個核心類：DLedgerLeaderElector 和 DLedgerStore，選舉和文件存儲。選出 leader 后，再由 leader 去接收數(shù)據(jù)的寫入，同時同步到其他的 follower，這樣就完成了整個 Raft 的寫入過程。
DLedger 的優(yōu)化
Raft 協(xié)議復(fù)制過程可以分為四步，先是發(fā)送消息給 leader，leader 除了本地存儲之外，會把消息復(fù)制給 follower，然后等待follower 確認(rèn)，如果得到多數(shù)節(jié)點(diǎn)確認(rèn)，該消息就可以被提交，并向客戶端返回發(fā)送成功的確認(rèn)。
DLedger對于復(fù)制過程有以下優(yōu)化：
- 1、對于復(fù)制過程，DLedger 采用一個異步線程模型提高吞吐量和性能。
- 2、DLedger 中，leader 向所有 follower 發(fā)送日志也是完全相互獨(dú)立和并發(fā)的，leader 為每個 follower 分配一個線程去復(fù)制日志 這是一個獨(dú)立并發(fā)的復(fù)制過程。
- 3、在獨(dú)立并發(fā)的復(fù)制過程內(nèi)，DLedger設(shè)計并實現(xiàn)日志并行復(fù)制的方案，不再需要等待前一個日志復(fù)制完成再復(fù)制下一個日志，只需在 follower 中維護(hù)一個按照日志索引排序請求列表， follower 線程按照索引順序串行處理這些復(fù)制請求。而對于并行復(fù)制后可能出現(xiàn)數(shù)據(jù)缺失問題，可以通過少量數(shù)據(jù)重傳解決。
通過以上3點(diǎn)，優(yōu)化這一復(fù)制過程。
在可靠性方面DLedger也對網(wǎng)絡(luò)分區(qū)做了優(yōu)化，而且也對DLedger 做了可靠性測試：
DLedger對網(wǎng)絡(luò)分區(qū)的優(yōu)化
如果出現(xiàn)上圖的網(wǎng)絡(luò)分區(qū)，n2與集群中的其他節(jié)點(diǎn)發(fā)生了網(wǎng)絡(luò)隔離，按照 raft 論文實現(xiàn)，n2會一直請求投票，但得不到多數(shù)的投票，term 一直增大。一旦網(wǎng)絡(luò)恢復(fù)后，n2就會去打斷正在正常復(fù)制的n1和n3，進(jìn)行重新選舉。為了解決這種情況，DLedger 的實現(xiàn)改進(jìn)了 raft 協(xié)議，請求投票過程分成了多個階段，其中有兩個重要階段：WAIT_TO_REVOTE和WAIT_TO_VOTE_NEXT。WAIT_TO_REVOTE是初始狀態(tài)，這個狀態(tài)請求投票時不會增加 term，WAIT_TO_VOTE_NEXT則會在下一輪請求投票開始前增加 term。對于圖中n2情況，當(dāng)有效的投票數(shù)量沒有達(dá)到多數(shù)量時?？梢詫⒐?jié)點(diǎn)狀態(tài)設(shè)置WAIT_TO_REVOTE，term 就不會增加。通過這個方法，提高了Dledger對網(wǎng)絡(luò)分區(qū)的容忍性。
DLedger 可靠性測試
官方不僅測試對稱網(wǎng)絡(luò)分區(qū)故障，還測試了其他故障下 Dledger 表現(xiàn)情況，包括隨機(jī)殺死節(jié)點(diǎn)，隨機(jī)暫停一些節(jié)點(diǎn)的進(jìn)程模擬慢節(jié)點(diǎn)的狀況，以及 bridge、partition-majorities-ring 等復(fù)雜的非對稱網(wǎng)絡(luò)分區(qū)。在這些故障下，DLedger 都保證了一致性，驗證了 DLedger 有很好可靠性。
Dledger 的應(yīng)用
在 RocketMQ 上的應(yīng)用
RocketMQ 4.5 版本發(fā)布后，可以采用 RocketMQ on DLedger 方式進(jìn)行部署。DLedger commitlog 代替了原來的 commitlog，使得 commitlog 擁有了選舉復(fù)制能力，然后通過角色透傳的方式，raft 角色透傳給外部 broker 角色，leader 對應(yīng)原來的 master，follower 和 candidate 對應(yīng)原來的 slave。
因此 RocketMQ 的 broker 擁有了自動故障轉(zhuǎn)移的能力。在一組 broker 中， Master 掛了以后，依靠 DLedger 自動選主能力，會重新選出 leader，然后通過角色透傳變成新的 Master。
Dledger構(gòu)建高可用的嵌入式 KV 存儲
DLedger 還可以構(gòu)建高可用的嵌入式 KV 存儲。
我們沒有一個嵌入式且高可用的解決方案。RocksDB 可以直接用，但是它本身不支持高可用。(Rocks DB 是Facebook開源的單機(jī)版數(shù)據(jù)庫)
有了 DLedger 之后，我們把對一些數(shù)據(jù)的操作記錄到 DLedger 中，然后根據(jù)數(shù)據(jù)量或者實際需求，恢復(fù)到hashmap 或者 rocksdb 中，從而構(gòu)建一致的、高可用的 KV 存儲系統(tǒng)，應(yīng)用到元信息管理等場景。
參考：
https://developer.aliyun.com/article/713017
https://blog.csdn.net/csdn_lhs/article/details/108029978
網(wǎng)站標(biāo)題：高可用的升級-RocketMQ知識體系7
標(biāo)題網(wǎng)址：http://www.dlmjj.cn/article/djgddoe.html
