大家好，我是君哥。

RocketMQ 5.0 已經發布一段時間了，今天來分享一下 RocketMQ 5.0 有哪些新特性。

1 架構變化

RocketMQ 5.0 架構上的變化主要是為了更好的走向云原生。

RocketMQ 4.x 架構如下：

Broker 向 Name Server 注冊 Topic 路由信息，Producer 和 Consumer 則從 Name Server 獲取路由信息，然后 Producer 根據路由信息向 Broker 發送消息，Consumer 則根據路由信息從 Broker 拉取消息。

這個架構存在以下幾個問題：

1.富客戶端，客戶端同時支持 Java、C++、Go 等各種語言，如果為了跟應用程序隔離，把客戶端部署到 sidecar 中，這個 sidecar 會很大，部署難度高；

2.Broker 同時承擔計算和存儲的功能，不利于云原生環境下的資源解耦。

RocketMQ 5.0 架構如下圖：

RocketMQ 5.0 在架構上主要做了兩個優化：1.通過引入無狀態的代理模塊，將 Broker 原來的協議適配、權限管理、消息管理等計算功能抽離到了代理模塊中，Broker 則專注于存儲功能。這樣在云環境下可以更好地進行資源調度；

2.RocketMQ 5.0 基于 gRPC 支持多語言 SDK，各語言 SDK API 在本地語言層面對齊，API 非常輕量級，更容易被使用和集成。

2 集成事件、流處理

RocketMQ 5.0 采用事件驅動架構來支持消息流式處理和輕計算，可以實現消息的就近計算和分析。

RocketMQ 5.0 增加了 RocketMQ-EventBridge 組件，這個組件兼容標準 CloudEvents 協議標準，既可以鏈接社區活躍的生態，又可以跟各大云廠商的產品進行集成，對云原生的支持非常友好。下面這張圖來自官網：

2.1 流式處理

為了更好地支持流失處理，RocketMQ 5.0 在原有 MessageQueue 的基礎上抽象出了邏輯隊列。一個邏輯隊列可以包含多個物理隊列，以此拼接出流式隊列。如下圖：

這樣可以更加輕量級，做到秒級的擴縮容，即使物理節點發生變化也不需要復制遷移數據，數據存儲的調度也更加靈活。

2.2 計算框架

在計算框架方面，RocketMQ 5.0 主要有兩個變化：

1.引入流式處理框架 RSteams，這樣 RocketMQ 自身就可以完成輕量級的理和計算；

2.引入輕量級 SQL 查詢引擎 RSQLDB，RSQLDB 可以兼容了 Flink/Blink SQL 標準，實現了 RocketMQ 和 Flink/Blink 的融合。比如對于輕量級的計算，可以使用 SQL 在 RocketMQ 完成，而對于重量級的計算，RocketMQ 資源受限時，可以從 RocketMQ 遷移到 Flink 處理。

3 高可用

在 RocketMQ 5.0 之前，高可用架構有兩個階段：

1.RocketMQ 4.5 之前采用 Master-Slave 部署，這種架構 Master 發生故障后是不能自動切換的，對集群的影響會比較大；

2.RocketMQ 4.5 之后采用基于 raft 協議的 DLedger 算法來進行主從切換，架構如下圖：

3.1 Master-Slave 架構優化

RocketMQ 5.0 對 Master-Slave 架構和基于 Raft 的架構都做了優化。

對于 Master-Slave 架構的升級，RocketMQ 5.0 引入了 BrokerContainer 的概念，一個 BrokerContainer 中可以部署多個 Broker，這些 Broker 擁有獨立的端口，功能完全獨立，可以通過 admin 來增加或減少 Broker。如下圖：

這樣一個 BrokerContainer 中的多個 Broker 可以共享同一個節點的資源，提高資源利用率。

同時，在一個 BrokerContainer 中可以同時部署 Broker 的 Master 和 Slave 節點，這樣就可以通過 Master/Slave 交叉部署來實現節點對等，如下圖兩節點對等部署：

即使 Node1 掛了，Node2 節點中的 Broker1 可以提供讀功能，并不會丟消息，Broker2 可以提供讀寫功能。

再看下面三個節點的對等部署架構圖：

每個 Node 的 BrokerContainer 中都有 1 個 Master 跟 2 個 Slave 節點，如果其中一個 Node 掛了，其他兩個 Node 上的 Broker 可以繼續提供讀寫服務。

3.2 Raft 架構優化

基于 Raft 架構雖然可以實現主節點故障后自動切換，但也存在幾個問題：

1.消息日志副本數必須是 3 個以上，這個是 Raft 協議自動選主的要求，造成資源浪費；

2.Raft 選主過程中必須有多數節點同意才能選主成功，副本數越多時間開銷會越大，這會加大 ACK 延時；

3.CommitLog 主從同步需要使用 DLedger 庫，也就是說 CommitLog 被看作是 Raft log 進行復制，這樣 RocketMQ 原生的零拷貝、堆外內存的優勢無法保留了。

RocketMQ 5.0 專門增加了輕量級的 DLedgerControlller 選主組件，將選主的切換能力上移，這個組件是可拔插的，既可以部署在 NameServer 中，也可以部署在本地。如下圖：

引入了 DLedgerControlller 組件后，消息主備復制還是采用 RocketMQ 原生的基于 Master-Slave 架構的復制能力，復制效率高。

4 總結

本文概括性地介紹了 RocketMQ 5.0 比較有亮點的新特性，希望能夠讓你對新版本有一定了解，深入的介紹見后面的文章。