Apache RocketMQ 5.0 腾讯云落地实践

Apache?RocketMQ??发展历程回顾

RocketMQ?最早诞生于淘宝的在线电商交易场景，经过了历年双十一大促流量洪峰的打磨，2016年捐献给?Apache?社区，成为?Apache?社区的顶级项目，并在国内外电商，金融，互联网等各行各业的广大客户落地验证，得到广泛认可。

Apache?RocketMQ?社区在2022年10月正式对外发布了全新的5.0版本，腾讯云消息队列团队也和社区紧密合作，支持了5.0的商业化版本，现在将整个落地过程的经验教训做个总结，回馈社区。

什么是?RocketMQ?5.0？

一个新版本号？

一套新设计的API？

一系列新的特性实现？

一个存算分离的新架构？

一种新的商业化产品形态？

RocketMQ?面向云原生的新思考？

Apache?RocketMQ?社区过去一年对5.0新架构从不同的角度进行了分享介绍，导致很多用户对5.0新架构认识不一致，其实从以上不同角度理解都对，本文尝试从多个维度做一个较全面的解释和回顾，帮助用户全面理解?RocketMQ?5.0?架构演进背后的思考逻辑。

RocketMQ?5.0?的演进目标

• 基础架构适应云原生化

RocketMQ?运行依赖的环境过去十年发生了巨大的变化，从最早的物理机部署开始，到现在云计算已经深入人心，资源越来越“弹性伸缩,?按量付费,?高SLA”，计算资源容器化，存储资源都演进为标准的分布式存储，比如块存储、文件存储和对象存储越来越成熟和标准化，尤其是以S3?为代表的对象存储，对比其他存储有很大的成本优势，所以新架构的演进就是要充分利用新计算和存储资源的优势。

• 轻量API和完善多语言SDK支持

RocketMQ?4.x?以前的协议，基于十多年前设计的私有Remoting协议，导致开发非?Java?语言的?SDK?成本非常高，所以?5.0?基于?gRPC?设计的全新?API?和?Proxy?模式，可以极大的方便多语言?SDK?开发，丰富多语言生态。

• 消息、事件、流场景与生态拓展集成

社区还开源了?EventBridge,?Connector,?Stream,?MQTT?等周边项目，有助于完善和增强周边生态，拓展更多业务场景。

RocketMQ?5.0?的关键新特性

为了支持以上三个主要的演进目标，RocketMQ?5.0?版本引入了大量新的技术和特性，下面将一些关键特性逐个简要介绍，其中不少特性已经在腾讯云投入实际使用，并发挥了业务价值。

POP 消费模式

RocketMQ?5.0?之前版本只提供了Pull的消费模式(即使?PushConsumer?也是通过?Pull?和长轮训模拟的?Push?效果)，Pull?消费模式和?Kafka?消费模式类似，也是需要在客户端做负载均衡，计算客户端实例和队列的映射关系，然后再消费消息和维护队列的位点信息，通过新的?POP?消费模式，带来了以下明显的好处：

• 不需要在客户端计算分配逻辑，简化客户端逻辑

• 降低了客户端SDK开发的复杂度，便于快速支持多语言客户端

• 消费位点完全维护在Broker端，避免单个消费节点慢导致消费延迟

• 适配其他协议的Proxy模式更顺畅，方便支持多消费模型时做推拉转换

腾讯云在?RocketMQ?5.0?的产品形态中，支持5.0新协议和兼容其他消息协议的过程中，都采用了?POP?消费模式，方便支持了Proxy的完全无状态和负载均衡。

更详细的POP方案设计扩展阅读参考：

• [RIP?19]?Server?side?rebalance,??lightweight?consumer?client?support

• [RIP?51]?Pop?orderly?improvement

基于gRPC的新API设计

RocketMQ?社区过去几年在支持?RocketMQ?4.x?客户端的过程中，越来越意识到?Remoting?协议的不足，开发非Java?SDK的门槛和成本过高，导致各个公司推出了基于?HTTP?等其他协议多种兼容?Proxy?方案，这次新?API?相当于官方出了一个统一的可扩展?Proxy?方案，方便各公司在这个?Proxy?的基础上，合并兼容一些其他协议，统一和简化架构，最终形成一个以RocketMQ?Broker?为存储内核，兼容各种消息协议的无状态?Proxy?的存算分离统一架构。

腾讯云在落地新架构的过程中，因为?Proxy?要处理协议序列化和转换等?CPU?密集型计算，要注意对?CPU?占用的优化，我们也向社区提了多个优化代码，以下是我们对4C8G规格的参考压测数据：

Proxy?压测过程中典型火焰图占用分析如下：

更详细的关于新方案设计和扩展阅读详见：

• [RIP37]?New?and?Unified?APIs

• [RIP39]?Support?gRPC?protocol

• [RIP55]?Supportremoting?protocol?in?rocketmq?proxy?module

秒级定时消息

定时消息是在线消息场景经常用的一种消息类型，发送方发送消息以后，并不想让订阅方立即消费到消息，而是等一段时间以后，消息对订阅方可见，典型的业务场景是订单下单五分钟后检查订单状态，或交易成功后第二天固定时间生成积分或优惠券。

RocketMQ?5.0?之前的版本，只能利用重试消息固定间隔的机制，实现Level固定级别的定时消息，5.0?新版本中重新实现了定时消息，可以支持超大规模超?时间任意秒级粒度的定时消息。

更详细的关于秒级定时消息方案设计和扩展阅读参考：

• [RIP43]?Support?timing?messages?with?arbitrary?time?delay

分层存储

RocketMQ?4.x?只支持本地磁盘或云盘等块设备作为持久化存储介质，块设备存储虽然能带来低延迟和可靠性，但是其存储成本却是对象存储的5~10倍，而消息队列数据是典型的冷热分布的数据，根据作者在实际系统的统计，约85%热数据在10分钟内通过内存缓存读取，其次10%温数据可能会在1小时内读走，约有5%的冷数据只有长时间堆积或回溯消费的场景才会被读到。

RocketMQ?5.0?引入了分层存储技术，可以将冷数据搬迁到更廉价的存储中，比如对象存储，可以在不降低用户体验的前提下，极大的降低综合存储成本。实现思路如下图所示，通过写入时将消息异步复制到分层存储，读取时优先读取本地存储，不命中的话再读取远程存储，实现分层存储的目的。

腾讯云在落地分层存储的过程中，一级存储选择了腾讯云云盘CBS，二级存储选择了腾讯云对象存储COS，以下表格是我们在腾讯云上的一个性能测试报告，开启分层存储对在线业务几乎不会有影响，这也与代码预期行为一致（dispatch异步写对象存储、热数据读本地缓存），二级存储单分区消费可以支持7500msg/s，扩分区可以等比例扩容消费速度，可以满足线上需求标准。

更详细的实现方案详见RIP文档:

• [RIP57]?Tieredstorage?for?RocketMQ

• [RIP65]?TieredStorage?Optimization

基于KV的百万队列索引

RocketMQ?4.x?版本中，每个Topic实际都是由多个队列来存储消息的，队列的数据存在统一的Commitlog中，消息队列索引是通过文件队列来存储消息索引的，当队列少于1万时，可以稳定高效的提供读写服务，当队列数超过10万以后，队列索引会退化成严重的随机写，导致性能严重下降

RocketMQ?5.0?引入?RocksDB?存储队列索引，利用?RocksDB?的?LSM?索引结构特性，将大量文件队列索引的随机写转化为?SST?文件的顺序写，即使有上百万个消息队列，从整个架构看，底层云盘依然只有少量的顺序写文件，依然可以稳定的提供消息读写服务。

以下是在我们测试环境测得的数据，队列数量少的时候，两个方案的从TPS和耗时指标差别不大，但是队列数超过20万以后，基于RocksDB的索引方案性能和稳定性的优势明显。

更详细的实现方案介绍参考：

• [RIP66]?Support?KV(Rocksdb)?Storage

• 百万队列能力支持

原生批量消息支持

RocketMQ?4.x?的版本中的批量消息是一个“伪批量”消息实现，需要在发送方发送一个业务层面组织好的消息数组，RocketMQ?Broker?收到消息数组后，会再拆成多个消息，逐个处理消息的写入，旧方案虽然兼容性好，实现简单，但是只优化了网络开销，压缩和存储性能优化不明显。

RocketMQ?5.0?引入了新的?AutoBatch?特性，对批量消息做了全链路的优化，从发送端的自动攒批编程界面，到新的存储格式和索引结构，都做了全面的优化。

以下是?RocketMQ?社区咸鱼(guyinyou?·?GitHub)同学提供的几种场景的压测数据，对比普通消息吞吐量翻倍提升，对比?Kafka?同等节点规格和业务场景下可以达到几乎相同的吞吐，在分区增加的场景下，提供更优的发送延时抖动：

使用同样测试节点和?Kafka?作性能对比，部署架构都采用3节点2副本的测试场景下，同样?16?分区下可以达到几乎同样的吞吐量但更低的发送延时，并且随着分区数增加，RocketMQ的稳定性和发送延时有明显的优势。

更详细的设计文档和测试结果详见：

• [RIP26]?Improve?Batch?Message?Processing?Throughput

• 活动回顾丨RocketMQ?Meetup?开源开发者沙龙（含?PPT）

jRaft?Controller?实现

RocketMQ?4.x?主从复制提供了简单高效的消息高可靠方案，但是一直存在一个无法自动切换主从的功能缺失，DLedger模式虽然通过基于Raft的三副本解决了自动选主的问题，但是性能比较差，并且机器成本高。

RocketMQ?5.0?新增了一个?Controller?组件(此组件可以和Namesrv合并部署)，解决主从复制部署模式下自动切换的问题，但是社区默认的?Controller?组件是基于?DLedger?实现的，Raft?实现并不完善，腾讯云消息团队同学为社区提供了一个新的基于?SOFAJRaft?更成熟的?Raft?实现方案，可以实现更稳定可靠的主从切换。

不同副本和同步机制的性能对比如下图所示：

在腾讯云测试环境的混沌测试结果全部通过：

更多JRaft?Controller的详细设计文档参考：

• [RIP44]?Support?DLedger?Controller

• [RIP67]?jRaft-Controller?Implemention

• jRaft?Controller?故障测试报告

其他新特性索引

RocketMQ?社区针对大的特性变更，都会有详细RIP文档和评审流程，限于篇幅，本文只挑了几个关键新特性做了简要介绍，更多新特新可以参考社区全部?RIP?列表链接。

腾讯云?RocketMQ?的商业化历程

腾讯云消息队列团队过去几年基于?Apache?RocketMQ?社区走过了完整的商业化历程，在2023年9月正式推出了5.x?商业化版本，提供极致弹性和更低成本的RocketMQ?服务，满足不同场景对?RocketMQ?的差异化需求，并已经在金融、出行、教育、游戏等多个行业落地实践。

新存算分离架构升级

在腾讯云内部，我们也将部署架构做了调整，按照 RocketMQ?5.0?推荐的存算分离架构，简化RocketMQ?的运维，也可以为用户提供更好的升降配弹性体验。

下图是?RocketMQ?5.0?新的存算分离架构：

全新的?5.0?Serverless?产品形态

基于以上新的存算分离新架构，我们推出了新的?TDMQ?RocketMQ?5.0?Serverless?产品形态，通过全新的按量计费模式，并且专业版以上免费提供了弹性TPS的能力，可以更低成本来应对突发流量。

落地实践总结与展望

回顾?RocketMQ?过去十年的发展历程，可以看到?RocketMQ?社区的蓬勃发展和功能的快速迭代演进，并且在国内各大云厂商也有快速的落地支持，腾讯云也会持续的大力研发投入，给?RocketMQ?用户提供了更多更优的选择。

腾讯云在?RocketMQ?商业化过程中，也积极回馈?RocketMQ?社区，近一年腾讯云为?RocketMQ?社区贡献了?30+?缺陷修复和性能优化代码合并，并且贡献了一个?RIP?67，也希望未来和?RocketMQ?社区更紧密配合，为?Apache?RocketMQ?的繁荣发展做出贡献，为用户提供更优质的?RocketMQ?服务。