RocketMQ 5.0 VS RocketMQ 4.x 变化知多少？
RocketMQ 5.0 VS RocketMQ 4.x 变化知多少？
RocketMQ 5.0 VS RocketMQ 4.x 变化知多少？
今天来介绍一下 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 有所帮助。
结语
如果这篇文章对您有所帮助，或者有所启发的话，求一键三连：点赞、评论、收藏?关注，您的支持是我坚持写作最大的动力。