2026年2月13日，有来自北京的消息，消息队列作为企业级分布式系统里的核心组件，它的稳定性直接关联到了数十亿美元量级的核心业务的运转情况。某头部互联网公司曾经经历了Kafka集群频繁出现写入失败这样严峻的挑战之后，首次公开披露了其花费18个月时间才得出的“代理层+双写迁移”混合架构解决方案，此方案已经成功支撑了万亿级的消息流转，进而引发了技术圈的广泛关注。
痛点溯源
2024年第三季度开始后，Kafka集群出现一种周期性的写入抖动现象，在峰值时段时，写入失败的概率高达7.3%。这个集群承担了包含订单、支付以及风控等在内的32个核心业务，单个Topic的订阅方数量最多的时候能达到47个下游系统。因为业务之间的耦合程度过高滴滴出行企业版代理商，所以在2024年11月，直接替换消息队列的尝试不得不停止，经过预估，全量迁移将会致使至少15个业务线中断服务超过72小时。
发现运维团队在2025年1月的故障复盘中，写入失败主要是由于突发流量致使分区Leader选举超时。在2025年除夕夜的大促里，单集群每秒写入请求峰值冲破28万，分区数量超过5000个的Topic出现持续25分钟的数据写入无法可用。
代理缓存
技术团队在2025年3月上线了消息队列代理层，其采用Codis集群当作写入缓冲，当Kafka集群不可写时，会把要发送的消息暂存到Codis，暂存的最长时间被设定为72小时有这个情况，代理层里面设置了重试机制，一开始重试的间隔是500毫秒，每次失败之后重试间隔会增加，最大的间隔不会超过5分钟。
Codis集群被部署在3个可用区当中，总共配置了12个节点，单个节点的内存容量是64GB。根据2025年第二季度给出的统计结果来看，代理层平均每天处理的写入失败重试请求大约有4.7万次，单次暂存消息的最大体积能够达到2MB。在该模块上线以后，Kafka写入失败对业务所造成的影响时长从平均18分钟急剧下降到了不足30秒。
选型对比
2025年4月，测试团队展开了相关测试，是在256核CPU、1.5TB内存的物理机环境下进行的，持续时间为6周，属于对比压测。到了5月，测试数据呈现出来了。其中显示，当消息体达到2048字节，Topic数量增加到256个的时候，Kafka吞吐量出现了变化，从每秒12.3万条急剧下降至每秒2.1万条，且降幅达到了82.9%。
同一个时期，RocketMQ在256 Topic情景之下，其吞吐量一直维持在每秒6.8万条，而当处于512 Topic时，依旧保持每秒6.5万条。在关于写入延迟的层面上，在ACK等于1模式的状况之中，RocketMQ平均延迟是2.1毫秒，在ACK等于3模式的时候则为6.8毫秒，其波动幅度并没有超过15%。基于共享集群所存在的资源隔离需求，团队在2025年6月正式挑选RocketMQ作为下一代消息队列的底座。
双写迁移
该迁移方案，于2025年7月份开始启动，采用的是生产端双写策略。业务方在改造客户端之后，会同时朝着原有Kafka集群以及新RocketMQ集群写入全量数据。截止到2025年10月，已经完成了支付、风控等19个核心业务的双写接入，双写期间日均消息总量超过800亿条。
消费端的迁移这事，借助ConsumerProxy来统一管理消费进度，代理层把业务原有的Group ID拿来复用，靠着Rebalance机制达成平滑切换，在那已经完成的12个业务迁移里头，单个业务平均切换所耗费的时间仅仅只需45分钟，重复消息率比万分之三还要低，运行达到30天之后，等Kafka数据依据过期策略自动清理掉，就能够让对应集群下线，全流程仅仅需要业务方开展一次客户端改造。
定制改造
针对公司单集群百万Topic的那种极端场景，研发团队对开源RocketMQ实施深度定制。在2025年9月的时候，完成元数据管理模块的重构，把Topic路由信息从集中式存储转变为分布式KV结构。经过测试，改造之后单Broker能够支撑的Topic数量从开源版的3.7万提升到112万，元信息同步耗时从秒级缩短至200毫秒以内。
针对于机械硬盘场景之中的IO瓶颈，团队于2025年第四季度对数据删除策略作出了优化，把默认的“整日删除”变更为“分时段、分文件删除”，还引入了IO负载自适应调节机制，在混合部署了SATA盘与SSD盘的集群里面，数据删除所引发的IO峰值从95%下降到了41%，相关的优化代码于2026年1月向社区提交了Pull Request。
针对该项目负责人所透露的情况，目前存在着推进RocketMQ主从自动切换功能开发的相关事宜，其中新方案有着在2026年第二季度上线的计划滴滴出行企业版代理商，并且这个计划是基于Raft协议来实现Broker选主的，达到该目标后届时能够进一步降低单分片顺序消费场景下的运维干预频次，与此同时团队已经开始了对于Serverless化的消息队列产品形态的调研。
在您迁移核心中间件之际，是更倾向于进行彻底重构，还是借助代理层来实施渐进式改造？特别邀请大家于评论区分享各自身切实的实战经验，点赞数排名在前三位的将会获取技术团队所编撰的《万亿级消息队列迁移实践》电子手册。
