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

丶龙八夷
发布于 2023-7-21 11:35
浏览
0收藏

大家好,我是君哥。

RocketMQ 5.0 已经发布一段时间了,今天来分享一下 RocketMQ 5.0 有哪些新特性。

1 架构变化

RocketMQ 5.0 架构上的变化主要是为了更好的走向云原生。

RocketMQ 4.x 架构如下:

RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!-鸿蒙开发者社区

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 大手笔,拥抱云原生,支持流处理,高可用架构升级!-鸿蒙开发者社区

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 协议标准,既可以链接社区活跃的生态,又可以跟各大云厂商的产品进行集成,对云原生的支持非常友好。下面这张图来自官网:

RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!-鸿蒙开发者社区

2.1 流式处理

为了更好地支持流失处理,RocketMQ 5.0 在原有 MessageQueue 的基础上抽象出了逻辑队列。一个逻辑队列可以包含多个物理队列,以此拼接出流式队列。如下图:

RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!-鸿蒙开发者社区

这样可以更加轻量级,做到秒级的扩缩容,即使物理节点发生变化也不需要复制迁移数据,数据存储的调度也更加灵活。

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 算法来进行主从切换,架构如下图:

RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!-鸿蒙开发者社区

3.1 Master-Slave 架构优化

RocketMQ 5.0 对 Master-Slave 架构和基于 Raft 的架构都做了优化。

对于 Master-Slave 架构的升级,RocketMQ 5.0 引入了 BrokerContainer 的概念,一个 BrokerContainer 中可以部署多个 Broker,这些 Broker 拥有独立的端口,功能完全独立,可以通过 admin 来增加或减少 Broker。如下图:

RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!-鸿蒙开发者社区

这样一个 BrokerContainer 中的多个 Broker 可以共享同一个节点的资源,提高资源利用率。

同时,在一个 BrokerContainer 中可以同时部署 Broker 的 Master 和 Slave 节点,这样就可以通过 Master/Slave 交叉部署来实现节点对等,如下图两节点对等部署:

RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!-鸿蒙开发者社区

即使 Node1 挂了,Node2 节点中的 Broker1 可以提供读功能,并不会丢消息,Broker2 可以提供读写功能。

再看下面三个节点的对等部署架构图:

RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!-鸿蒙开发者社区

每个 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 中,也可以部署在本地。如下图:

RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!-鸿蒙开发者社区

引入了 DLedgerControlller 组件后,消息主备复制还是采用 RocketMQ 原生的基于 Master-Slave 架构的复制能力,复制效率高。

4 总结

本文概括性地介绍了 RocketMQ 5.0 比较有亮点的新特性,希望能够让你对新版本有一定了解,深入的介绍见后面的文章。

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

分类
标签
已于2023-7-21 11:35:51修改
收藏
回复
举报
回复
    相关推荐