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

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

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

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

性能升級

• 異步化 pipeline 模式

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

• 批量日志復制

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

除了上述的性能優化，社區還對 DLedger 模式下影響性能的鎖、緩存等做了數項性能優化，使 DLedger 模式下的性能提升數倍。

穩定性升級

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

• random-partition（fixed-partition）故障隨機挑選節點進行網絡隔離，模擬常見的對稱網絡分區。

• random-loss 故障隨機挑選節點并對這些節點接收和發送的網絡包進行按比例丟棄，模擬一些節點網絡較差的情況。

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

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

• bridge 和 partition-majorities-ring 故障模擬比較極端的非對稱網絡分區。

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

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

圖中縱坐標是是時延，橫坐標是測試時間，綠色框表示數據發送成功，紅色框表示數據發送失敗，藍色框表示不確定是否數據添加成功，灰色部分表示故障注入的時間段。可以看出一些故障注入時間段造成了集群短暫的不可用，一些故障時間段則沒有，這是合理的。由于是隨機網絡分區，所以只有殺死的少數節點包含 leader 節點時才會造成集群重新選舉，但即使造成集群重新選舉， DLedger 模式在一段時間后也會恢復可用性。

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

在 OpenMessaging Chaos 測試過程中，我們發現了 DLedger 模式存在的數個隱性問題并進行了修復，提高了 DLedger 模式下對進程異常崩潰、慢節點、對稱/非對稱網絡分區、網絡丟包的容錯能力，也進一步驗證了 DLedger 模式的可靠性。

功能升級

• DLedger 模式支持 Preferred Leader

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

• DLedger 模式支持批量消息

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。