共计 6277 个字符，预计需要花费 16 分钟才能阅读完成。
作者：隆基
本文将从技术角度理解 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
点击此处，立刻参加流动
