Apache RocketMQ 發展歷程回顧
RocketMQ 最早誕生于淘寶的在線電商交易場景，經過了歷年雙十一大促流量洪峰的打磨，2016年捐獻給 Apache 社區，成為 Apache 社區的頂級項目，并在國內外電商，金融，互聯網等各行各業的廣大客戶落地驗證，得到廣泛認可。
Apache RocketMQ 社區在2022年10月正式對外發布了全新的5.0版本，騰訊云消息隊列團隊也和社區緊密合作，支持了5.0的商業化版本，現在將整個落地過程的經驗教訓做個總結，回饋社區。
什么是 RocketMQ 5.0？
一個新版本號？
一套新設計的API？
一系列新的特性實現？
一個存算分離的新架構？
一種新的商業化產品形態？
RocketMQ 面向云原生的新思考？
Apache RocketMQ 社區過去一年對5.0新架構從不同的角度進行了分享介紹，導致很多用戶對5.0新架構認識不一致，其實從以上不同角度理解都對，本文嘗試從多個維度做一個較全面的解釋和回顧，幫助用戶全面理解 RocketMQ 5.0 架構演進背后的思考邏輯。
RocketMQ 5.0 的演進目標
- 基礎架構適應云原生化
RocketMQ 運行依賴的環境過去十年發生了巨大的變化，從最早的物理機部署開始，到現在云計算已經深入人心，資源越來越“彈性伸縮, 按量付費, 高SLA”，計算資源容器化，存儲資源都演進為標準的分布式存儲，比如塊存儲、文件存儲和對象存儲越來越成熟和標準化，尤其是以S3 為代表的對象存儲，對比其他存儲有很大的成本優勢，所以新架構的演進就是要充分利用新計算和存儲資源的優勢。
- 輕量API和完善多語言SDK支持
RocketMQ 4.x 以前的協議，基于十多年前設計的私有Remoting協議，導致開發非 JAVA 語言的 SDK 成本非常高，所以 5.0 基于 gRPC 設計的全新 API 和 Proxy 模式，可以極大的方便多語言 SDK 開發，豐富多語言生態。
- 消息、事件、流場景與生態拓展集成
社區還開源了 EventBridge, Connector, Stream, MQTT 等周邊項目，有助于完善和增強周邊生態，拓展更多業務場景。
RocketMQ 5.0 的關鍵新特性
為了支持以上三個主要的演進目標，RocketMQ 5.0 版本引入了大量新的技術和特性，下面將一些關鍵特性逐個簡要介紹，其中不少特性已經在騰訊云投入實際使用，并發揮了業務價值。
POP 消費模式
RocketMQ 5.0 之前版本只提供了Pull的消費模式(即使 PushConsumer 也是通過 Pull 和長輪訓模擬的 Push 效果)，Pull 消費模式和 Kafka 消費模式類似，也是需要在客戶端做負載均衡，計算客戶端實例和隊列的映射關系，然后再消費消息和維護隊列的位點信息，通過新的 POP 消費模式，帶來了以下明顯的好處：
- 不需要在客戶端計算分配邏輯，簡化客戶端邏輯。
- 降低了客戶端 SDK 開發的復雜度，便于快速支持多語言客戶端。
- 消費位點完全維護在 Broker 端，避免單個消費節點慢導致消費延遲。
- 適配其他協議的 Proxy 模式更順暢，方便支持多消費模型時做推拉轉換。
騰訊云在 RocketMQ 5.0 的產品形態中，支持5.0新協議和兼容其他消息協議的過程中，都采用了 POP 消費模式，方便支持了 Proxy 的完全無狀態和負載均衡。
更詳細的 POP 方案設計擴展閱讀參考：
- [RIP 19] Server side rebalance, lightweight consumer client support：https://Github.com/apache/rocketmq/wiki/%5bRIP-19%5d-Server-side-rebalance,--lightweight-consumer-client-support
- [RIP 51] Pop orderly improvement：https://github.com/apache/rocketmq/wiki/RIP-51-Pop-orderly-improvement
基于 gRPC 的新 API 設計
RocketMQ 社區過去幾年在支持 RocketMQ 4.x 客戶端的過程中，越來越意識到 Remoting 協議的不足，開發非Java SDK 的門檻和成本過高，導致各個公司推出了基于 HTTP 等其他協議多種兼容 Proxy 方案，這次新 API 相當于官方出了一個統一的可擴展 Proxy 方案，方便各公司在這個 Proxy 的基礎上，合并兼容一些其他協議，統一和簡化架構，最終形成一個以RocketMQ Broker 為存儲內核，兼容各種消息協議的無狀態 Proxy 的存算分離統一架構。
騰訊云在落地新架構的過程中，因為 Proxy 要處理協議序列化和轉換等 CPU 密集型計算，要注意對 CPU 占用的優化，我們也向社區提了多個優化代碼，以下是我們對4C8G規格的參考壓測數據：
Proxy 壓測過程中典型火焰圖占用分析如下：
更詳細的關于新方案設計和擴展閱讀詳見：
- [RIP37] New and Unified APIs：https://shimo.im/docs/m5kv92OeRRU8olqX
- [RIP39] Support gRPC protocol：https://shimo.im/docs/gXqmeEPYgdUw5bqo
- [RIP55] Supportremoting protocol in rocketmq proxy module：https://github.com/apache/rocketmq/wiki/RIP-55-Support-remoting-protocol-in-rocketmq-proxy-module
秒級定時消息
定時消息是在線消息場景經常用的一種消息類型，發送方發送消息以后，并不想讓訂閱方立即消費到消息，而是等一段時間以后，消息對訂閱方可見，典型的業務場景是訂單下單五分鐘后檢查訂單狀態，或交易成功后第二天固定時間生成積分或優惠券。
RocketMQ 5.0 之前的版本，只能利用重試消息固定間隔的機制，實現Level固定級別的定時消息，5.0 新版本中重新實現了定時消息，可以支持超大規模超?時間任意秒級粒度的定時消息。
更詳細的關于秒級定時消息方案設計和擴展閱讀參考：
- [RIP43] Support timing messages with arbitrary time delay：https://shimo.im/docs/gXqme9PKKpIeD7qo
分層存儲
RocketMQ 4.x 只支持本地磁盤或云盤等塊設備作為持久化存儲介質，塊設備存儲雖然能帶來低延遲和可靠性，但是其存儲成本卻是對象存儲的5~10倍，而消息隊列數據是典型的冷熱分布的數據，根據作者在實際系統的統計，約85%熱數據在10分鐘內通過內存緩存讀取，其次10%溫數據可能會在1小時內讀走，約有5%的冷數據只有長時間堆積或回溯消費的場景才會被讀到。
RocketMQ 5.0 引入了分層存儲技術，可以將冷數據搬遷到更廉價的存儲中，比如對象存儲，可以在不降低用戶體驗的前提下，極大的降低綜合存儲成本。實現思路如下圖所示，通過寫入時將消息異步復制到分層存儲，讀取時優先讀取本地存儲，不命中的話再讀取遠程存儲，實現分層存儲的目的。
騰訊云在落地分層存儲的過程中，一級存儲選擇了騰訊云云盤CBS，二級存儲選擇了騰訊云對象存儲COS，以下表格是我們在騰訊云上的一個性能測試報告，開啟分層存儲對在線業務幾乎不會有影響，這也與代碼預期行為一致（dispatch異步寫對象存儲、熱數據讀本地緩存），二級存儲單分區消費可以支持7500msg/s，擴分區可以等比例擴容消費速度，可以滿足線上需求標準。
更詳細的實現方案詳見RIP文檔:
- [RIP57] Tieredstorage for RocketMQ：https://github.com/apache/rocketmq/wiki/RIP-57-Tiered-storage-for-RocketMQ
- [RIP65] TieredStorage Optimization：https://github.com/apache/rocketmq/wiki/RIP-65-Tiered-Storage-Optimization
基于KV的百萬隊列索引
RocketMQ 4.x 版本中，每個 Topic 實際都是由多個隊列來存儲消息的，隊列的數據存在統一的 Commitlog 中，消息隊列索引是通過文件隊列來存儲消息索引的，當隊列少于1萬時，可以穩定高效的提供讀寫服務，當隊列數超過10萬以后，隊列索引會退化成嚴重的隨機寫，導致性能嚴重下降。
RocketMQ 5.0 引入 RocksDB 存儲隊列索引，利用 RocksDB 的 LSM 索引結構特性，將大量文件隊列索引的隨機寫轉化為 SST 文件的順序寫，即使有上百萬個消息隊列，從整個架構看，底層云盤依然只有少量的順序寫文件，依然可以穩定的提供消息讀寫服務。
以下是在我們測試環境測得的數據，隊列數量少的時候，兩個方案的從 TPS 和耗時指標差別不大，但是隊列數超過20萬以后，基于 RocksDB 的索引方案性能和穩定性的優勢明顯。
更詳細的實現方案介紹參考：
● [RIP66] Support KV(Rocksdb) Storage：https://github.com/apache/rocketmq/wiki/RIP-66-Support-KV(Rocksdb)-Storage
● 百萬隊列能力支持：https://www.bilibili.com/video/BV19u4y1r7Qd
原生批量消息支持
RocketMQ 4.x 的版本中的批量消息是一個“偽批量”消息實現，需要在發送方發送一個業務層面組織好的消息數組，RocketMQ Broker 收到消息數組后，會再拆成多個消息，逐個處理消息的寫入，舊方案雖然兼容性好，實現簡單，但是只優化了網絡開銷，壓縮和存儲性能優化不明顯。
RocketMQ 5.0 引入了新的 AutoBatch 特性，對批量消息做了全鏈路的優化，從發送端的自動攢批編程界面，到新的存儲格式和索引結構，都做了全面的優化。
以下是 RocketMQ 社區咸魚(guyinyou · GitHub)同學提供的幾種場景的壓測數據，對比普通消息吞吐量翻倍提升，對比 Kafka 同等節點規格和業務場景下可以達到幾乎相同的吞吐，在分區增加的場景下，提供更優的發送延時抖動：
使用同樣測試節點和 Kafka 作性能對比，部署架構都采用3節點2副本的測試場景下，同樣 16 分區下可以達到幾乎同樣的吞吐量但更低的發送延時，并且隨著分區數增加，RocketMQ 的穩定性和發送延時有明顯的優勢。
更詳細的設計文檔和測試結果詳見：
- [RIP26] Improve Batch Message Processing Throughput：https://github.com/apache/rocketmq/wiki/RIP-26-Improve-Batch-Message-Processing-Throughput
- 活動回顧丨RocketMQ Meetup 開源開發者沙龍（含 PPT）：https://mp.weixin.qq.com/s/qSbzqn0ZqsdRUjFpvNOuBg
jRaft Controller 實現
RocketMQ 4.x 主從復制提供了簡單高效的消息高可靠方案，但是一直存在一個無法自動切換主從的功能缺失，DLedger 模式雖然通過基于 Raft 的三副本解決了自動選主的問題，但是性能比較差，并且機器成本高。
RocketMQ 5.0 新增了一個 Controller 組件(此組件可以和 Namesrv 合并部署)，解決主從復制部署模式下自動切換的問題，但是社區默認的 Controller 組件是基于 DLedger 實現的，Raft 實現并不完善，騰訊云消息團隊同學為社區提供了一個新的基于 SOFAJRaft 更成熟的 Raft 實現方案，可以實現更穩定可靠的主從切換。
不同副本和同步機制的性能對比如下圖所示：
在騰訊云測試環境的混沌測試結果全部通過：
更多JRaft Controller的詳細設計文檔參考：
- [RIP44] Support DLedger Controller：https://github.com/apache/rocketmq/wiki/RIP-44-Support-DLedger-Controller
- [RIP67] jRaft-Controller Implemention：https://docs.google.com/document/d/1mpzTv1vnWxQwPGsHj6Ng2fK9aL9f6MZFw7ZgvW5284o
- jRaft Controller 故障測試報告：https://docs.google.com/document/d/1eWaKHcs3jGoWtqzmhQovhvKecY1EFW9BLIP0pfA-5fQ/edit#heading=h.d5b71yh9i1wy
其他新特性索引
RocketMQ 社區針對大的特性變更，都會有詳細 RIP 文檔和評審流程，限于篇幅，本文只挑了幾個關鍵新特性做了簡要介紹，更多新特新可以參考社區全部 RIP 列表鏈接：https://github.com/apache/rocketmq/wiki/RocketMQ-Improvement-Proposal。
騰訊云 RocketMQ 的商業化歷程
騰訊云消息隊列團隊過去幾年基于 Apache RocketMQ 社區走過了完整的商業化歷程，在2023年9月正式推出了5.x 商業化版本，提供極致彈性和更低成本的 RocketMQ 服務，滿足不同場景對 RocketMQ 的差異化需求，并已經在金融、出行、教育、游戲等多個行業落地實踐。
新存算分離架構升級
在騰訊云內部，我們也將部署架構做了調整，按照 RocketMQ 5.0 推薦的存算分離架構，簡化 RocketMQ 的運維，也可以為用戶提供更好的升降配彈性體驗。
下圖是 RocketMQ 5.0 新的存算分離架構：
全新的 5.0 Serverless 產品形態
基于以上新的存算分離新架構，我們推出了新的 TDMQ RocketMQ 5.0 Serverless 產品形態，通過全新的按量計費模式，并且專業版以上免費提供了彈性TPS的能力，可以更低成本來應對突發流量。
落地實踐總結與展望
回顧 RocketMQ 過去十年的發展歷程，可以看到 RocketMQ 社區的蓬勃發展和功能的快速迭代演進，并且在國內各大云廠商也有快速的落地支持，騰訊云也會持續的大力研發投入，給 RocketMQ 用戶提供了更多更優的選擇。
騰訊云在 RocketMQ 商業化過程中，也積極回饋 RocketMQ 社區，近一年騰訊云為 RocketMQ 社區貢獻了 30+ 缺陷修復和性能優化代碼合并，并且貢獻了一個 RIP 67，也希望未來和 RocketMQ 社區更緊密配合，為 Apache RocketMQ 的繁榮發展做出貢獻，為用戶提供更優質的 RocketMQ 服務。
