关于消息队列:从RabbitMQ平滑迁移到RocketMQ技术实战

作者：vivo 互联网中间件团队 - Liu Runyun

大量业务应用消息中间件进行零碎间的解耦、异步化、削峰填谷设计实现。公司外部后期基于 RabbitMQ 实现了一套高可用的消息中间件平台。随着业务的持续增长，音讯体量随之增大，对消息中间件平台提出了更高的要求，此外在运维过程中也遇到了高可用难以保障，性能个性有余等诸多问题。基于遇到的这些问题，决定引入 RocketMQ 进行替换。本文将介绍基于 RocketMQ 建设消息中间件平台并实现在线业务无感知的平滑迁徙。

一、背景阐明

vivo 互联网中间件团队于 2016 年开始基于开源 RabbitMQ 向业务提供高可用消息中间件平台服务。

为解决好业务流量快速增长的问题，咱们通过正当的业务集群拆分和动静调整，较好的交付了 业务对消息中间件平台的 平台能力需要。

然而随着业务长周期的迅猛发展，音讯体量也越来越大，在高并发、大流量场景下 RabbitMQ 的零碎架构设计存在着肯定的限度，次要有以下问题：

1.1 高可用能力有余

架构设计存在脑裂危险，并且默认脑裂后无奈主动复原，人工染指复原存在数据失落的危险。

为解决脑裂问题，能够抉择将网络异样后的解决调整为 pause_minority 模式，然而也带来了可能渺小的网络抖动也会导致集群故障无奈复原的问题。

1.2. 性能有余

业务音讯发送后通过 exchange 路由到对应的 queue 中，每一个 queue 由集群中的某个节点理论承载流量，高流量下集群中的某个节点可能会成为瓶颈。

queue 由某个节点承载流量后无奈疾速迁徙，强制迁徙到其它低负载节点可能会导致 queue 不可用，这也导致了向集群中增加节点并无奈疾速晋升集群的流量承载能力。

集群性能较低，经测试应用三台机器组成集群，可承载大略数万 tps 左右，并且因为 queue 是由集群中某个节点理论承载的，也无奈持续晋升某个 queue 的性能，这样就无奈撑持大流量业务。

音讯沉积到千万或更多后会导致集群性能降落，甚至海量沉积后如果生产申请 tps 特地高，可能会因为磁盘的性能损耗导致发送性能降落，并且在音讯沉积太多时复原工夫长甚至无奈复原。

1.3 性能个性有余

RabbitMQ 默认状况下生产异样会执行立刻从新投递，大量的异样音讯也可能导致业务无奈生产后续音讯。

性能个性上未反对事务音讯、程序音讯性能。

虽可自行实现音讯轨迹逻辑，然而会对集群产生十分大的性能损耗，在正式环境中理论无奈基于 RabbitMQ 原生的能力实现音讯轨迹性能。

二、消息中间件平台的我的项目指标

基于以上问题，中间件团队于 2020 年 Q4 开始进行了下一代消息中间件平台计划的调研，为保障下一代消息中间件平台合乎业务新的需要，咱们首先明确了消息中间件平台的建设指标，次要蕴含两局部：

• 业务需要
• 平台需要

2.1 业务需要剖析

高性能：可撑持极高的 tps，并且反对程度扩大，可疾速满足业务的流量增长需要，消息中间件不应成为业务申请链路性能晋升的瓶颈点。

高可用：极高的平台可用性(>99.99%)，极高的数据可靠性(>99.99999999%)。

丰盛的性能个性：反对集群、播送生产；反对事务音讯、程序音讯、延时音讯、死信音讯；反对音讯轨迹。

2.2 平台运维需要剖析

• 可运维：业务应用权限校验；业务生产生产流量限度；业务流量隔离与疾速迁徙能力。
• 可观测：丰盛的性能指标察看集群的运行状况。
• 可把握：可基于开源组件疾速进行二次开发，丰盛平台性能个性和进行相干问题修复。
• 云原生：后续可基于容器化提供云原生消息中间件，提供更高的弹性和可伸缩能力。
• 总结：须要建设高性能、高牢靠的下一代消息中间件，具备极高的数据可靠性，丰盛的性能个性，并且须要完满兼容以后的 RabbitMQ 平台，帮忙业务疾速迁徙到新消息中间件平台，缩小业务迁徙老本。

三、开源组件选型调研

基于以后 RabbitMQ 平台的问题和对下一代消息中间件平台的我的项目需要，咱们发展了针对以后较风行的两款消息中间件：RocketMQ、Pulsar 的调研。

调研过程中次要针对以下两方面进行比照：

3.1 高可用能力剖析比照

 3.1.1 高可用架构与负载平衡能力比照

 Pulsar 部署架构（起源：Pulsar 社区）

RocketMQ 部署架构（起源：RocketMQ 社区）

• Pulsar：

• 采纳计算与存储拆散架构设计，能够实现海量数据存储，并且反对冷热数据拆散存储。
• 基于 ZK 和 Manager 节点管制 Broker 的故障切换以实现高可用。
• Zookeeper 采纳分层分片存储设计，人造反对负载平衡。

• RocketMQ：

• 采纳存算一体架构设计，主从模式部署，master 节点异样不影响音讯读取，Topic 采纳分片设计。
• 须要二次开发反对主从切换实现高可用。
• 未实现 Broker 的主动负载平衡，能够将 top n 流量 Topic 散布到不同的 Broker 中实现简略的负载平衡。

 3.1.2 扩缩容与故障复原比照

• Pulsar

• Broker 与 BooKeeper 独立扩缩容，并且扩缩容后会实现主动负载平衡。
• Broker 节点无状态，故障后承载 Topic 会主动转移到其它 Broker 节点，实现故障秒级复原。
• BooKeeper 由主动复原服务进行 ledger 数据对齐，并复原到设置的 QW 份。
• 故障期间已 ack 音讯不会失落，未 ack 音讯须要客户端重发。

• RocketMQ

• Broker 扩缩容后须要人工染指实现 Topic 流量平衡，可开发主动负载平衡组件联合 Topic 的读写权限管制自动化实现扩缩容后的负载平衡。
• 基于主从切换实现高可用，因为客户端定期 30 秒从 NameSrv 更新路由，因而故障复原工夫在 30~60 秒，能够联合客户端降级策略让客户端被动剔除异样 Broker 节点，实现更快故障复原。
• 采纳同步复制异步刷盘部署架构，在极其状况下会造成大量音讯失落，采纳同步复制同步刷盘，已写入音讯不会失落。

 3.1.3 性能比照

• Pulsar

• 可撑持百万 Topic 数量，理论受到 ZK 存储元数据限度。
• 依据外部压测 1KB 音讯可撑持 TPS 达数十万。

• RocketMQ

• 逻辑上可撑持百万 Topic，理论在达到数万时 Broker 与 NameSrv 传输心跳包可能超时，倡议单集群不超过 5 万。
• 依据压测可撑持 1KB 音讯体 TPS 达 10 万 +。

3.2 性能个性比照

3.3  总结

从高可用架构剖析，Pulsar 基于 Bookeeper 组件实现了架构的计算与存储拆散，能够实现故障的疾速复原；RocketMQ 采纳了主从复制的架构，故障复原依赖主从切换。

从性能个性剖析，Pulsar 反对了丰盛的过期策略，反对了音讯去重，能够反对实时计算中音讯只生产一次的语义；RocketMQ 在事务音讯、音讯轨迹、生产模式等个性对在线业务有更好的反对。

从这两方面比照，最终抉择了RocketMQ 构建咱们下一代的消息中间件平台。

四、平滑迁徙建设

通过技术调研，确定了基于 RocketMQ 建设下一代消息中间件平台。

为了实现业务从 RabbitMQ 平滑迁徙到 RocketMQ，就 须要建设音讯网关实现音讯从 AMQP 协定转换到 RocketMQ；RabbitMQ 与 RocketMQ 的元数据语义与存储存在差别，须要实现元数据语义的映射与元数据的独立存储。

次要有以下四个事项须要实现：

4.1 音讯网关独立部署与嵌入式部署差别比照

4.2 元数据定义映射与保护

4.3 互不烦扰的高性能音讯推送

RabbitMQ 采纳推模式进行音讯生产，尽管 RocketMQ 也反对音讯推送生产，然而因为 AMQP 协定中通过 prefetch 参数限度了客户端缓存音讯数量以保障不会因缓存太多音讯导致客户端内存异样，因而在音讯网关实现音讯推送时也须要满足 AMQP 协定的语义。

同时每个音讯网关都须要数千甚至数万的 queue 的音讯推送，每个 queue 音讯生产速率存在差别，并且每个队列可能随时有音讯须要推送到客户端进行生产，要保障不同 queue 之间的推送互不烦扰且及时。

为了实现高效的、互不烦扰的音讯推送，有以下策略：

1. 每个 queue 采纳独立的线程，保障互不烦扰和时效性，毛病是无奈撑持海量 queue 的音讯推送。
2. 基于信号量、阻塞队列等，在感知到有可推送音讯和可生产服务端时按需进行音讯的推送，这样可应用大量的线程即可实现高效的音讯推送。

最终抉择了第 2 种计划，数据流转图如下图所示：

一个音讯生产过程：客户端在启动连贯到音讯网关后，在音讯网关中会构建 RocketMQ 推送生产客户端实例，并且注入自定义的 ConsumeMessageService 实例，同时应用一个信号量保留客户端容许推送的音讯数量。

当音讯从集群侧推送到音讯网关时，将音讯依照推送的批次封装为一个工作保留在 ConsumeMessageService 实例的 BlockingQueue 中，同时推送线程会轮询所有的 ConsumeMessageService 实例，如果发现本地缓存有待生产的音讯并且有可生产音讯的业务客户端，将工作提交到线程池中实现音讯的推送。

为了保障不会因为大量生产速率特地高的 queue 导致其它 queue 的音讯推送时效性升高，会限度每一个 ConsumeMessageService 只容许推送肯定数量的音讯即转到推送其它 queue 的音讯，以此即可保障所有 queue 的音讯推送的互不烦扰和时效性。

在客户端生产 ack/uack 后再次通过信号量告诉下一次推送，这样也保障了应用大量的线程资源即可实现海量音讯的推送需要。

4.4 生产启停与生产限流能力实现

基于音讯网关，能够在音讯推送逻辑中减少生产启停和生产限流逻辑。

生产启停能够帮忙业务疾速实现生产的暂停或是局部异样节点进行音讯生产。

生产限流能够帮忙业务管制音讯生产速率，防止对底层依赖产生太大压力。

4.5 平台架构

• 最终造成了以上的平台架构。新建设了一个 AMQP-proxy 音讯网关服务实现 AMQP 音讯转换到 RocketMQ，反对业务的音讯生产生产。
• 建设了 mq-meta 服务保护集群的元数据信息。
• 通过 mq-controller 管制集群的主从切换，实现集群的高可用，同时减少了集群监控，负载平衡模块保障集群的高可用。

五、平台建设停顿与迁徙收益

5.1 业务应用收益

 5.1.1 更高、更稳固的音讯发送性能

原生 RabbitMQ 集群业务压测性能

应用音讯网关后业务压测性能

 5.1.2 更丰盛的性能个性

• 对立的音讯过期工夫
• 生产异样音讯将依照梯度延时重投递
• 间接反对播送生产模式
• 全环境按需提供音讯轨迹性能
• 反对生产重置到以前的某个位点

 5.1.3 业务应用个性变动

• 音讯将 不再无限期保留 ，默认 保留 3~7 天（理论保留工夫依据集群配置决定）
• 生产异样将不再立刻重投递，将依照肯定的 梯度延时重投递，屡次异样后将变为死信音讯
• 间接反对 播送生产，留神播送生产模式生产无异样重投递，每个音讯每个节点只生产一次
• 业务生产生产性能可反对程度扩大
• 不反对 生产优先级 性能
• 默认 生产超时工夫 15 分钟，生产超时后音讯从新投递，生产超时工夫可按需调整
• 反对 生产启停（全局或限度局部节点生产）
• 反对 全局生产限流
• 限度音讯体大小，以后限度为 256KB，超过将间接返回失败，后续将进行流量治理，限度发送大音讯体业务流量

5.2 平台运维收益

业务从 RabbitMQ 迁徙到 RocketMQ 后，可撑持业务流量从万 TPS 级别晋升到十万 TPS 级别，可撑持业务容量从数亿晋升至百亿级别。耗用机器资源降落 50% 以上，运维难度和老本均大大降低，同时能够基于音讯网关实现更加丰盛的性能个性。

六、将来瞻望

将来，中间件团队打算在三个方面对消息中间件进行迭代演进：

1. 基于音讯网关能力丰盛现有平台性能个性，进行业务音讯治理。
2. 过来五年中间件团队基于开源 RabbitMQ 进行了 RabbitMQ 的高可用建设，发现间接让业务方应用基于开源组件的 SDK 接入会带来 SDK 降级艰难，与后端消息中间件类型绑定的问题，将来咱们打算基于 GPRC 和音讯网关，实现音讯队列引擎服务化，业务无需关怀底层具体应用的开源消息中间件选型。
3. 调研 RocketMQ5.0 计算与存储拆散构架，进行消息中间件架构的再降级。