大家好，我是君哥。
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 比較有亮點的新特性，希望能夠讓你對新版本有一定了解，深入地介紹一下後面的文章。
原文：https://mp.weixin.qq.com/s/GDtORf76Zq7GlCGnLJHsrg
作者：朱晉君
如果覺得本文對你有幫助，可以點贊關注支援一下