政策快报平台从上线到现在消息队列换了3次。第1次用Redis的List做简单队列。第2次迁移到RabbitMQ。第3次迁移到RocketMQ。每一次换型都是因为旧的方案已经无法满足新的需求。每一次换型也都有代价——数据迁移、代码改造、团队学习成本。今天复盘这3次选型背后的思考为什么换、怎么换的、换了之后解决了什么问题。3次选型第一次Redis List简单队列阶段上线初期消息量很小。每天几千条消息用Redis的List做队列完全够用。生产者LPUSH消费者RPOP简单直接。优点无需额外组件Redis已经在用了零成本接入。缺点不支持消费确认、不支持重试、消息量大时容易积压。这个阶段持续了大约6个月。直到某天爬虫采集量突然暴增Redis队列积压了几万条消息消费者处理不过来有些消息还没消费就被淘汰了。因为没有确认机制消息丢失后无法找回。第二次RabbitMQ功能完善阶段消息量起来之后我们开始寻找更专业的消息中间件。RabbitMQ成了当时的选择支持消费确认ACK消息不会丢失支持重试和死信队列失败消息可以重新处理支持多种路由模式灵活匹配不同的业务场景优点功能全面、稳定、社区活跃。缺点使用Erlang编写运维团队不熟悉出问题排查困难吞吐量在单机队列中算不错但无法水平扩展。这个阶段持续了大约2年。遇到的最棘手的问题是高峰期偶尔出现消息积压时无法快速扩容只能等流量自然回落。平时还算稳定但业务增长后碰到了吞吐量瓶颈。第三次RocketMQ大规模分布式阶段2025年初业务进一步增长消息量已经达到每天数百万条RabbitMQ开始频繁出现性能瓶颈消息积压、延迟升高、消费者频繁超时。经过评估我们决定迁移到RocketMQ。选择理由是支持分布式部署水平扩展能力强吞吐量高单机支持十万级QPS支持事务消息、延时消息支持消息轨迹追踪问题排查方便阿里出品Java技术栈团队熟悉运维成本低迁移过程大致分了三个阶段持续了约1个月。先双跑验证再灰度切流最后全量切换控制风险。选型决策的一些思考选型适用场景不适用场景Redis List消息量小万级/天、允许少量丢失消息量大、需要确认机制RabbitMQ消息量中等百万级/天、功能需求全面需要水平扩展、吞吐量要求极高RocketMQ消息量大千万级/天、需要分布式部署团队不熟悉Java生态、运维能力有限经验总结选型不是一步到位的。从简单方案开始遇到瓶颈再升级比一开始就上“重型武器”更务实。Redis List用了6个月RabbitMQ用了2年RocketMQ用了1年——每一步都比上一步撑得更久。团队能力是重要的选型维度。功能再强大运维不熟悉、排查问题困难也会成为新的瓶颈。RocketMQ最终胜出的原因之一是团队对Java技术栈的熟悉度远高于Erlang。迁移成本需要考虑清楚。每次换型都需要改造代码、迁移数据、切换流量。不要轻易为了“技术先进”而换型要为了“解决实际瓶颈”而换型。消息队列的选型没有“最好”只有“最合适”。每个阶段有每个阶段的需求选择当时最合适的方案等需求变化了再调整。政策快报平台的实践是从最简单的方案起步在遇到瓶颈时果断评估是否到了该升级的节点而不是过早追求“一步到位”或过晚才响应业务需求。