雲原生消息、事件、流超融合平台——RocketMQ 5.0 初探

前言：本文整理自 RocketMQ x EventMesh OpenDay 金融通演講内容

作者 | 金融通

今天分享的主題是雲原生消息事件流超融合平台 RocketMQ 5.0 初探，内容主要分為三個部分：

首先，帶大家回顧業務消息領域首選 RocketMQ 4 發展曆史以及 4.x 版本的演進與發展。

其次，會為大家詳細介紹 RocketMQ 5.0 發展情況以及一些新特性。

最後，會為大家介紹 RocketMQ 5.0 的發展路線圖，友善社群小夥伴能夠一起參與進來到 5.0 的貢獻中來。

RocketMQ 發展曆程

RocketMQ 自誕生以來前後經曆了四代架構，并伴随着企業IT 架構不斷發展，從 SOA 時代到微服務時代，再到如今的雲原生時代。RocketMQ 最早誕生于阿裡巴巴，阿裡巴巴早期有一些自研的消息引擎，比如淘寶的 Notify、B2B 業務的 Napoli。但無論是 Napoli 還是 Notify，都是基于關系型資料庫進行存儲并帶來了一些隐患。

是以在2011年，阿裡巴巴以檔案系統作為存儲研發了 MetaQ。經過不斷探索，在重寫 MetaQ 2.0 後，第一代 RocketMQ 正是誕生，并将其命名為 RocketMQ 3.0 。2013年，阿裡巴巴對 RocketMQ 進行開源，并在2016年捐獻給 Apache 社群。2017年，RocketMQ 從 Apache 畢業，正式成為 Apache 基金會頂級開源項目。

随着 RocketMQ 進入 Apache 基金會，RocketMQ 4.x 進行快速發展，也釋出了非常多版本，在架構多副本能力、消息類型、消息治理方面都有了非常巨大的飛躍。與此同時，社群生态也茁壯成長，全球 Contributor 數接近 500 人。

伴随着雲原生時代到來，以及實時計算的興起，RocketMQ 也将進行全面更新，釋出 RocketMQ 5.0。我們和社群小夥伴們将 RocketMQ 5.0 定義為雲原生的消息、事件、流的超融合平台。

RocketMQ 4 回顧

回顧 RocketMQ 4，我們一直在強調 RocketMQ 是業務消息首選。非常多公司将 RocketMQ 用于核心交易鍊路上，甚至很多公司會搭建兩套消息系統，一套 Kafka 進行資料分析，另一套 RocketMQ 用于業務消息處理。

那為什麼 RocketMQ 會為成為衆多企業的一緻選擇呢，從以下幾點，也許能一窺究竟：

第一，RocketMQ 是金融級高可靠的産品。相比于其他消息中間件，RocketMQ 經過超大規模驗證。阿裡巴巴幾乎所有消息鍊路都是建立在 RocketMQ 之上，包括核心交易鍊路。比如雙十一當天 RocketMQ 支援了超過數萬億條消息的流轉，與此同時，在阿裡雲上的消息服務也服務了數萬家企業。這些規模龐大的企業對 SLA 同樣有着極高的要求。而這些自身實踐以及客戶服務的大量真實場景打磨對于消息系統的穩定性起到了至關重要的作用。

第二，RocketMQ 有着極簡的架構并且易于維護，整個叢集由 NameServer、Broker 兩部分組成，NameServer 進行路由發現，Broker 作為實際存儲資料的叢集。從架構圖中可以看到，RocketMQ 采用兩主兩備的叢集方式，從節點通過同步複制或者異步複制的方式向主節點同步資料。這樣的部署模式保證了服務能夠具備較高可用性。

通過部署多組 Broker，即使其中一組 Broker 的 Master 出現不可用，也可以發送消息給其他組 Master，Consumer 也能從 Slave 進行讀取。而 NameServer 處于完全無狀态，即使 NameServer 全部當機，由于用戶端已儲存路由資訊，是以也不會影響存量服務。此外，RocketMQ 的運維也非常容易，擴容時隻要增加 Broker 組數即可。如果一組 Broker 出現問題，也可以将它進行禁寫，路由會馬上被摘掉，不會影響其他業務。

RocketMQ 部署也非常簡單，JAR 部署隻需要兩行指令就能把 RocketMQ 進行拉起。在 K8s 上部署就更加簡單，如果用了 RocketMQ Operator ，用一句 kubectl apply 指令就能将整個叢集拉起來。

第三，是豐富的消息類型，RocketMQ 支援普通消息、順序消息、延遲消息、重試消息、死信消息、事務消息等。在消息治理方面，RocketMQ 除了常見的訂閱模式，廣播模式、叢集模式，還支援消息查詢，消息回放，消息軌迹，ACL 權限控制等。此外，RocketMQ 也是業界少有的原生支援服務端過濾的消息産品，可以提供給使用者更加豐富的使用場景，也可以充分利用服務端計算資源。RocketMQ 不僅支援消息的 Tag 過濾，還創新性地支援 SQL92 過濾，Tag 過濾其實已經滿足了絕大部分的過濾需求，如果特别複雜的場景可以考慮 SQL92 過濾方式，兩個過濾方式基本上可以滿足所有消息過濾需求。相比于其他消息中間件而言，RocketMQ 的消息類型和消息治理是最豐富的。

最後 RocketMQ 具備高吞吐低延時的特性。在阿裡巴巴雙十一中，RocketMQ 支撐萬億級洪峰并保持毫秒級響應。

接下來，帶大家回顧一下 RocketMQ 4.x 版本的發展。在開源早期，RocketMQ 就已支援普通消息、順序消息、延遲消息等不同類型消息，基本滿足大多數業務場景。

在 RocketMQ 4.3.0 版本之後，正式釋出事務消息，通過類似于兩階段的方式去解決上下遊資料不一緻問題。

在 RocketMQ 4.4.0 版本中，RocketMQ 增加了消息軌迹的功能，使使用者可以更好定位每一條消息的投放接收路徑，幫助問題排查，另外還增加 ACL 權限控制，提高了 RocketMQ 的管控能力和安全性。

在 4.5.0 版本中，RocketMQ 推出了多副本，也就是 Raft 模式。在 Raft 模式下，一組 Broker 如果 Master 挂了，那麼 Broker 中其他 Slave 就會重新選出主。是以 Broker 組内就擁有了自動故障轉移的能力，也解決了像高可用順序消息這樣的問題，進一步提高了 RocketMQ 的可用性。

在 4.6.0 版本中，我們推出了輕量級 Pull Consumer，使用者可以使用更加适合于流計算的 API，這一版本也開始支援全新的 Request-Reply 消息，使得 RocketMQ 具備了同步調用 RPC 的能力，RocketMQ 可以更好的打破網絡隔離網絡之間的調用，這個版本中 RocketMQ 也開始支援 IPV6，并且是首個支援 IPV6 的消息中間件。

在 4.7.0 版本中，RocketMQ 重構了主備同步複制流程，通過線程異步化，将同步複制和刷盤的過程 Pipeline 化，同步雙寫性能有将近數倍提升。

在 4.8.0 版本中，RocketMQ Raft 模式有了一個質的提升，包括通過異步化、批量複制等手段将性能提升了數倍，在穩定性上利用 OpenChaos 完成包括當機、殺死程序，OOM、各種各樣的網絡分區和延遲的測試，修複了重要 Bug。在功能上，支援 Preferred Leader，進而 Broker 組内可以優先選主，也支援了批量消息等功能。

在 4.9.0 版本，主要是提升了可觀測性，包括支援 OpenTracing，事務消息和 Pull Consumer 支援 Trace 等功能。

可以看到 RocketMQ 在經過多年發展，從性能、穩定性、可靠性、可觀測性等方面都有了很大提高。并且在這一過程中，除了阿裡之外企業在代碼建設方面做出了卓越貢獻，這也證明 RocketMQ 已成為多元化并繁榮發展的社群。

除了 RocketMQ 主倉庫的發展，RocketMQ 生态項目發展也令人備受鼓舞，特别是與雲原生熱點技術的整合，比如說在雲原生化部署上面，我們有 RocketMQ Operator、RocketMQ Docker 這些項目。在微服務開發架構上面，RocketMQ 社群也通過建構 RocketMQ Spring Boot Starter 這種接入方式，友善開源使用者的微服務系統與 RocketMQ 消息隊列的通信能力能夠實作快速內建和打通，以此為基礎 Spring Cloud Stream Binder 和 Spring Cloud Bus 的 RocketMQ 實作也被 Spring Cloud 官方收錄。

在 Service Mesh 方面，RocketMQ 是最早和 Envoy 結合的消息産品，現在也完成了 Dapr 的內建。在 Serverless 方面，包括适配 Cloud Events 以及社群開源了 RocetMQ Knative Source 倉庫。

在可觀測性上，RocketMQ 支援 OpenTracing、OpenTelemetry、Prometheus Exporter 等 。

在 Eventing 領域，我們有自己的 RocketMQ Connector，可以去完成各種外部元件，比如 MySQL、ElasticSearch 與 RocketMQ 的資料互動和資料同步，也能完成 MQ 叢集之間的一個資料流轉。在 Streaming 領域， RocketMQ 5.0 會釋出原生的輕量級實時計算架構 RocketMQ-Streams，另一方面 RocketMQ 也積極和 Flink、Storm 、Spark 等現有大資料架構進行內建。

我們可以看到 RocketMQ 不僅是業務消息的管道，也在承擔着事件流轉、業務資料的一些離線計算和輕量級的實時計算。通過消息、事件、流三個方面發展，RocketMQ 已形成完整自閉環的生态發展，正在逐漸成為消息、事件、流的超融合的處理平台。

RocketMQ5.0 概覽

在正式介紹 RocketMQ 5.0 之前，我們需要先回答這樣一個問題：為什麼我們需要 RocketMQ 5.0，在跟衆多貢獻者溝通以及對 RocketMQ 大量運維實踐後，發現這裡有兩大原因：

首先，開源社群的需求越發凸顯，當大量企業采用 RocketMQ 後，每個使用者都有豐富的業務場景。而 RocketMQ 4.x 主要服務于業務消息領域，那麼如何通過 RocketMQ 進行實時資料計算去處理這些高價值資料，成為企業下一步探索的重要方向。這也是 RocketMQ 為什麼會從消息領域去積極拓展流計算領域的原因。

其次，雲消息服務品質要求不斷提高，作為 RocketMQ 深度參與者與貢獻者，阿裡雲的消息服務目前已服務數萬家企業。随着客戶企業對于服務的要求，以及阿裡巴巴自身的業務發展，這都對 RocketMQ 有了更高要求。如何做到一套架構，同時能滿足不同使用者不同場景需求，成為 RocketMQ 5.0 中重點解決的問題。

是以，結合廣泛的實際業務場景，RocketMQ 5.0 作為生于雲、長于雲的全新的架構，經過不斷探索實踐，RocketMQ 5.0 主要具備以下特性：

1. 高 SLA、低成本：與雲一緻的可用性、高性能、低成本

2. 可排程：任意元件的重塑與組建适應多樣性場景

3. 可擴充：開放的豐富生态

4. 可伸縮性：極緻自動化擴容/縮容

5. 标準化：社群标準，符合行業标準

RocketMQ 5.0 作為雲原生的消息事件流的超融合平台，基于架構圖我們一一進行講解：

1. 輕量級 SDK

RocketMQ 5.0 提供輕量級的用戶端，使之具備良好的內建與被內建能力。同時，将負載均衡、邏輯位點管理這些複雜邏輯都放到服務端，實作無狀态化。在協定選擇方面，除了原有協定之外，全面支援雲原生通信标準 gRPC 協定。

2. 極簡架構

RocketMQ 5.0 依然不會去引入任何外部依賴，保持極低的運維負擔。同時，節點之間的松散耦合，任意服務節點可以随時進行遷移。RocketMQ 5.0 将會是面向失敗的設計，任意的服務節點的失敗和遷移都是可以忍受的。

3. 可分可合的存儲計算分離架構

Broker 節點會成為真正無狀态的服務節點，并且沒有 Topic Banding。也就是說消息的發送和消費是可以發生在任意計算節點上，一個接入點即可代理所有流量，計算層以及存儲層均可獨立進行彈性擴縮。在存儲計算分離後，計算節點可以處理不同類型的協定，包括 Remoting、gRPC，MQTT、AMQP 等。此外包括 ACL、訂閱關系、多租的控制等都會放在計算節點上。最重要的一點，它是可分可合的，可以支援小叢集，也可以支援超大規模的叢集，并且能适應多種業務的場景，降低運維的負擔。

4. 多模存儲

RocketMQ Raft 模式采取三副本形态，與本身就擁有三副本的雲盤結合之後，相當于就得到了 9 副本。9 副本雖然帶來了更高的可靠性，但也造成了嚴重的成本浪費。是以，RocketMQ 5.0 通過多模存儲解決這一問題。比如，在普通的塊儲存設備上，可以根據可用性需求完成兩副本或三副本部署。在雲上用單副本，進而更好的支援雲盤輸出，充分利用雲上基礎設施去降低運維成本。

5. 雲原生基礎設施的廣泛使用與整合

支援 OpenTelemetry、Prometheus 等項目，強化 RocketMQ 可觀測能力。并更好去支援 K8s 生态，比如 RocketMQ Operator 用一條指令即可拉起 RocketMQ 叢集，并且去完成向灰階釋出資料的全生命周期管理，自動彈性擴縮等方面的支援。

核心特性一：可分可合的存儲計算分離架構

接下來，詳細介紹一下可分可合的存儲計算分離架構。可分可合指的是 RocketMQ 可以像現在一樣用同一程序去啟動 Broker，也可以分開部署。分開部署之後計算節點就能真正的做到無狀态，RocketMQ 對存儲計算分離的架構的引進是非常謹慎的，一體化部署帶來了諸多好處，比如大資料場景下，一體化部署提供就近計算能力，降低帶寬成本。業務消息場景下，一體化部署可以降低延遲。與此同時，存儲計算分離也有非常多的好處，比如說擴縮容可以更加靈活，可以針對具體計算資源或存儲資源進行擴縮容。

是以 RocketMQ 5.0 将會提供可分可合的存儲計算分離架構，可以适應多種場景。計算節點是完全無狀态的。包括像協定适配、流量租戶等管控都會放在計算節點上完成。此外，通過 POP 消費方式把整個用戶端的負載均衡邏輯位的管理上升到計算節點，無 Queue Binding，任意的計算節點都能進行收發。另外，由于無狀态，可以完成秒級彈性擴縮，并且過程中是沒有 Rebalance 負擔的。

與此同時，RocketMQ 5.0 會對存儲叢集進行了優化調整。在存儲叢集中我們原生的保留了多消息類型的存儲支援，包括事務消息、定時消息，重試消息、死信消息等。在副本的選擇上，根據不同場景去提供不同支援，包括本地塊裝置多副本支援、雲盤單副本支援。借助多模态存儲功能，充分利用雲上基礎設施降低成本。

另一點非常重要的是多元索引的支援。現在 RocketMQ 存儲是一份 CommitLog ，背景線程去分發建構 ConsumeQueue、index 這些索引。那麼 RocketMQ 5.0 會對索引全面增強，支援更多樣索引。比如加入批處理的索引，消息就可以完成批量發送，批量存儲，批量接收，進而提升 RocketMQ Batch 能力。比如消息隊列隻做消息輪轉，查詢能力比較弱，在 RocketMQ 5.0 中，消息和 KV 會更好結合在一起，去建構查詢索引進而增強 KV 能力。通過一份資料，多種索引，RocketMQ 5.0 可以滿足不同場景。

核心特性二：流批一體的資料通路方式

首先介紹全新的消費模式——POP 消費方式。左上角的圖是 RocketMQ 4.0 現有消費端的負載均衡架構。比如現在 Topic 分布在 3 個 Broker 上，共計 9 個隊列。在叢集模式下，1 個消費組有 3 個消費者。根據。是以每個消費者配置設定到了三個隊列。

但這也帶來了一些問題，比如說某 Consumer 突然 Hang 住了，這它無法消費消息但也沒有掉線，仍然保持和 Broker 的心跳連接配接，是以也不會将剔除而進行重平衡，是以這個消費者配置設定到的隊列就會有大量的消息堆積，這些隊列的消費就會卡住。

這本質上是一個綁定關系問題，一旦 Rebalance 發生後，Consumer 和隊列就完成了綁定。針對這個問題，RocketMQ 5.0 推出了一個全新的消費方式，即 POP 消費方式。它取消了 Rebalance 造成的綁定關系，一個隊列可以被任意多個 Consumer 進行消費，然後在 Broker 端通過隊列鎖完成并發控制。

POP 消費中，用戶端會直接到每個 Broker 的隊列進行請求消費， Broker 會把消息配置設定傳回給等待的用戶端。随後用戶端消費結束後傳回對應的 ACK 結果通知 Broker，Broker 再标記消息消費結果，如果逾時沒響應或者消費失敗，再會進行重試。

Broker 對于每次 POP 的請求，都會有以下三個操作：

1. 對應的隊列進行加鎖，然後從 Store 層擷取該隊列的消息；

2. 然後寫入 CK 消息，表明擷取的消息要被 POP 消費；

3. 最後送出目前位點，并釋放鎖。

CK 消息實際上是記錄了 POP 消息具體位點的定時消息，當用戶端逾時沒響應的時候，CK 消息就會重新被 Broker 消費，然後把 CK 消息的位點的消息寫入重試隊列。如果 Broker 收到用戶端的消費結果的 ACK ，删除對應的 CK 消息，然後根據具體結果判斷是否需要重試。

從整體流程可見，POP 消費并不需要 Reblance ，可以避免 Rebalance 帶來的消費延時，同時用戶端可以消費 Broker 的所有隊列，這樣就可以避免機器 Hang 住而導緻堆積的問題。

有了 POP、PUSH、PULL 等模式之後，RocketMQ 就可以完成流批一體的資料通路方式。比如說在 Streaming 場景下，通過原本 PUSH 方式可以保證很好的順序消費。但批處理等對順序要求并不高的場景中，我們可以用 POP 消費的方式對同一隊列進行高并發讀取，加快資料讀取速度。另一方面 POP 消費模式也使得用戶端更加輕量化，大量的邏輯都在服務端，對多語言用戶端的編寫也是更加友好的。

核心特性三：極緻彈性擴縮

上圖是 RocketMQ 現有架構，比如說我們通過禁寫操作，可以使 Broker 1001 的流量自然流入到 1002 上。但在 Streaming 領域，上層業務一般要求存儲隊列始終固定的，隻有這樣才能保證流式資料處理的順序性和完整性，這也就要求擴縮容不會引起隊列數量的變化。是以 RocketMQ 5.0 Preview 版本提供了一個邏輯隊列概念，把原本的實體隊列邏輯組合在一起，一個邏輯隊列可以分散到不同 Broker 上面。比如圖中的一個邏輯隊列，0～100 在 Broker 1001 上，100～1000 在 Broker 1002 上，1000～2000 的在 Broker 1003 上，通過組合可以把多個實體隊列串聯成了一個大的邏輯隊列。

由于邏輯隊列是一個 Binding 過程，是以是非常輕量級的操作，是以提供了一個秒級彈性擴充的一個能力，過程中完全沒有也沒有資料的複制，隻要一完成 Broker 擴容，完成綁定操作，流量也就完成了調撥。另外我們也提供雙模隊列相容的能力，平時預設還是原來的實體隊列，隻有指定單個 Topic 開啟後，才會使用邏輯隊列。

核心特性四：輕量級實時計算

RocketMQ 5.0 中還有一個非常重量級的特性，将會推出輕量級的實時計算架構 RocketMQ Streams。它的設計目标是幫助使用者在不依賴外部重量級計算産品的情況下，僅利用已有 RocketMQ 資源完成大多數業務場景需要的輕量級的資料處理和計算。

RocketMQ Stream 依賴少、部署簡單，它利用 RocketMQ Rabalance 能力可以任意橫向擴充，同時支援包括 Map、Fliter 這些常見的算子，還有 Window、Join、維表等。另外相比于其他基于消息的實時計算平台，RocketMQ Streams 除提供原生無依賴的支援外，可以相容 Flink SQL 标準以及提供 UDF/UDAF/UDTF 的能力。

另一方面，在實時計算生态上面，RocketMQ 也積極的和其他的大資料架構進行對接，包括 Flink、Spark 等 。特别是基于最新标準的 RocketMQ-Flink Connector 也會近期畢業。

RcoketMQ 5.0 Landscape

RocketMQ 5.0 版本将在今年正式釋出， 5.0 Preview 的版本已經在 Discuss 了，代碼也放在 Github 倉庫中，5.0 Preview 版本會推出邏輯隊列，以及流批一體的通路方式等重磅特性。之後我們會正式釋出實時流計算架構 RocketMQ Streams，并在 RocketMQ 5.0 支援批處理、批索引能力。在後續的裡程碑中 RocketMQ 5.0 将會完成 gRPC 協定支援，全新的輕量級用戶端，完成 AMQP、MQTT 協定等支援，以及可分可合的存儲與計算分離架構。

也希望能有更多的小夥伴參與到 Apache RocketMQ 社群中來，一起打造來下一代雲原生消息引擎，打造 Messaging、Eventing、Streaming 的超融合處理平台。