Apache RocketMQ 5.0 架构解析：如何基于云原生架构支撑多元化场景

本文将从技术角度了解 RocketMQ 的云原生架构了解 RocketMQ 如何基于一套统一的架构支撑多元化的场景。文章主要包含三部分内容。首先介绍 RocketMQ 5.0 的核心概念和架构概览然后从集群角度出发从宏观视角学习 RocketMQ 的管控链路、数据链路、客户端和服务端如何交互最后介绍消息队列最重要的模块存储系统了解 RocketMQ 如何实现数据的存储和数据的高可用以及如何利用云原生存储进一步提升竞争力。概览在介绍 RocketMQ 的架构之前先从用户视角来看下 RocketMQ 的关键概念以及领域模型。如下图这里按照消息的流转顺序来介绍。在 RocketMQ 中消息生产者一般对应业务系统的上游应用在某个业务动作触发后发送消息到 Broker。Broker 是消息系统数据链路的核心负责接收消息、存储消息、维护消息状态、消费者状态。多个 broker 组成一个消息服务集群共同服务一个或多个 Topic。生产者生产消息并发送到 Broker消息是业务通信的载体每个消息包含消息 ID、消息 Topic、消息体内容、消息属性、消息业务 key 等。每条消息都属于某个 Topic表示同一个业务的语义。在阿里内部交易消息的 Topic 被称为 Trade购物车消息称为 Cart生产者应用会将消息发送到对应的 Topic 上。Topic 里还有 MessageQueue用于消息服务的负载均衡与数据存储分片每个 Topic 包含一个或多个 MessageQueue分布在不同的消息 Broker。生产者发送消息Broker 存储消息消费者负责消费消息。消费者一般对应业务系统的下游应用同一个消费者应用集群共用一个 Consumer Group。消费者会与某个 Topic 产生订阅关系订阅关系是 Consumer GroupTopic 过滤表达式的三元组符合订阅关系的消息会被对应的消费者集群消费。接下来就从技术实现角度进一步深入了解 RocketMQ。架构概览下图是一张 RocketMQ 5.0 的架构图RocketMQ 5.0 的架构从上往下可分为 SDK、NameServer、Proxy 与 Store 层。SDK 层包括 RocketMQ 的 SDK用户基于 RocketMQ 自身的领域模型来使用 SDK。除了 RocketMQ 自身的 SDK 之外还包括细分领域场景的业界标准 SDK比如面向事件驱动的场景RocketMQ 5.0 支持 CloudEvents 的 SDK面向 IoT 的场景RocketMQ 支持物联网 MQTT 协议的 SDK为了方便更多传统应用迁移到 RocketMQ还支持了 AMQP 协议未来也会开源到社区版本里。Nameserver 承担服务发现与负载均衡的职责。通过 NameServer客户端能获取 Topic 的数据分片与服务地址链接消息服务器进行消息收发。消息服务包含计算层 Proxy 与存储层 RocketMQ Store。RocketMQ 5.0 是存算分离的架构这里的存算分离强调的主要是模块和职责的分离。Proxy 与 RocketMQ Store 面向不同的业务场景可以合并部署也可以分开部署。计算层 Proxy 主要承载消息的上层业务逻辑尤其是面向多场景、多协议的支持比如承载 CloudEvents、MQTT、AMQP 的领域模型的实现逻辑与协议转换。面向不同的业务负载还可将 Proxy 分离部署独立弹性比如在物联网场景Proxy 层独立部署可以面向海量物联网设备连接数进行弹性伸缩与存储流量扩缩容解耦。RocketMQ Store 层则负责核心的消息存储包括基于 Commitlog 的存储引擎、多元索引、多副本技术与云存储集成扩展。消息系统的状态全部下沉到 RocketMQ Store其组件全部实现无状态化。服务发现下面详细看一下 RocketMQ 的服务发现如下图所示。RocketMQ 的服务发现的核心是 NameServer下图是 Proxy 与 Broker 合并部署的模式也是 RocketMQ 最常见的模式。每个 Broker 集群会负责某些 Topic 的服务每个 broker 都会将自身服务的 topic 信息注册到 NameServer下面简称 NS集群与每个 NameServer 进行通信并定时与 NS 通过心跳机制来维持租约。服务注册的数据结构包含 topic 与 topic 分片。示例中 broker1 与 broker2 分别承载 topicA 的一个分片。在 NS 机器上会维护全局视图topicA 有两个分片分别在 broker1 与 broker2。RocketMQ SDK 在对 TopicA 进行正式的消息收发之前会随机访问 NameServer 机器从而获取到 topicA 有哪些分片每个数据的分片在哪个 broker 上与 broker 建立好长连接然后再进行消息的收发。大部分项目的服务发现机制会通过 zookeeper 或 etcd 等强一致的分布式协调组件来担任注册中心的角色而 RocketMQ 有自己的特点如果从 CAP 的角度来看注册中心采用 AP 模式NameServer 节点无状态是 shared-nothing 的架构有更高的可用性。如下图RocketMQ 的存算分离可分可合采用分离的部署模式RocketMQ SDK 直接访问无状态的 Proxy 集群。该模式可以应对更复杂的网络环境支持多网络类型的访问如公网访问实现更好的安全控制。在整个服务发现机制中NameServer、Proxy 都为无状态可以随时进行节点增减。有状态节点 Broker 的增减基于 NS 的注册机制客户端可以实时感知、动态发现。在缩容过程中RocketMQ Broker 还可以进行服务发现的读写权限控制对缩容的节点禁写开读待未读消息全消费后再实现无损平滑下线。负载均衡通过上文的介绍了解了 SDK 是如何通过 NameServer 来发现 Topic 的分片信息 MessageQueue以及 Broker 地址的基于这些服务发现的元数据下面再来详细介绍下消息流量是如何在生产者、RocketMQ Broker 和消费者集群进行负载均衡的。生产链路的负载均衡如下图如所示生产者通过服务发现机制获取到 Topic 的数据分片以及对应的 Broker 地址。服务发现机制是比较简单在默认情况下采用 RoundRobin 的方式轮询发送到各个 Topic 队列保证 Broker 集群的流量均衡。在顺序消息的场景下会略有不同基于消息的业务主键 Hash 到某个队列发送如果有热点业务主键Broker 集群也可能出现热点。除此之外基于元数据还能根据业务需要扩展更多的负载均衡算法比如同机房优先算法可以降低多机房部署场景下的延迟提升性能。消费者的负载均衡拥有两种类型的负载均衡方式包括队列级负载均衡和消息粒度的负载均衡。最经典的模式是队列级负载均衡消费者知道 Topic 的队列总数和同一个 Consumer Group 下的实例数可以按照统一的分配算法类似于一致性 hash 的方式使每个消费者实例绑定对应队列只消费绑定队列的消息每个队列的消息也只会被消费者实例消费。该模式最大的缺点是负载不均衡消费者实例要绑定队列且有临时状态。如果有三个队列有两个消费者实例则必然有消费者需要消费 2/3 的数据如果有 4 个消费者则第四个消费者会空跑。因此RocketMQ 5.0 引入了消息粒度的负载均衡机制无需绑定队列消息在消费者集群随机分发保障消费者集群的负载均衡。更重要的是该模式更加符合未来 Serverless 化的趋势Broker 的机器数、Topic 的队列数与消费者实例数完全解耦可以独立扩缩容。存储系统前面通过架构概览和服务发现机制已经对 RocketMQ 有比较全局性的了解接下来将深入 RocketMQ 的存储系统。存储系统对 RocketMQ 的性能、成本、可用性有决定性作用。RocketMQ 的存储核心由 commitlog、ConsumeQueue 与 index 文件组成。消息存储首先写到 commitlog刷盘并复制到 slave 节点完成持久化commitlog 是 RocketMQ 存储的 source of true可以通过它构建完整的消息索引。相比于 KafkaRocketMQ 将所有 topic 的数据都写到 commitlog 文件最大化顺序 IO使得 RocketMQ 单机可支撑万级的 topic。写完 commitlog 之后RocketMQ 会异步分发出多个索引首先是 ConsumeQueue 索引与 MessageQueue 对应基于索引可以实现消息的精准定位可以按照 topic、队列 ID 与位点定位到消息消息回溯功能也是基于该能力实现的。另外一个很重要的索引是哈希索引它是消息可观测的基础。通过持久化的 hash 表来实现消息业务主键的查询能力消息轨迹主要基于该能力实现。除了消息本身的存储之外broker 还承载了消息元数据的存储以及 topic 的文件包括 broker 会对哪些 topic 提供服务还维护了每个 topic 的队列数、读写权限、顺序性等属性subscription、consumer offset 文件维护了 topic 的订阅关系以及每个消费者的消费进度abort、checkpoint 文件则用于完成重启后的文件恢复保障数据完整性。Topic 高可用前面站在单机的视角从功能的层面学习 RocketMQ 的存储引擎包括 commitlog 和索引。现在重新跳出来再从集群视角看 RocketMQ 的高可用。RocketMQ 的高可用指当 RocketMQ 集群出现 NameServer、Broker 局部不可用时指定的 topic 依然可读可写。RocketMQ 可以应对三类故障场景。场景 1某对 Broker 的单机不可用比如当 Broker2 主节点宕机备节点可用TopicA 依然可读可写其中分片 1 可读可写分片 2 可读不可写TopicA 在分片 2 的未读消息依然可以消费。总结来说即只要 Broker 集群里任意一组 Broker 存活一个节点则 Topic 的读写可用性不受影响。如果某组 Broker 主备全部宕机则 Topic 新数据的读写也不受影响未读消息会延迟待任意主备启动才能继续消费。场景 2NameServer 集群部分不可用由于 NameServer 是 shared-nothing 架构每个节点都为无状态并且为 AP 模式无需依赖多数派算法因此只要有一台 NameServer 存活则整个服务发现机制都正常Topic 的读写可用性不受影响。场景 3NameServer 全部不可用由于 RocketMQ 的 SDK 对服务发现元数据有缓存只要 SDK 不重启依然可以按照当下的 topic 元数据继续进行消息收发。MessageQueue 的高可用基础概念上一个小节中讲到 Topic 的高可用原理从它的实现中可以发现虽然 Topic 持续可读可写但是 Topic 的读写队列数发生变化。队列数变化会对某些数据集成的业务有影响比如说异构数据库 Binlog 同步同一个记录的变更 binlog 会写入不同的队列重放 binlog 可能会出现乱序导致脏数据。所以还需要对现有的高可用进一步增强要保障在局部节点不可用时不仅 Topic 可读可写并且 Topic 的可读写队列数量不变指定的队列也是可读可写的。如下图NameServer 或 Broker 任意出现单点不可用Topic A 依然保持 2 个队列每个队列都具备读写能力。5.0 HA 的特点为了解决上述的场景RocketMQ 5.0 引入全新的高可用机制核心概念如下DLedger Controller基于 raft 协议的强一致元数据组件执行选主命令维护状态机信息。SynStateSet维护处于同步状态的副本组集合集合里的节点都有完整的数据主节点宕机后从集合中选择新的主节点。Replication用于不同副本之间的数据复制、数据校验、截断对齐等事项。下面是 5.0 HA 的架构全景图新的高可用架构具备多个优势。在消息存储引入了朝代与开始位点的数据基于这两个数据完成数据校验、截断对齐在构建副本组的过程中简化数据一致性逻辑。基于 DledgerController无需引入 zk、etcd 等外部分布式一致性系统并且 DledgerController 还可与 NameServer 合并部署简化运维、节约机器资源。RocketMQ 对 DledgerController 是弱依赖即便 Dledger 整体不可用也只会影响选主不影响正常的消息收发流程。可定制用户可以根据业务对数据可靠性、性能、成本综合选择比如副本数可以是 2、3、4副本直接可以是同步复制或异步复制。如 2-2 模式表示 2 副本并且两个副本的数据同步复制2-3 模式表示 3 副本只要有 2 个副本写成功即认为消息持久化成功。用户还可以将其中的副本部署在异地机房异步复制实现容灾。如下图云原生存储-对象存储上文讲到的存储系统都是 RMQ 面向本地文件系统的实现在云原生时代将 RocketMQ 部署到云环境可以进一步利用云原生基础设施比如云存储来进一步增强 RocketMQ 的存储能力。RocketMQ 5.0 提供了多级存储的特性是内核级的存储扩展面向对象存储扩展了对应的 Commitlog、ConsumeQueue 与 IndexFile。且采用了插件化的设计多级存储可以有多种实现在阿里云上基于 OSS 对象服务实现在 AWS 上则可以面向 S3 的接口来实现。通过引入了云原生的存储RocketMQ 释放了很多红利。第一个是无限存储能力消息存储空间不受本地磁盘空间的限制原来是保存几天现在可以几个月、甚至存一年。另外对象存储也是业界成本最低的存储系统特别适合冷数据存储。第二个是 Topic 的 TTL原来多个 Topic 的生命周期是和 Commitlog 绑定统一的保留时间。现在每个 Topic 都会使用独立的对象存储 Commitlog 文件可以有独立的 TTL。第三个是存储系统进一步的存算分离能把存储吞吐量的弹性和存储空间的弹性分离。第四个是冷热数据隔离分离了冷热数据的读链路能大幅度提升冷读性能不会影响在线业务。总结RocketMQ 整体架构RocketMQ 负载均衡AP 优先、分合模式、横向扩展、负载粒度RocketMQ 存储设计存储引擎、高可用、云存储。本文已同步收录至「RocketMQ 中文社区」 面向 RocketMQ 中文开发者的一站式学习社区