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個。
詳情查看 http://rocketmq.apache.org/release_notes/release-notes-4.8.0/。