作者 | RocketMQ社區(qū)
來源|阿里巴巴云原生公眾號

“童年的雨天最是泥濘，卻是記憶里最干凈的曾經(jīng)。凜冬散盡，星河長明，新的一年，萬事順遂，再見，2020！”

走過這個歲末，萬眾期待的 Apache RocketMQ 4.8.0 終于發(fā)布了，在這個版本中社區(qū)對 RocketMQ 完成大量的優(yōu)化和問題修復(fù)。更重要的是，該版本從性能、穩(wěn)定性、功能三個方面大幅度提升 DLedger 模式能力。

DLedger?是 OpenMessaging?中一個基于 Raft 的 CommitLog 存儲庫實現(xiàn)，從 RocketMQ 4.5.0 版本開始，RocketMQ 引入 DLedger 模式來解決了 Broker 組內(nèi)自動故障轉(zhuǎn)移的問題，而在 4.8.0 版本中社區(qū)也對 RocketMQ DLedger 模式進行了全面升級。

性能升級

• 異步化 pipeline 模式

RocketMQ 4.7.0 重新升級了同步雙寫的架構(gòu)，利用異步化 pipeline 模式大幅提升了同步雙寫的性能。在 RocketMQ 4.8.0 中，社區(qū)將這一改進應(yīng)用到 DLedger 模式中, 下圖展示了 DLedger 模式下 broker 處理發(fā)送消息的過程。在原本的架構(gòu)中, SendMessageProcessor 線程對每一個消息的處理，都需要等待多數(shù)派復(fù)制成功確認，才會返回給客戶端，而在新版本中，利用 CompletableFuture 對線程處理消息的過程進行異步化改造，不再等待多數(shù)派的確認即可對下一個請求進行處理，Ack 操作由其他線程確認之后再進行結(jié)果處理并返回給客戶端。通過對復(fù)制過程進行切分并將其流水線化，減少線程的長時間等待，充分利用 CPU，從而大幅提高吞吐量。

• 批量日志復(fù)制

Batch 一直是性能優(yōu)化的重要方式，在新版本中，可以通過設(shè)置 isEnableBatchPush=true 來開啟 DLedger 模式的批量復(fù)制。通過將多條數(shù)據(jù)聚合在一個包中進行發(fā)送，可以降低收發(fā)包的個數(shù)，從而降低系統(tǒng)調(diào)用和上下文的切換。在數(shù)據(jù)發(fā)送壓力比較大，并且可能達到系統(tǒng)收發(fā)包瓶頸的情況下，批量復(fù)制能顯著提高吞吐量。值得注意的是，DLedger 模式下的批量復(fù)制并不會對單個包進行延時的攢批處理，因此不會影響單個消息的發(fā)送時延。

除了上述的性能優(yōu)化，社區(qū)還對 DLedger 模式下影響性能的鎖、緩存等做了數(shù)項性能優(yōu)化，使 DLedger 模式下的性能提升數(shù)倍。

穩(wěn)定性升級

為了驗證和測試 Dledger 模式的可靠性，除了本地對 DLedger 模式進行了各種各樣的測試，社區(qū)利用 OpenMessaging-Chaos?框架對 RocketMQ DLedger 模式進行了大量 Chaos 測試。OpenMessaging-Chaos 是一個利用故障注入來驗證各種消息平臺一致性和高可用性的測試框架，在 OpenMessaging-Chaos 的測試中，客戶端并發(fā)地向待測試集群發(fā)送和接收消息，中間會間隔性地對集群進行故障注入，最后給出測試結(jié)果，包括是否丟消息，是否有重復(fù)消息，集群平均故障恢復(fù)時間等。利用 OpenMessaging-Chaos，我們驗證了 DLedger 模式在以下故障注入場景下的表現(xiàn)：

• random-partition（fixed-partition）故障隨機挑選節(jié)點進行網(wǎng)絡(luò)隔離，模擬常見的對稱網(wǎng)絡(luò)分區(qū)。

• random-loss 故障隨機挑選節(jié)點并對這些節(jié)點接收和發(fā)送的網(wǎng)絡(luò)包進行按比例丟棄，模擬一些節(jié)點網(wǎng)絡(luò)較差的情況。

• random-kill（minor-kill、major-kill、fixed-kill）故障模擬常見的進程崩潰情況。

• random-suspend（minor-suspend、major-suspend、fixed-suspend）故障模擬一些慢節(jié)點的情況，比如發(fā)生 Full GC、OOM 等。

• bridge 和 partition-majorities-ring 故障模擬比較極端的非對稱網(wǎng)絡(luò)分區(qū)。

以 minor-kill 故障注入為例，我們部署 5 個節(jié)點組成一組 DLedger 模式的 RocketMQ broker 進行 Chaos 測試。minor-kill 故障注入會隨機挑選集群中少數(shù)節(jié)點進程殺死，由于殺死少數(shù)節(jié)點，即使集群不可用也能在一段時間內(nèi)恢復(fù)，方便測試集群平均故障恢復(fù)時間。

測試過程中我們設(shè)置四個客戶端并發(fā)向 RocketMQ DLedger 集群發(fā)送和接收消息，故障注入時間間隔為 100s，即 100s 正常運行，100s 故障注入，一直循環(huán)，整個階段一共持續(xù) 2400s。測試結(jié)束后，OpenMessaging-Chaos 會給出測試結(jié)果和時延圖。下圖展示了整個測試過程中入隊操作的時延情況。

圖中縱坐標是是時延，橫坐標是測試時間，綠色框表示數(shù)據(jù)發(fā)送成功，紅色框表示數(shù)據(jù)發(fā)送失敗，藍色框表示不確定是否數(shù)據(jù)添加成功，灰色部分表示故障注入的時間段?？梢钥闯鲆恍┕收献⑷霑r間段造成了集群短暫的不可用，一些故障時間段則沒有，這是合理的。由于是隨機網(wǎng)絡(luò)分區(qū)，所以只有殺死的少數(shù)節(jié)點包含 leader 節(jié)點時才會造成集群重新選舉，但即使造成集群重新選舉， DLedger 模式在一段時間后也會恢復(fù)可用性。

下圖是測試結(jié)束后 OpenMessaging-Chaos 給出的統(tǒng)計結(jié)果，可以看到一共成功發(fā)送了 11W 個數(shù)據(jù)，沒有數(shù)據(jù)丟失，這表明即使在故障下，RocketMQ DLedger 模式仍舊滿足 At Least Once 的投遞語義。此外，RTOTestResult 表明 12 次故障時間段一共發(fā)生了 3 次集群不可用的情況（與上述時延圖一致），但每次集群都能在 30 秒以內(nèi)恢復(fù)，平均故障恢復(fù)時間在 22 秒左右。

在 OpenMessaging Chaos 測試過程中，我們發(fā)現(xiàn)了 DLedger 模式存在的數(shù)個隱性問題并進行了修復(fù)，提高了 DLedger 模式下對進程異常崩潰、慢節(jié)點、對稱/非對稱網(wǎng)絡(luò)分區(qū)、網(wǎng)絡(luò)丟包的容錯能力，也進一步驗證了 DLedger 模式的可靠性。

功能升級

• DLedger 模式支持 Preferred Leader

在舊版本中一組 Broker 中選誰作為 Leader 完全是隨機的。但是在新版中我們可以通過配置 preferredLeaderId 來指定優(yōu)先選舉某個節(jié)點為 Leader，如下圖所示，通過在三個機房部署 DLedger 模式的 broker 組，利用 preferred leader 可以更好的實現(xiàn)機房對齊的功能，圖中 DC1 中服務(wù)更好，我們可以優(yōu)先選擇在 DC1 中部署 Master。此外，利用 preferred leader 還可以更好實現(xiàn) DLedger 集群混部，從而充分利用機器資源。

• DLedger 模式支持批量消息

從 RocketMQ 4.8.0 開始，DLedger 模式支持批量消息發(fā)送，從而在消息類型的支持上完全與 Master-Slave 部署形態(tài)保持一致。

除了對 DLedger 模式的大量優(yōu)化，本次 RocketMQ 版本一共包含 Improvement 25 個，Bug Fix 11 個，文檔和代碼格式優(yōu)化 16 個。據(jù)不完全統(tǒng)計，這些貢獻來自近 40 位 RocketMQ 社區(qū)的 Contributor，感謝大家的積極參與。也非常期待有更多的用戶、廠商、開發(fā)者參與到 RocketMQ 建設(shè)中來，加入 Apache RocketMQ 社區(qū)，永遠不會太遲！

總結(jié)

以上是生活随笔為你收集整理的再见 2020！Apache RocketMQ 发布 4.8.0，DLedger 模式全面提升！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。