大家好，我是君哥。

RocketMQ 5.0 已經(jīng)發(fā)布一段時間了，今天來分享一下 RocketMQ 5.0 有哪些新特性。

1、架構變化

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

RocketMQ 4.x 架構如下：

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

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

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

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

RocketMQ 5.0 架構如下圖：

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

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

2、集成事件、流處理

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

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

（1）流式處理

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

這樣可以更加輕量級，做到秒級的擴縮容，即使物理節(jié)點發(fā)生變化也不需要復制遷移數(shù)據(jù)，數(shù)據(jù)存儲的調(diào)度也更加靈活。

（2）計算框架

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

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

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

3、高可用

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

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

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

（1）Master-Slave 架構優(yōu)化

RocketMQ 5.0 對 Master-Slave 架構和基于 Raft 的架構都做了優(yōu)化。

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

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

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

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

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

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

（2）Raft 架構優(yōu)化

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

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

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

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

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

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

4、總結(jié)

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