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

​

​

文章转载自公众号：君哥聊技术