簡介：今天分享的主題是云原生消息事件流超融合平臺 RocketMQ 5.0 初探，內容主要分為三個部分： 首先，帶大家回顧業務消息領域首選 RocketMQ 4 發展歷史以及 4.x 版本的演進與發展。 其次，會為大家詳細介紹 RocketMQ 5.0 發展情況以及一些新特性。 最后，會為大家介紹 RocketMQ 5.0 的發展路線圖，方便社區小伙伴能夠一起參與進來到 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 CloudBus 的 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 的超融合處理平臺。

原文鏈接：https://developer.aliyun.com/article/793225?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。 與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的云原生消息、事件、流超融合平台——RocketMQ 5.0 初探的全部內容，希望文章能夠幫你解決所遇到的問題。

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