一直以來，在多地多中心的消息發(fā)送場景下，如何保障數(shù)據(jù)的完整性和一致性是一個技術(shù)難點。本文將和您一起探討 Dledger 技術(shù)，并分享 RocketMQ 的實踐。

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

1.1 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ū)廣泛使用的版本中都有支持，原理圖如下圖 1 所示。

 

 

圖 1 Master-Slave

1.2 基于 Zookeeper 服務(wù)

隨著 Google 三篇核心技術(shù)論文的發(fā)表(MapReduce、GFS 和 BigTable)，分布式領(lǐng)域開啟了快速發(fā)展。在 Hadoop 生態(tài)中，誕生了一個基于 Paxos 算法選舉 Leader 的分布式協(xié)調(diào)服務(wù) ZooKeeper。[z1] 由于 ZooKeeper 本身擁有高可用和高可靠的特性，隨之誕生了很多基于 ZooKeepe r 的高可用高可靠的系統(tǒng)。具體做法如下圖 2 所示：

 

 

圖 2 Based on Zookeeper/Etcd

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

基于 ZooKeeper 的服務(wù)還存在一個變種，具體做法如下圖 3：

 

 

圖 3 Based on ZooKeeper/Etcd

在第一種方式中，發(fā)起者(Client)和接收者(Server)都是在同一個進(jìn)程中的。而在這種方式中 Client 是脫離于 Server 之外的，通過 Zookeeper，從這三個 Client 中選出一個 Master 來，選完 Master 后把請求同時發(fā)送到 3 個 Server 里，這樣也可以達(dá)到多副本的效果。

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

1.3 基于 Raft 服務(wù)方式

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

 

 

圖 4 Raft

♦ Raft Leader Election 機(jī)制

Raft 最大的好處就是可以實現(xiàn)自身 leader 選舉。如果一個分布系統(tǒng)要自我協(xié)調(diào)，通常是采用“投票”的方式，在“投票”的時候，為了解決沖突問題，就采用了兩個機(jī)制：Term 和 Quorum。

♦ Term，即給每一次投票編號，以 1、2、3 這樣的數(shù)字命名。

♦ Quorum，即少數(shù)服從多數(shù)原則，每一次投票必須要得到多數(shù)派(N/2 + 1)的同意才認(rèn)為是成功。

根據(jù)這兩個機(jī)制，在一個 Term 中，一個節(jié)點只能投出一票，保證在一個 Term 中只有一個節(jié)點能選舉成功。如果在一個 Term 中，沒有節(jié)點獲得大多數(shù)節(jié)點(N/2+1)的選票，選舉失敗，會重新發(fā)起選舉。選舉失敗后，給每個節(jié)點設(shè)置合適的隨機(jī)等待時間，會容易更快選舉完成。選舉成功之后就是跟之前比較相似的復(fù)制過程。

♦ 三種實現(xiàn)高可靠和高可用的方法優(yōu)劣對比

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

♦ Master/Slave

優(yōu)點：實現(xiàn)簡單

缺點：不能自動控制節(jié)點切換，一旦出了問題，需要人為介入。

♦ Based on Zookeeper/Etcd

優(yōu)點：可以自動切換節(jié)點

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

♦ Raft

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

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

2. 什么是 DLedger

2.1 Dledger 的定位

前文介紹了目前分布式系統(tǒng)中，做到高可靠和高可用的三種基本的實現(xiàn)方法。Raft 算法現(xiàn)在解析的比較多，也比較成熟，代碼實現(xiàn)難度也有所降低。Dledger 作為一個輕量級的 Java Library，它的作用就是將 Raft 有關(guān)于算法方面的內(nèi)容全部抽象掉，開發(fā)人員只需要關(guān)心業(yè)務(wù)即可。

 

 

圖 5 Dledger Proposition

如上圖所示，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)一件事：就是把操作日志變得高可用和高可靠。

這樣做對消息系統(tǒng)還有非常特別的含義。消息系統(tǒng)里面如果還采用 StateMachine + CommitLog 的方式，會出現(xiàn) double IO 的問題，因為消息本省可以理解為是一個操作記錄。所以 Dledger 會提供一些對原生 CommitLog 訪問的 API。通過這些 API 可以直接去訪問 CommitLog。這樣的話，只需要寫入一次就可以拿到寫入的內(nèi)容。Dledger 對外提供的是簡單的 API，如下圖 6 所示。可以把它理解為一個可以無限寫入操作記錄的文件，可以不停 append，每一個 append 的記錄會加上一個編號。所以直接去訪問 Dledger 的話就是兩個 API：一個是 append，另一個是 get，即根據(jù)編號拿到相應(yīng)的 entry(一條記錄)。

 

 

圖 6 Dledger API

2.2 Dledger 的架構(gòu)

Dledger 的架構(gòu)如下圖 7 所示:

 

 

圖 7 Dledger Architecture

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

2.3 Dledger 的代碼

因為 Dledger 只有 CommitLog，沒有 StateMachine，所以代碼很精簡，只有 4000 多行，總體代碼測試覆蓋率大概是 70%。通過如下幾行命令便可以快速地體驗：

 

 

圖 8 Dledge Quick Start

Dledger 源代碼地址：https://github.com/openmessaging/openmessaging-storage-dledger

3. RocketMQ on DLedger

3.1 Dledger 在 RocketMQ 上的應(yīng)用

 

 

圖 9 RocketMQ on Dledger Architecture

Dledger 雖然只需要寫 CommitLog，但是基于 CommitLog 是可以做很多事情的。RocketMQ 原來的架構(gòu)里是有 CommitLog 的，現(xiàn)在用 Dledger 去替代原來的 CommitLog。由于 Dledger 提供了一些可以直接讀取 CommitLog 的 API，于是就可以很方便地根據(jù) CommitLog 去構(gòu)建 ConsumerQueue 或者其他的模塊。這就是 Dledger 在 RocketMQ 上最直接的應(yīng)用。

3.2 Dledger 與 RocketMQ 對接時格式上的區(qū)別：

加了 Dledger 之后，其實就是在原來的消息上面加了一個頭。這個頭就是 Dledger 的頭，本質(zhì)上是一些簡單的屬性，例如 size 等。如下圖 10 所示。

 

 

圖 10 RocketMQ on Dledger Format

在使用的時候會有格式上的差異，所以社區(qū)在升級的時候做了一個平滑升級的考慮，如圖 11 所示。要解決的問題是：如何將原來已有的 CommitLog 和現(xiàn)在基于 Dledger 的 CommitLog 混合?現(xiàn)在已經(jīng)支持自動混合，但是唯一的一個要求是舊版的 CommitLog 需要自己去保持它的一致性。因為 Dledger 的復(fù)制是從新寫入的記錄開始。假設(shè)舊的 CommitLog 已經(jīng)是一致的情況下，然后直接啟動 Dledger ，是可以在舊的 CommitLog 基礎(chǔ)上繼續(xù) append，同時保證新寫消息的一致性，高可靠和高可用。這是 Dledger 直接應(yīng)用到 RocketMQ 上的時候一個格式上的區(qū)別。

 

 

圖 11 RocketMQ on Dledger Smooth Upgrade

對于用戶來說，這樣做最直接的好處是：若使用 Master/Slave 架構(gòu)模式，一旦一個 broker 掛了，則需要手動控制。但是使用 Dledger 之后不需要這么做。因為 Dledger 可以通過自己選舉，然后把選舉結(jié)果直接傳給 RocketMQ 的 broker，這樣通過 nameserver 拿到路由的時候就可以自動找到 leader 節(jié)點去訪問消息，達(dá)到自動切換的目的。如下圖 12 所示。

 

 

圖 12 RocketMQ on Dledger Failover

3.3 Dledger 在多中心場景下的使用

上面只是最基本的應(yīng)用，更直接的應(yīng)用如圖 13 所示：(容災(zāi)切換)

 

 

圖 13 RocketMQ on Dledger Multi Center

這里舉一個真實的金融應(yīng)用場景：杭州、深圳和上海分別代表系統(tǒng)中三個節(jié)點，進(jìn)行消息傳輸。要求：數(shù)據(jù)一條都不能丟，滿足實時高可用并且考慮城市之間的容災(zāi)。

Raft 的論文中沒有提及如何優(yōu)先選擇某個節(jié)點作為 leader，但是我們實現(xiàn)的時候可以自己優(yōu)化。假設(shè)杭州節(jié)點服務(wù)更好，我們可以指定優(yōu)先選擇杭州節(jié)點為 leader。如果杭州節(jié)點宕機(jī)，可以再把 leader 節(jié)點切換到上海，如果上海節(jié)點也掛掉，雖然集群不可用了，但是大部分?jǐn)?shù)據(jù)還在深圳節(jié)點有災(zāi)備。深圳主要起復(fù)制和災(zāi)備的作用，一般情況下不會被選為 leader。

3.4 Dledger 的使用方式

社區(qū) 4.4.0 剛剛發(fā)表，RocketMQ on DLedger 計劃在 4.5.0 發(fā)布，目前可以在分支上獲取代碼：https://github.com/apache/rocketmq/blob/store_with_dledger/docs/cn/dledger/

下載代碼之后，可以通過運(yùn)行社區(qū)提供的簡單腳本 fast-try.sh 來體驗一下。

 

 

圖 14 RocketMQon Dledger Quick Start

4. RocketMQ 社區(qū)發(fā)展

4.1 功能點展望

前面主要講了兩個東西：RocketMQ 和 DLedger。DLedger 主要是作為 OpenMessaging 的一個社區(qū)在孵化，OpenMessaging 針對消息的存儲也抽象出了一套 API，DLedger 是其一個標(biāo)準(zhǔn)的實現(xiàn)。

目前，Github 上的 DLedger 只是實現(xiàn)了 Raft 一些基礎(chǔ)功能。后續(xù)有很多可以擴(kuò)展的功能點，比如：

♦ Leader 節(jié)點優(yōu)先選擇

♦ 手動配置 leader

♦ 自動降級到 master/slave 架構(gòu)

4.2 openmessaging-hakv

再看一下跟 DLedger 定位相似的 Java Library：openmessaging-hakv。openmessaging-hakv 結(jié)構(gòu)圖如圖 15 所示。

 

 

圖 15 openmessaging-hakv

代碼詳見：https://github.com/openmessaging/openmessaging-hakv

目前來看，我們沒有一個嵌入式且高可用的解決方案。RocksDB 可以直接用，但是它本身不支持高可用。有了 DLedger 之后，我們可以把操作的記錄直接寫入 DLedger，但是基于這些記錄恢復(fù)過程我們可以自己選擇。假如數(shù)據(jù)量少，對高可用要求高，比如元數(shù)據(jù)，我們可以直接存在內(nèi)存的 hashmap 中，根據(jù) DLedger 的寫入記錄來構(gòu)建自己的 hashmap，從而達(dá)到數(shù)據(jù)的一致性和容災(zāi)功能。

本文作者：劉振東，GitHub ID dongeforever，阿里巴巴技術(shù)專家，

標(biāo)簽： [db:TAGG]

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。