RocketMQ 5.0 架构概览
2023-08-18 11:23:10 
阿炯
Why RocketMQ 5.0
Apache RocketMQ 自诞生以来，因其架构简单、业务功能丰富、具备极强可扩展性等特点被众多企业开发者以及云厂商广泛采用。历经十余年的大规模场景打磨，RocketMQ 已经成为业内共识的金融级可靠业务消息首选方案，被广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景。尽管 RocketMQ 在开源社区已经走过了十多个年头，但在企业架构云原生浪潮下，我们一直在思考 RocketMQ 的架构演进以及对上层集成的价值提升。
RocketMQ 5.0 的演进目标有三个：
1.消息基础架构的云原生化演进：充分结合云原生大潮下的基础设施和生态技术，提高资源利用和弹性能力。 2.集成效率的痛点升级优化：从API、SDK多方面重构设计，为开发者提供更加简单易用、轻量易集成的方案； 3.事件、流集成场景拓宽：将以当前业务集成的能力为基础进一步聚焦消息领域的后处理场景，支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并将全面拥抱 Serverless 和 EDA。
New in RocketMQ 5.0
基础架构云原生化升级
RocketMQ 自诞生以来就一直坚持简洁架构，比如元数据采用最终一致性设计，只引入了几百行代码的无状态 NameSrv 组件。相比其他产品依赖 ZK 进行元数据的管理维护，RocketMQ 的优势是显而易见的。
随着企业上云的进一步普及以及云原生技术趋势的演进，集成的网络环境更加复杂，企业开发者对效率也有了更高的要求，我们看到当前的架构还存在一定的不足。当前的架构下存储和计算资源的灵活匹配相对困难，特别是在如今企业上云逐步普及的情况下，云厂商的计算资源和存储资源之间解耦灵活的弹性策略可以更好的实现降本提效。
RocketMQ 5.0 引入了全新的弹性无状态代理模式，将当前的Broker职责进行拆分，对于客户端协议适配、权限管理、消费管理等计算逻辑进行抽离，独立无状态的代理角色提供服务，Broker则继续专注于存储能力的持续优化。这套模式可以更好地实现在云环境的资源弹性调度。 值得注意的是RocketMQ 5.0的全新模式是和4.0的极简架构模式相容相通的，5.0的代理架构完全可以以Local模式运行，实现与4.0架构完全一致的效果。开发者可以根据自身的业务场景自由选择架构部署。
轻量API和多语言SDK
除了架构改变，RocketMQ 5.0 重新思考了面向开发者的集成界面，即API和SDK的设计。RocketMQ 4.x SDK 是比较重量级的富客户端模式，提供了诸如顺序消费、广播消费、消费者负载均衡、消息缓存、消息重试、位点管理、推拉结合、流控、诊断、故障转移、异常节点隔离等一系列能力。这些复杂能力虽然可以帮助业务集成解决实际问题，但其自身的演进和迭代却存在比较大的负担，客户端的升级和多语言普及难度较大。从API的简洁性和友好性方面，RocketMQ 5.0正在做轻量化设计。
RocketMQ 5.0 推出了基于 gRPC 全新的多语言 SDK，这套 SDK 有几个重要特点：采用全新极简的 API，拥有不可变 API 的设计，完善的错误处理，各语言 SDK API 在本地语言层面对齐，新的API 化繁为简，更易被使用和集成。 采用云原生的 RPC 标准框架 gRPC，标准的传输层框架，更易被拦截，特别适合被 Service Mesh 集成从而赋予其更多的传输层基础能力。 客户端轻量化，以典型的「SimpleConsumer」为代表，采用全新的面向消息的无状态消费模型，整个 SDK 从代码到运行时都极为轻量。轻量化是一种非常重要能力，如果各个中间件都采取富客户端的形式，这些中间件当被一起植入到 Sidecar 中时，也会是一个非常庞大的 Sidecar，应用框架集成的复杂度非常高。
除了API/SDK的设计优化，RocketMQ 5.0 还引入了一种无状态消费模型，即 Pop 机制，创新性地在队列模型之上支持了无状态的消息模型，在一个主体上同时支持两种消费模型，体现了消息和流的「二象性」。面向流场景采用高性能的队列模型进行消费；面向消息的场景，采用无状态的消息模型进行消费。业务可以只关心消息本身，通过「SimpleConsumer」提供单条消息级别的消费、重试、修改不可见时间、以及删除等 API 能力。
事件、流处理场景集成
除了上述基础架构以及API集成的变化，RocketMQ 5.0基于业务消息的基础优势，RocketMQ 5.0进一步拓宽在消息后处理计算的场景挖掘。支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并将全面拥抱 Serverless 和 EDA。
伴随企业云原生化进程的加速，计算力的构成越来越多样化，通过事件驱动架构来开发云原生应用是一件非常顺理成章的事情。RocketMQ 5.0 正是基于此技术趋势大潮开放了兼容标准CloudEvents协议的RocketMQ-EventBridge组件。EventBridge提供丰富的跨产品、跨平台连接能力，能够促进云厂商、企业应用、SaaS 服务三者相互集成。EventBridge的目标是以统一开放的标准链接社区活跃的生态，同时能与各个云厂商的「Hub」类产品进行集成，来达到开源和云的数据互通，助力企业客户轻松上云和下云。
在消息流式处理场景，RocketMQ 5.0将当前的队列下沉为物理队列，上层重新抽象了逻辑队列。一个逻辑队列可以包含多个物理队列，各个物理队列都作为逻辑队列的一个片段，以此拼接出真正的流式队列。也因此可以做到更轻量，秒级扩缩，在物理节点发生变化时不涉及到存量数据复制迁移；实现数据存储的灵活调度，配合 TTL 实现无限存储能力。同时，应对流的高吞吐场景，5.0优化里存储批量处理的读写性能。
在计算框架方面，RocketMQ 5.0 引入了一套轻量级流式处理框架RSteams。RStreams 依赖少、部署简单，可任意横向扩展，利用 RocketMQ 资源即可完成轻量级的数据处理和计算。除此以外，为了方便开发者让基于 RocketMQ 的流式计算更容易，5.0 还支持了一套轻量SQL查询引擎 RSQLDB，为开发者提供基于 SQL 的开发体验。RSQLDB 首创性地兼容了 Flink/Blink SQL 标准以及 UDF/UDAF/UDTF，使得两个开源产品的生态可以更好地融合，开发者可以将 Flink/Blink 已有 SQL 计算任务迁移到 RocketMQ ，在 RocketMQ 内部完成轻量级的计算处理，在算力受限或者更大规模的场景下，同样可以将 RocketMQ 的实时计算任务迁移到 Flink，利用 Flink 的大数据计算能力满足业务诉求。
How to upgrade to 5.0
RocketMQ 5.0在完成上述架构升级、API重构和新功能场景时，统一遵循了向下兼容的原则。RocketMQ 4.x版本可以无缝升级到5.0版本同时保持对历史版本SDK的兼容。选择5.0版本无需担心不兼容历史版本的应用。我们建议升级服务端版本后，尽快替换使用新版本的SDK以获得更好的接入体验和新功能。
RocketMQ 5.0 架构解析：如何基于云原生架构支撑多元化场景
作者：隆基
本节将从技术角度了解 RocketMQ 的云原生架构，了解其如何基于一套统一的架构支撑多元化的场景。主要包含三部分内容。首先介绍 RocketMQ 5.0 的核心概念和架构概览；然后从集群角度出发，从宏观视角学习 RocketMQ 的管控链路、数据链路、客户端和服务端如何交互；最后介绍消息队列最重要的模块存储系统，了解 RocketMQ 如何实现数据的存储和数据的高可用，以及如何利用云原生存储进一步提升竞争力。
1、概览
在介绍 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。
2、架构概览
下图是一张 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，其组件全部实现无状态化。
3、服务发现
下面详细看一下 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 还可以进行服务发现的读写权限控制，对缩容的节点禁写开读，待未读消息全消费后，再实现无损平滑下线。
4、负载均衡
通过上文的介绍了解了 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 的队列数与消费者实例数完全解耦，可以独立扩缩容。
5、存储系统
前面通过架构概览和服务发现机制，已经对 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 文件则用于完成重启后的文件恢复，保障数据完整性。
6、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 元数据继续进行消息收发。
7、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 的架构全景图，新的高可用架构具备多个优势。
1.在消息存储引入了朝代与开始位点的数据，基于这两个数据完成数据校验、截断对齐，在构建副本组的过程中简化数据一致性逻辑。
2.基于 DledgerController，无需引入 zk、etcd 等外部分布式一致性系统，并且 DledgerController 还可与 NameServer 合并部署，简化运维、节约机器资源。
3.RocketMQ 对 DledgerController 是弱依赖，即便 Dledger 整体不可用，也只会影响选主，不影响正常的消息收发流程。
4.可定制，用户可以根据业务对数据可靠性、性能、成本综合选择，比如副本数可以是 2、3、4，副本直接可以是同步复制或异步复制。如 2-2 模式表示 2 副本并且两个副本的数据同步复制；2-3 模式表示 3 副本，只要有 2 个副本写成功即认为消息持久化成功。用户还可以将其中的副本部署在异地机房，异步复制实现容灾。如下图：
8、云原生存储-对象存储
上文讲到的存储系统都是 RMQ 面向本地文件系统的实现，在云原生时代，将 RocketMQ 部署到云环境可以进一步利用云原生基础设施，比如云存储来进一步增强 RocketMQ 的存储能力。RocketMQ 5.0 提供了多级存储的特性，是内核级的存储扩展，面向对象存储扩展了对应的 Commitlog、ConsumeQueue 与 IndexFile。且采用了插件化的设计，多级存储可以有多种实现，在阿里云上基于 OSS 对象服务实现，在 AWS 上则可以面向 S3 的接口来实现。
通过引入了云原生的存储，RocketMQ 释放了很多红利。
第一个是无限存储能力，消息存储空间不受本地磁盘空间的限制，原来是保存几天，现在可以几个月、甚至存一年。另外对象存储也是业界成本最低的存储系统，特别适合冷数据存储。
第二个是 Topic 的 TTL，原来多个 Topic 的生命周期是和 Commitlog 绑定，统一的保留时间。现在每个 Topic 都会使用独立的对象存储 Commitlog 文件，可以有独立的 TTL。
第三个是存储系统进一步的存算分离，能把存储吞吐量的弹性和存储空间的弹性分离。
第四个是冷热数据隔离，分离了冷热数据的读链路，能大幅度提升冷读性能，不会影响在线业务。
9、总结
RocketMQ 整体架构：
RocketMQ 负载均衡：AP 优先、分合模式、横向扩展、负载粒度；
RocketMQ 存储设计：存储引擎、高可用、云存储。
Apache RocketMQ 自诞生以来，因其架构简单、业务功能丰富、具备极强可扩展性等特点被众多企业开发者以及云厂商广泛采用。历经十余年的大规模场景打磨，RocketMQ 已经成为业内共识的金融级可靠业务消息首选方案，被广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景。尽管 RocketMQ 在开源社区已经走过了十多个年头，但在企业架构云原生浪潮下，我们一直在思考 RocketMQ 的架构演进以及对上层集成的价值提升。
RocketMQ 5.0 的演进目标有三个：
1.消息基础架构的云原生化演进：充分结合云原生大潮下的基础设施和生态技术，提高资源利用和弹性能力。 2.集成效率的痛点升级优化：从API、SDK多方面重构设计，为开发者提供更加简单易用、轻量易集成的方案； 3.事件、流集成场景拓宽：将以当前业务集成的能力为基础进一步聚焦消息领域的后处理场景，支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并将全面拥抱 Serverless 和 EDA。
New in RocketMQ 5.0
基础架构云原生化升级
RocketMQ 自诞生以来就一直坚持简洁架构，比如元数据采用最终一致性设计，只引入了几百行代码的无状态 NameSrv 组件。相比其他产品依赖 ZK 进行元数据的管理维护，RocketMQ 的优势是显而易见的。
随着企业上云的进一步普及以及云原生技术趋势的演进，集成的网络环境更加复杂，企业开发者对效率也有了更高的要求，我们看到当前的架构还存在一定的不足。当前的架构下存储和计算资源的灵活匹配相对困难，特别是在如今企业上云逐步普及的情况下，云厂商的计算资源和存储资源之间解耦灵活的弹性策略可以更好的实现降本提效。
RocketMQ 5.0 引入了全新的弹性无状态代理模式，将当前的Broker职责进行拆分，对于客户端协议适配、权限管理、消费管理等计算逻辑进行抽离，独立无状态的代理角色提供服务，Broker则继续专注于存储能力的持续优化。这套模式可以更好地实现在云环境的资源弹性调度。 值得注意的是RocketMQ 5.0的全新模式是和4.0的极简架构模式相容相通的，5.0的代理架构完全可以以Local模式运行，实现与4.0架构完全一致的效果。开发者可以根据自身的业务场景自由选择架构部署。
轻量API和多语言SDK
除了架构改变，RocketMQ 5.0 重新思考了面向开发者的集成界面，即API和SDK的设计。RocketMQ 4.x SDK 是比较重量级的富客户端模式，提供了诸如顺序消费、广播消费、消费者负载均衡、消息缓存、消息重试、位点管理、推拉结合、流控、诊断、故障转移、异常节点隔离等一系列能力。这些复杂能力虽然可以帮助业务集成解决实际问题，但其自身的演进和迭代却存在比较大的负担，客户端的升级和多语言普及难度较大。从API的简洁性和友好性方面，RocketMQ 5.0正在做轻量化设计。
RocketMQ 5.0 推出了基于 gRPC 全新的多语言 SDK，这套 SDK 有几个重要特点：采用全新极简的 API，拥有不可变 API 的设计，完善的错误处理，各语言 SDK API 在本地语言层面对齐，新的API 化繁为简，更易被使用和集成。 采用云原生的 RPC 标准框架 gRPC，标准的传输层框架，更易被拦截，特别适合被 Service Mesh 集成从而赋予其更多的传输层基础能力。 客户端轻量化，以典型的「SimpleConsumer」为代表，采用全新的面向消息的无状态消费模型，整个 SDK 从代码到运行时都极为轻量。轻量化是一种非常重要能力，如果各个中间件都采取富客户端的形式，这些中间件当被一起植入到 Sidecar 中时，也会是一个非常庞大的 Sidecar，应用框架集成的复杂度非常高。
除了API/SDK的设计优化，RocketMQ 5.0 还引入了一种无状态消费模型，即 Pop 机制，创新性地在队列模型之上支持了无状态的消息模型，在一个主体上同时支持两种消费模型，体现了消息和流的「二象性」。面向流场景采用高性能的队列模型进行消费；面向消息的场景，采用无状态的消息模型进行消费。业务可以只关心消息本身，通过「SimpleConsumer」提供单条消息级别的消费、重试、修改不可见时间、以及删除等 API 能力。
事件、流处理场景集成
除了上述基础架构以及API集成的变化，RocketMQ 5.0基于业务消息的基础优势，RocketMQ 5.0进一步拓宽在消息后处理计算的场景挖掘。支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并将全面拥抱 Serverless 和 EDA。
伴随企业云原生化进程的加速，计算力的构成越来越多样化，通过事件驱动架构来开发云原生应用是一件非常顺理成章的事情。RocketMQ 5.0 正是基于此技术趋势大潮开放了兼容标准CloudEvents协议的RocketMQ-EventBridge组件。EventBridge提供丰富的跨产品、跨平台连接能力，能够促进云厂商、企业应用、SaaS 服务三者相互集成。EventBridge的目标是以统一开放的标准链接社区活跃的生态，同时能与各个云厂商的「Hub」类产品进行集成，来达到开源和云的数据互通，助力企业客户轻松上云和下云。
在消息流式处理场景，RocketMQ 5.0将当前的队列下沉为物理队列，上层重新抽象了逻辑队列。一个逻辑队列可以包含多个物理队列，各个物理队列都作为逻辑队列的一个片段，以此拼接出真正的流式队列。也因此可以做到更轻量，秒级扩缩，在物理节点发生变化时不涉及到存量数据复制迁移；实现数据存储的灵活调度，配合 TTL 实现无限存储能力。同时，应对流的高吞吐场景，5.0优化里存储批量处理的读写性能。
在计算框架方面，RocketMQ 5.0 引入了一套轻量级流式处理框架RSteams。RStreams 依赖少、部署简单，可任意横向扩展，利用 RocketMQ 资源即可完成轻量级的数据处理和计算。除此以外，为了方便开发者让基于 RocketMQ 的流式计算更容易，5.0 还支持了一套轻量SQL查询引擎 RSQLDB，为开发者提供基于 SQL 的开发体验。RSQLDB 首创性地兼容了 Flink/Blink SQL 标准以及 UDF/UDAF/UDTF，使得两个开源产品的生态可以更好地融合，开发者可以将 Flink/Blink 已有 SQL 计算任务迁移到 RocketMQ ，在 RocketMQ 内部完成轻量级的计算处理，在算力受限或者更大规模的场景下，同样可以将 RocketMQ 的实时计算任务迁移到 Flink，利用 Flink 的大数据计算能力满足业务诉求。
How to upgrade to 5.0
RocketMQ 5.0在完成上述架构升级、API重构和新功能场景时，统一遵循了向下兼容的原则。RocketMQ 4.x版本可以无缝升级到5.0版本同时保持对历史版本SDK的兼容。选择5.0版本无需担心不兼容历史版本的应用。我们建议升级服务端版本后，尽快替换使用新版本的SDK以获得更好的接入体验和新功能。
RocketMQ 5.0 架构解析：如何基于云原生架构支撑多元化场景
作者：隆基
本节将从技术角度了解 RocketMQ 的云原生架构，了解其如何基于一套统一的架构支撑多元化的场景。主要包含三部分内容。首先介绍 RocketMQ 5.0 的核心概念和架构概览；然后从集群角度出发，从宏观视角学习 RocketMQ 的管控链路、数据链路、客户端和服务端如何交互；最后介绍消息队列最重要的模块存储系统，了解 RocketMQ 如何实现数据的存储和数据的高可用，以及如何利用云原生存储进一步提升竞争力。
1、概览
在介绍 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。
2、架构概览
下图是一张 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，其组件全部实现无状态化。
3、服务发现
下面详细看一下 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 还可以进行服务发现的读写权限控制，对缩容的节点禁写开读，待未读消息全消费后，再实现无损平滑下线。
4、负载均衡
通过上文的介绍了解了 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 的队列数与消费者实例数完全解耦，可以独立扩缩容。
5、存储系统
前面通过架构概览和服务发现机制，已经对 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 文件则用于完成重启后的文件恢复，保障数据完整性。
6、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 元数据继续进行消息收发。
7、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 的架构全景图，新的高可用架构具备多个优势。
1.在消息存储引入了朝代与开始位点的数据，基于这两个数据完成数据校验、截断对齐，在构建副本组的过程中简化数据一致性逻辑。
2.基于 DledgerController，无需引入 zk、etcd 等外部分布式一致性系统，并且 DledgerController 还可与 NameServer 合并部署，简化运维、节约机器资源。
3.RocketMQ 对 DledgerController 是弱依赖，即便 Dledger 整体不可用，也只会影响选主，不影响正常的消息收发流程。
4.可定制，用户可以根据业务对数据可靠性、性能、成本综合选择，比如副本数可以是 2、3、4，副本直接可以是同步复制或异步复制。如 2-2 模式表示 2 副本并且两个副本的数据同步复制；2-3 模式表示 3 副本，只要有 2 个副本写成功即认为消息持久化成功。用户还可以将其中的副本部署在异地机房，异步复制实现容灾。如下图：
8、云原生存储-对象存储
上文讲到的存储系统都是 RMQ 面向本地文件系统的实现，在云原生时代，将 RocketMQ 部署到云环境可以进一步利用云原生基础设施，比如云存储来进一步增强 RocketMQ 的存储能力。RocketMQ 5.0 提供了多级存储的特性，是内核级的存储扩展，面向对象存储扩展了对应的 Commitlog、ConsumeQueue 与 IndexFile。且采用了插件化的设计，多级存储可以有多种实现，在阿里云上基于 OSS 对象服务实现，在 AWS 上则可以面向 S3 的接口来实现。
通过引入了云原生的存储，RocketMQ 释放了很多红利。
第一个是无限存储能力，消息存储空间不受本地磁盘空间的限制，原来是保存几天，现在可以几个月、甚至存一年。另外对象存储也是业界成本最低的存储系统，特别适合冷数据存储。
第二个是 Topic 的 TTL，原来多个 Topic 的生命周期是和 Commitlog 绑定，统一的保留时间。现在每个 Topic 都会使用独立的对象存储 Commitlog 文件，可以有独立的 TTL。
第三个是存储系统进一步的存算分离，能把存储吞吐量的弹性和存储空间的弹性分离。
第四个是冷热数据隔离，分离了冷热数据的读链路，能大幅度提升冷读性能，不会影响在线业务。
9、总结
RocketMQ 整体架构：
RocketMQ 负载均衡：AP 优先、分合模式、横向扩展、负载粒度；
RocketMQ 存储设计：存储引擎、高可用、云存储。