三 Raft在CMQ中的應(yīng)用

早期我們在rabbitmq的基礎(chǔ)上搭建了一套可擴(kuò)展消息中間件CRMQ1.0，由于rabbitmq的GM同步算法在性能等方面存在瓶頸，所以自研了基于raft算法的內(nèi)部版本CRMQ2.0和騰訊云CMQ，在保證強(qiáng)一致高可靠的前提下，性能和可用性都有顯著提升。實現(xiàn)上采用了生產(chǎn)Confirm + 消費(fèi)Ack機(jī)制保證消息不丟失，Confirm和Ack機(jī)制均通過raft來保證。生產(chǎn)的消息通過Raft轉(zhuǎn)為Entry同步到大多數(shù)節(jié)點(diǎn)并提交，完成后各節(jié)點(diǎn)狀態(tài)機(jī)應(yīng)用該Entry，將消息內(nèi)容寫入磁盤，之后由Leader節(jié)點(diǎn)回復(fù)客戶端Confirm，表示消息生產(chǎn)成功。消費(fèi)時客戶端從Leader節(jié)點(diǎn)拉取消息，消費(fèi)完成后通過Ack命令通知服務(wù)端消息已消費(fèi)可刪除，Ack請求經(jīng)Raft同步后，各節(jié)點(diǎn)應(yīng)用該請求，之后消息被刪除不會再投遞。下面介紹詳細(xì)過程：

生產(chǎn)流程：

1)生產(chǎn)者將生產(chǎn)消息的請求發(fā)往Leader的Raft模塊。

2)Raft模塊完成Entry的創(chuàng)建和同步。

3)大多數(shù)節(jié)點(diǎn)上持久化并返回成功后Entry標(biāo)記為Committed。

4)所有節(jié)點(diǎn)的State Machine應(yīng)用該日志，取出實際的生產(chǎn)請求，將消息內(nèi)容寫入磁盤，更新ApplyIndex。該步驟不需要刷盤。

5)Leader回復(fù)客戶端Confirm，通知生產(chǎn)成功。

6)如果此后機(jī)器重啟，通過raft日志恢復(fù)生產(chǎn)消息，保證了已Confirm的消息不丟失。

消費(fèi)流程：

1)消費(fèi)者從Leader節(jié)點(diǎn)拉取消息。

2)Leader收到后從磁盤加載未刪除的消息投遞給客戶端。

3)客戶端處理完成后Ack消息，通知服務(wù)器刪除消息。

4)Ack請求經(jīng)Raft同步后標(biāo)記為Committed。

5)各節(jié)點(diǎn)狀態(tài)機(jī)應(yīng)用該日志，將消息對應(yīng)的bit置位，將其設(shè)置為已刪除并更新ApplyIndex。

6)通知客戶端刪除成功。

7)如果機(jī)器重啟，通過Raft日志恢復(fù)Ack請求，保證了已刪除的消息不會再投遞。

快照管理：

快照管理與業(yè)務(wù)緊密相關(guān)，不同系統(tǒng)快照制作的成本差異很大，CMQ中快照的內(nèi)容十分輕量，一次快照的耗時在毫秒級，平均5min創(chuàng)建一次，各節(jié)點(diǎn)獨(dú)立完成。實現(xiàn)上內(nèi)存中維護(hù)了一份動態(tài)的快照，制作快照時首先拷貝出動態(tài)快照的副本，之后處理流繼續(xù)更新動態(tài)快照，用拷貝出的副本創(chuàng)建快照文件，不影響實際的處理流。快照具體內(nèi)容包括：

1)term：快照對應(yīng)Entry的term (參照算法)

2)index：快照對應(yīng)Entry的 index (參照算法)

3)node_info：Entry時的集群配置信息。

4)topic info：每個隊列一項。CMQ中同一隊列生產(chǎn)的消息順序?qū)懭?，分片存儲，因此只需記?**一個分片的狀態(tài)(分片文件名，文件偏移量)。

5)queue info：每個隊列一項。CMQ中采用bitmap記錄消息的刪除情況，在內(nèi)存中維護(hù)，在制作快照時dump到快照文件。

可靠性：業(yè)界統(tǒng)一的衡量標(biāo)準(zhǔn)為RPO(Recovery Point Objective)，反映故障時數(shù)據(jù)恢復(fù)完整性的指標(biāo)。由于只有提交的日志才會被應(yīng)用到狀態(tài)機(jī)，且raft日志在寫入時會強(qiáng)制刷盤，所以故障重啟后通過快照+raft日志即可恢復(fù)，不會丟失數(shù)據(jù)，RPO=0。不過，如2.7節(jié)所述，Leader故障時可能會產(chǎn)生重復(fù)數(shù)據(jù)，需要通過冪等性保證或去重機(jī)制來解決該問題。

可用性：業(yè)界統(tǒng)一的衡量標(biāo)準(zhǔn)為RTO(Recovery Time Objective)，反映故障時業(yè)務(wù)恢復(fù)及時性的指標(biāo)。follower故障對系統(tǒng)沒有影響(RTO=0)，leader故障時其他節(jié)點(diǎn)通過自發(fā)選出新leader，而且CMQ中前端具備自動重連功能，當(dāng)連接斷開后會自動尋找新leader，系統(tǒng)不可用時間大大降低。目前CMQ中配置的選舉超時時間為2s~4s，在不考慮選舉沖突的前提下，RTO上限為4s。

在CMQ中，Leader通過與Follower的心跳判斷自己是否已網(wǎng)絡(luò)分區(qū)，當(dāng)檢測到分區(qū)時(大多數(shù)節(jié)點(diǎn)上次心跳回復(fù)時間距現(xiàn)在超過2s)，主動斷開前端連接，前端發(fā)現(xiàn)后會自動尋找新Leader。這段時間內(nèi)客戶端請求會超時，在連上新Leader后，客戶端重試之前超時的任務(wù)，后續(xù)請求恢復(fù)正常。

四 Raft算法性能優(yōu)化

Raft算法的性能瓶頸主要有兩方面：

1) 每次日志寫入后都需要刷盤才能返回成功，而刷盤是一個比較耗時的操作。

2) 由于算法限制，所有的請求都由Leader處理，不能做到所有節(jié)點(diǎn)皆可提供服務(wù)。

針對以上兩個問題，我們做了以下優(yōu)化：

1)Batch Processing：在請求量較大時，并不是每一條日志寫入都刷盤，還是累積一定量的日志后集中刷盤，從而減少刷盤次數(shù)。對應(yīng)的，在同步到Follower時也采用批量同步的方式，F(xiàn)ollower接收后將日志批量寫盤。

2)Multi-Raft： 進(jìn)程中同時運(yùn)行多個raft實例，機(jī)器之間組建多raft 組，客戶端請求路由到不同的group上，從而實現(xiàn)多主讀寫，提高并發(fā)性能。通過將leader分布在不同機(jī)器上，提高了系統(tǒng)的整體利用率。

3)Async-rpc： 在日志同步過程中采用同步rpc方式，在一端處理時另一端只能等待，性能較差。我們采用異步的方式使得leader端發(fā)送和Follower端處理并發(fā)進(jìn)行。發(fā)送過程中l(wèi)eader端維持一個發(fā)送窗口，當(dāng)待確認(rèn)的rpc數(shù)達(dá)到上限停止發(fā)送，窗口值上限：

在與同屬于高可靠(多副本同步刷盤)的Rabbitmq性能對比中，相同壓測場景下CMQ速度可以達(dá)到RabbitMQ的四倍左右。

以下為TS60機(jī)器1KB消息大小時性能數(shù)據(jù)：

測試中CMQ采用單Raft組方式以保證測試公平性。監(jiān)控顯示CPU、內(nèi)存和網(wǎng)卡均未達(dá)到瓶頸，系統(tǒng)瓶頸在磁盤IO，iostat顯示w_await遠(yuǎn)大于svctm。主要原因在于刷盤耗時，造成寫操作排隊等待。

實際生產(chǎn)環(huán)境CMQ中我們將raft組和磁盤進(jìn)行綁定，實現(xiàn)raft組之間磁盤的隔離，一方面保證了磁盤的順序讀寫，另一方面充分利用機(jī)器的cpu 、內(nèi)存、網(wǎng)卡等資源。

五 通用Raft庫

CMQ中完整實現(xiàn)了Raft算法并解決了很多細(xì)節(jié)難點(diǎn)?？紤]到分布式系統(tǒng)設(shè)計的復(fù)雜性，如果開發(fā)者只專注于業(yè)務(wù)相關(guān)部分，將可以顯著降低開發(fā)難度，提高系統(tǒng)的質(zhì)量，所以我們將CMQ中的raft部分以庫的方式獨(dú)立出來，使用者用它即可搭建一套強(qiáng)一致高可用分布式系統(tǒng)。目前該庫已經(jīng)完成基線版本開發(fā)并在部門落地使用，驗證完成后會陸續(xù)開放給更多業(yè)務(wù)使用。

六 總結(jié)

消息中間件通常分為高可靠版本和高性能版本兩種。CMQ是一款金融級的高可靠分布式消息中間件，通過raft保證了消息的可靠不丟失。同時在性能和可用性方面相比競品都有顯著提高。此外，我們自研的高性能版本的消息中間件ckafka也已在騰訊云上線，***兼容kafka0.09~0.10版本客戶端，關(guān)于CKafka的具體技術(shù)介紹請關(guān)注后續(xù)技術(shù)文章。

Raft算法強(qiáng)調(diào)了Leader的地位，選舉和日志同步都是圍繞Leader展開。由Leader負(fù)責(zé)處理所有請求保證了系統(tǒng)的強(qiáng)一致性;Leader選舉和日志同步算法保證了數(shù)據(jù)的可靠不丟失;此外上述步驟只需要大多數(shù)正常互聯(lián)即可，從而極大提高了系統(tǒng)的可用性，少量機(jī)器故障不受影響。不過，所有請求由Leader處理并沒有充分利用從節(jié)點(diǎn)的資源，目前google的Spanner已支持從從節(jié)點(diǎn)讀取，后續(xù)我們也會在這方面作更進(jìn)一步的研究。Raft算法易于理解和工程化，相信未來會應(yīng)用在越來越多的分布式系統(tǒng)中。

原文鏈接：https://cloud.tencent.com/community/article/937437

【本文是51CTO專欄作者“騰訊云技術(shù)社區(qū)”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系原作者獲取授權(quán)】

戳這里，看該作者更多好文