大家好，我是君哥。

今天來介紹一下 RocketMQ 5.0 源碼上的變化。

RocketMQ 5.0 是一個里程碑式的版本，經歷了近 5 年的打磨，代碼變更達到 60%。

首先看一下源碼中模塊的變化，如下圖：

從圖中可以看到，RocketMQ 5.0 主要增加了 4 個模塊兒，下面介紹一下這 4 個模塊兒。

1、bazel

bazel 是 Google 開源的構建工具，目前廣泛用于云計算領域的開源軟件（如 Kubernetes）構建，它有如下特點：1.支持增量式編譯、支持緩存、支持分布式擴展；2.bazel 可以清晰地以依賴關系圖的方式展現出當前的依賴關系，比 makefile 更加方便；3.bazel支持多語言構建。

RocketMQ 5.0 引入了 bazel 構建。

2、container

在 RocketMQ 4.x 時代，如果采用 Master-Slave 架構，Broke 節點一旦掛了，是不能自動切換的。RocketMQ 5.0 對這個架構進行了改進，引入了 BrokerContainer 的概念，一個 BrokerContainer 中可以部署多個 Broker，這些 Broker 擁有獨立的端口，功能完全獨立，并且可以共享同一個節點的資源。如下圖：

有創造性的是，在一個 BrokerContainer 中可以交叉部署 Master 和 Slave 節點，如下圖兩節點對等部署：

這樣做有即使 Node1 節點掛了，Node2 節點中的 Broker1 可以提供讀功能，并不會丟消息，而 Broker2 則可以繼續提供讀寫功能。

3、controller

RocketMQ 5.0 引入了 DLedger Controller 架構，解決傳統 DLedger 架構的不足。

（1）傳統 DLedger

在 RocketMQ 4.x 中，如果采用 DLedger 架構部署，Broker 掛掉后，是可以自動實現主從切換的。但這樣需要用 Raft Commitlog 來取代 RocketMQ 自身的 Commitlog，因為只有這樣 Commitlog 才會具有選舉的能力。Broker 主節點掛掉后，從節點依照 DLedger 協議進行內部協商，選舉出新的主節點，自動完成主備切換。

不過這樣存在幾個問題：

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

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

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

（2）DLedgerController

通過引入 DLedger Controller 架構，RocketMQ 將 DLedger 選主切換的能力獨立成一個可以拔插的組件，這樣 Master-Slave 架構也可以具有 Failover 的能力。

DLedger Controller 可以獨立部署，也可以部署在 NameServer 中，共享 NameServer 資源。

部署在 NameServer：

獨立部署：

4、Proxy

RocketMQ 5.0 為了更好地擁抱云原生，實現了計算和存儲相分離。把計算相關的功能抽象到了 Proxy，協議適配、權限管理、消息管理等。Broker 則專注于存儲，架構如下圖：?

這樣 RocketMQ 可以更好地上云，更好地進行資源調度。?

5、總結

本文從源碼角度講述了 RocketMQ 5.0 主要的變化。

為了更好地擁抱云原生， RocketMQ 5.0 架構上發生了比較大的變化，實現計算存儲相分離，并且引入 bazel 進行構建。

在高可用方面，RocketMQ 5.0  對傳統的基于 DLedger 的高可用進行了改造，同時引入了 BrokerContainer 對等部署方案。

希望本文對你理解新版本的 RocketMQ 有所幫助。