做网站多久能盈利,株洲网站建设方案,建一个网站的步骤,网站设计 重庆Apache RocketMQ 发展历程回顾 RocketMQ 最早诞生于淘宝的在线电商交易场景#xff0c;经过了历年双十一大促流量洪峰的打磨#xff0c;2016年捐献给 Apache 社区#xff0c;成为 Apache 社区的顶级项目#xff0c;并在国内外电商#xff0c;金融#xff0c;互联网等各行…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 服务。
