RocketMQ 5.0 大手笔，拥抱云原生，支持流处理，高可用架构升级！

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 比较有亮点的新特性，希望能够让你对新版本有一定了解，深入的介绍见后面的文章。