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

news2025/1/15 16:50:22

作者:隆基

本文将从技术角度了解 RocketMQ 的云原生架构,了解 RocketMQ 如何基于一套统一的架构支撑多元化的场景。

文章主要包含三部分内容。首先介绍 RocketMQ 5.0 的核心概念和架构概览;然后从集群角度出发,从宏观视角学习 RocketMQ 的管控链路、数据链路、客户端和服务端如何交互;最后介绍消息队列最重要的模块存储系统,了解 RocketMQ 如何实现数据的存储和数据的高可用,以及如何利用云原生存储进一步提升竞争力。

01 概览

在介绍 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 Group+Topic +过滤表达式的三元组,符合订阅关系的消息会被对应的消费者集群消费。

接下来就从技术实现角度进一步深入了解 RocketMQ。

02 架构概览

下图是一张 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,其组件全部实现无状态化。

03 服务发现

下面详细看一下 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 还可以进行服务发现的读写权限控制,对缩容的节点禁写开读,待未读消息全消费后,再实现无损平滑下线。

04 负载均衡

通过上文的介绍了解了 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 的队列数与消费者实例数完全解耦,可以独立扩缩容。

05 存储系统

前面通过架构概览和服务发现机制,已经对 RocketMQ 有比较全局性的了解,接下来将深入 RocketMQ 的存储系统。存储系统对 RocketMQ 的性能、成本、可用性有决定性作用。RocketMQ 的存储核心由 commitlog、ConsumeQueue 与 index 文件组成。

在这里插入图片描述

消息存储首先写到 commitlog,刷盘并复制到 slave 节点完成持久化,commitlog 是 RocketMQ 存储的 source of true,可以通过它构建完整的消息索引。

相比于 Kafka,RocketMQ 将所有 topic 的数据都写到 commitlog 文件,最大化顺序 IO,使得 RocketMQ 单机可支撑万级的 topic。

写完 commitlog 之后,RocketMQ 会异步分发出多个索引,首先是 ConsumeQueue 索引,与 MessageQueue 对应,基于索引可以实现消息的精准定位,可以按照 topic、队列 ID 与位点定位到消息,消息回溯功能也是基于该能力实现的。

另外一个很重要的索引是哈希索引,它是消息可观测的基础。通过持久化的 hash 表来实现消息业务主键的查询能力,消息轨迹主要基于该能力实现。

除了消息本身的存储之外,broker 还承载了消息元数据的存储以及 topic 的文件,包括 broker 会对哪些 topic 提供服务,还维护了每个 topic 的队列数、读写权限、顺序性等属性,subscription、consumer offset 文件维护了 topic 的订阅关系以及每个消费者的消费进度,abort、checkpoint 文件则用于完成重启后的文件恢复,保障数据完整性。

06 Topic 高可用

前面站在单机的视角,从功能的层面学习 RocketMQ 的存储引擎,包括 commitlog 和索引。现在重新跳出来再从集群视角看 RocketMQ 的高可用。

在这里插入图片描述

RocketMQ 的高可用指当 RocketMQ 集群出现 NameServer、Broker 局部不可用时,指定的 topic 依然可读可写。

RocketMQ 可以应对三类故障场景。

场景 1:某对 Broker 的单机不可用

比如,当 Broker2 主节点宕机,备节点可用,TopicA 依然可读可写,其中分片 1 可读可写,分片 2 可读不可写,TopicA 在分片 2 的未读消息依然可以消费。总结来说,即只要 Broker 集群里任意一组 Broker 存活一个节点,则 Topic 的读写可用性不受影响。如果某组 Broker 主备全部宕机,则 Topic 新数据的读写也不受影响,未读消息会延迟,待任意主备启动才能继续消费。

在这里插入图片描述

场景 2:NameServer 集群部分不可用

由于 NameServer 是 shared-nothing 架构,每个节点都为无状态,并且为 AP 模式,无需依赖多数派算法,因此只要有一台 NameServer 存活,则整个服务发现机制都正常,Topic 的读写可用性不受影响。

在这里插入图片描述

场景 3:NameServer 全部不可用

在这里插入图片描述

由于 RocketMQ 的 SDK 对服务发现元数据有缓存,只要 SDK 不重启,依然可以按照当下的 topic 元数据继续进行消息收发。

07 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 个副本写成功即认为消息持久化成功。用户还可以将其中的副本部署在异地机房,异步复制实现容灾。如下图:

在这里插入图片描述

08 云原生存储-对象存储

上文讲到的存储系统都是 RMQ 面向本地文件系统的实现,在云原生时代,将 RocketMQ 部署到云环境可以进一步利用云原生基础设施,比如云存储来进一步增强 RocketMQ 的存储能力。RocketMQ 5.0 提供了多级存储的特性,是内核级的存储扩展,面向对象存储扩展了对应的 Commitlog、ConsumeQueue 与 IndexFile。且采用了插件化的设计,多级存储可以有多种实现,在阿里云上基于 OSS 对象服务实现,在 AWS 上则可以面向 S3 的接口来实现。

通过引入了云原生的存储,RocketMQ 释放了很多红利。

在这里插入图片描述

第一个是无限存储能力,消息存储空间不受本地磁盘空间的限制,原来是保存几天,现在可以几个月、甚至存一年。另外对象存储也是业界成本最低的存储系统,特别适合冷数据存储。

第二个是 Topic 的 TTL,原来多个 Topic 的生命周期是和 Commitlog 绑定,统一的保留时间。现在每个 Topic 都会使用独立的对象存储 Commitlog 文件,可以有独立的 TTL。

第三个是存储系统进一步的存算分离,能把存储吞吐量的弹性和存储空间的弹性分离。

第四个是冷热数据隔离,分离了冷热数据的读链路,能大幅度提升冷读性能,不会影响在线业务。

09 总结

  • RocketMQ 整体架构:

在这里插入图片描述

  • RocketMQ 负载均衡:AP 优先、分合模式、横向扩展、负载粒度;
  • RocketMQ 存储设计:存储引擎、高可用、云存储。

【活动】带你玩转 RocketMQ,角逐「RocketMQ 首席评测官」

为了更好地长期得到开发者实际使用中的反馈和建议,联合阿里云开发者社区推出了“寻找 RocketMQ 首席评测官”活动,寻找在消息领域有技术实践经验、愿意深度评测产品并提出宝贵建议的开发者。期待您的加入,帮助 Apache RocketMQ 以及阿里云消息产品持续提升竞争力。

活动入口:

点击此处立即参与活动:(或前往文末阅读原文进入)

https://developer.aliyun.com/topic/rocketmq?utm_content=g_1000377381&spm=1000.2115.3001.5954

可以直接进行产品评测:

https://developer.aliyun.com/mission/review/rocketmqtest?spm=a2c6h.28281744.J_2889796290.5.c66c5bacLDNt46

点击此处,立即参与活动

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/896935.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

mysql in mac学习记录

鉴于有一段时间没有访问mysql了,最近打算在mac 系统上下载mysql 练习一下sql的使用,于是 First, the mysql download https://dev.mysql.com/downloads/mysql/ Second, Mysql install steps Install the software by normally install one software …

ARM M33架构入门

概述 Arm Cortex-M33核心处理器专为需要高效安全或数字信号控制的物联网和嵌入式应用而设计。该处理器具有许多可选功能,包括数字信号处理扩展 (DSP)、用于硬件强制隔离的TrustZone 安全性、内存保护单元 (MPU)和浮点单元 (FPU)。 Cortex-M33 的性能比 Cortex-M…

基于Googlenet深度学习网络的矿物质种类识别matlab仿真

目录 1.算法运行效果图预览 2.算法运行软件版本 3.部分核心程序 4.算法理论概述 5.算法完整程序工程 1.算法运行效果图预览 2.算法运行软件版本 matlab2022a 3.部分核心程序 ............................................................................ Number_of_…

毫米波雷达成像论文阅读笔记: IEEE TPAMI 2023 | CoIR: Compressive Implicit Radar

原始笔记链接:https://mp.weixin.qq.com/s?__bizMzg4MjgxMjgyMg&mid2247486680&idx1&snedf41d4f95395d7294bc958ea68d3a68&chksmcf51be21f826373790bc6d79bcea6eb2cb3d09bb1860bba0af0fd5e60c448ca006976503e460#rd ↑ \uparrow ↑点击上述链接即…

stm32控制蜂鸣器源代码(附带proteus线路图)

说明: 1 PB0输出0时,蜂鸣器发生; 2 蜂鸣器电阻值如果太大会导致电流太小,发不出声音; 3蜂鸣器额定电压需要设置得低一点,可以是2V,但不能高于3V,这更右上角的电阻值有关系&#x…

cdh6.3.2 Flink On Yarn taskmanager任务分配倾斜问题的解决办法

业务场景: Flink On Yarn任务启动 组件版本: CDH:6.3.2 Flink:1.13.2 Hadoop:3.0.0 问题描述: 在使用FLink on Yarn调度过程中,发现taskmanager总是分配在集中的几个节点上,集群…

vscode ssh 远程 gdb 调试

一、点运行与调试,生成launch.json 文件 二、点添加配置,选择GDB 三、修改启动程序路径

java并发:synchronized锁详解

背景: 在java多线程当中,我们总有遇到过多个线程操作一个共享数据时,而这个最后的代码执行结果并没有按照我们的预期一样得到正确的结果。此时我们就需要让代码执行在操作共享变量时,要等一个线程操作完毕时,另一个线程…

科技项目验收检测报告获取有哪些注意事项,作用都有哪些?

验收测试报告 软件从研发到结束是一个很长的周期,对于软件想要完成上市或者是交付到用户手中之前我们还需要进行一次全面检测,也就是科技项目验收测试,此测试有着严格的要求,需要第三方软件测评机构来完成,并出具科技…

Kotlin协程runBlocking并发launch,Semaphore同步1个launch任务运行

Kotlin协程runBlocking并发launch&#xff0c;Semaphore同步1个launch任务运行 <dependency><groupId>org.jetbrains.kotlinx</groupId><artifactId>kotlinx-coroutines-core</artifactId><version>1.7.3</version><type>pom&…

供应链安全和第三方风险管理:讨论如何应对供应链中的安全风险,以及评估和管理第三方合作伙伴可能带来的威胁

第一章&#xff1a;引言 在当今数字化时代&#xff0c;供应链的安全性越来越受到重视。企业的成功不仅仅依赖于产品和服务的质量&#xff0c;还取决于供应链中的安全性。然而&#xff0c;随着供应链越来越复杂&#xff0c;第三方合作伙伴的参与也带来了一系列安全风险。本文将…

同步jenkinsfile流水线(sync-job)

环境 变量&#xff1a;env&#xff08;环境变量&#xff1a;sit/dev/simulation/prod/all&#xff09;&#xff0c;job&#xff08;job-name/all&#xff09;目录&#xff1a;/var/lib/jenkins/jenkinsfile environment.json&#xff1a; [roottest-01 jenkinsfile]# cat env…

Spring Boot实现IP地址解析

一、本地解析 如果使用本地ip解析的话&#xff0c;我们将会借助ip2region&#xff0c;该项目维护了一份较为详细的本地ip地址对应表&#xff0c;如果为了离线环境的使用&#xff0c;需要导入该项目依赖&#xff0c;并指定版本&#xff0c;不同版本的方法可能存在差异。 <d…

管理类联考——逻辑——真题篇——按知识分类——汇总篇——三、综合推理

文章目录 题-综合推理-分类1-排序真题&#xff08;2016-54-55&#xff09;-难度最高*****-综合推理-分类1-排序-画表排除法真题&#xff08;2016-54&#xff09;真题&#xff08;2016-55&#xff09;真题&#xff08;2019-36&#xff09;-综合推理-分类1-排序真题&#xff08;2…

回归预测 | MATLAB实现BES-BP秃鹰搜索算法优化BP神经网络多输入单输出回归预测(多指标,多图)

回归预测 | MATLAB实现BES-BP秃鹰搜索算法优化BP神经网络多输入单输出回归预测&#xff08;多指标&#xff0c;多图&#xff09; 目录 回归预测 | MATLAB实现BES-BP秃鹰搜索算法优化BP神经网络多输入单输出回归预测&#xff08;多指标&#xff0c;多图&#xff09;效果一览基本…

如何避免爬虫IP被屏蔽

各位爬友们好&#xff0c;作为一名专业的爬虫代理提供者&#xff0c;我要和大家分享一些避免爬虫IP被屏蔽的实用技巧。你知道吗&#xff0c;当我们爬取数据的时候&#xff0c;很容易被目标网站识别出来并封禁我们的IP地址&#xff0c;导致无法继续爬取数据。这个问题困扰了很多…

Q/GDW 1597-2015《国家电网公司应用软件系统通用安全要求》

电力安全测试报告 电力行业检测标准 随着信息技术的快速发展和广泛应用&#xff0c;应用软件系统已成为企业信息化建设中不可或缺的重要组成部分。然而&#xff0c;应用软件系统的安全问题也随之而来&#xff0c;给企业和用户带来了潜在的风险和威胁。为了提高应用软件系统的…

【第七讲---视觉里程计1】

视觉里程计就是通过对图像进行特征提取与匹配得到两帧之间的位姿&#xff0c;并进行估计相机运动。 经典SLAM中以相机位姿-路标来描述SLAM过程 特征提取与匹配 路标是三维空间中固定不变的点&#xff0c;可以在特定位姿下观测到在视觉SLAM中&#xff0c;可利用图像特征点作为…

opencv光流估计

光流估计 光流是空间运动物体在观测成像平面上的像素运动的“瞬时速度”&#xff0c;根据各个像素点的速度矢量特征&#xff0c;可以对图像进行动态分析&#xff0c;例如目标跟踪。 返回&#xff1a; 亮度恒定&#xff1a;同一点随着时间的变化&#xff0c;其亮度不会发生改变…

STM32 GPIO复习

GPIO General Purpose Input Output&#xff0c;即通用输入输出端口&#xff0c;简称GPIO。 负责采集外部器件的信息或控制外部器件工作&#xff0c;即输入输出。 不同型号&#xff0c;IO口数量可能不一样&#xff0c;可通过选型手册快速查询。 能快速翻转&#xff0c;每次翻…