大家好，我是君哥。

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

1、架構(gòu)變化

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

RocketMQ 4.x 架構(gòu)如下：

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

這個(gè)架構(gòu)存在以下幾個(gè)問(wèn)題：

1.富客戶端，客戶端同時(shí)支持 Java、C++、Go 等各種語(yǔ)言，如果為了跟應(yīng)用程序隔離，把客戶端部署到 sidecar 中，這個(gè) sidecar 會(huì)很大，部署難度高；

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

RocketMQ 5.0 架構(gòu)如下圖：

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

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

2、集成事件、流處理

RocketMQ 5.0 采用事件驅(qū)動(dòng)架構(gòu)來(lái)支持消息流式處理和輕計(jì)算，可以實(shí)現(xiàn)消息的就近計(jì)算和分析。

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

（1）流式處理

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

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

（2）計(jì)算框架

在計(jì)算框架方面，RocketMQ 5.0 主要有兩個(gè)變化：

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

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

3、高可用

在 RocketMQ 5.0 之前，高可用架構(gòu)有兩個(gè)階段：

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

2.RocketMQ 4.5 之后采用基于 raft 協(xié)議的 DLedger 算法來(lái)進(jìn)行主從切換，架構(gòu)如下圖：

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

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

對(duì)于 Master-Slave 架構(gòu)的升級(jí)，RocketMQ 5.0 引入了 BrokerContainer 的概念，一個(gè) BrokerContainer 中可以部署多個(gè) Broker，這些 Broker 擁有獨(dú)立的端口，功能完全獨(dú)立，可以通過(guò) admin 來(lái)增加或減少 Broker。如下圖：

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

同時(shí)，在一個(gè) BrokerContainer 中可以同時(shí)部署 Broker 的 Master 和 Slave 節(jié)點(diǎn)，這樣就可以通過(guò) Master/Slave 交叉部署來(lái)實(shí)現(xiàn)節(jié)點(diǎn)對(duì)等，如下圖兩節(jié)點(diǎn)對(duì)等部署：

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

再看下面三個(gè)節(jié)點(diǎn)的對(duì)等部署架構(gòu)圖：

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

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

基于 Raft 架構(gòu)雖然可以實(shí)現(xiàn)主節(jié)點(diǎn)故障后自動(dòng)切換，但也存在幾個(gè)問(wèn)題：

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

2.Raft 選主過(guò)程中必須有多數(shù)節(jié)點(diǎn)同意才能選主成功，副本數(shù)越多時(shí)間開(kāi)銷會(huì)越大，這會(huì)加大 ACK 延時(shí)；

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

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

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

4、總結(jié)

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