“童年的雨天最是泥濘，卻是記憶裡最乾淨的曾經。凜冬散盡，星河長明，新的一年，萬事順遂，再見，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 部署形態保持一致。