今天来介绍一下 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 架构的不足。

3.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 原生的零拷贝、堆外内存的优势无法使用了。

3.1 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 有所帮助。