消息队列落地里没人愿意明说的取舍

上周去紫东国际创意园的技术沙龙，散会的时候蹲在门口碰到个做电商的后端，手里夹着半根烟，脸拉得老长。 问了才知道，上周年中大促把系统搞崩了。三个核心服务——订单、库存、营销，全是同步串着调，用户点提交订单，要顺着接口链路过完三个服务才能返回结果，流量一上来，线程池直接打满，整个接口集群堵得死死的。 我问他为啥不上消息队列。 他猛吸了一口烟，说去年双11被坑怕了。当时上了RabbitMQ做异步下单，消费端没做好幂等校验，用户点了三次支付，消息重投了三次，真的扣了三笔钱。财务追着他骂了小半个月，从那以后他见了队列就发怵。

别把消息队列当银弹

真不是他个例。 太多人对消息队列的认知停留在“加了就能扛住大流量”的层面，根本没算过要付的代价。你把原来的同步调用改成异步，用户点完提交订单，订单系统先把本地事务写完，把消息丢进队列，剩下的扣库存、发优惠券、加积分的逻辑，全交给下游服务慢慢消费。听起来很顺，响应时间一下子从几百毫秒降到几十毫秒。 但麻烦在于，链路一旦拆成异步，原来同步调用里天然的一致性约束就没了。消息丢了怎么办？消费端处理失败了怎么办？下游服务临时挂了，消息堆在队列里攒了几个小时，等服务恢复的时候，用户早就因为等不及退单走了。 你省下来的那几十毫秒接口响应时间，最后全得补到排查一致性问题的时间上。

之前在雨花软件园碰到个做工业互联网的开发，他们的场景更纠结。车间里的设备告警信号，必须实时传到平台，晚个两秒可能设备就因为过热烧了。一开始为了扛住设备上报的海量运行数据，用Kafka开了批量发送，攒够100条消息才打一个网络包。结果一次园区网络抖动，攒的二十条告警消息延迟了三秒才送到平台，值班的运维差点没吓死。 最后他们没搞什么复杂的优化，就是把通道拆了。核心告警走低延迟的专属队列，关批量发送，哪怕吞吐量低一半也没关系；剩下的设备温湿度、运行时长这类非紧急数据，走原来的高吞吐批量通道。 没什么高大上的技巧。 就是取舍。

选型的时候别盯着吞吐量死磕

很多人选消息队列的时候，上来就把各家的性能测试报告翻个遍，谁一秒能扛十万条消息，谁的端到端延迟能压到几毫秒，比来比去选个参数最猛的。 说白了，90%的中小团队，业务量根本到不了那个量级。你一个做本地社区的平台，一天的消息量撑死了几百万，哪怕是最基础的开源队列，都能轻轻松松跑满，根本摸不到性能天花板。 真正的成本在运维。你一开始选了个需要三个人专门盯的集群，结果团队就两个写业务的后端，平时赶需求都忙得连轴转，哪有空天天盯队列的磁盘使用率、分区同步状态、副本延迟？

之前有个朋友在江北的创业公司，一开始为了“技术先进”上了Pulsar，折腾了三个月，碰到一次分区重平衡的问题，翻遍了官方文档都没找到解决方案，整个集群卡了快两个小时，差点把核心业务搞挂。最后咬咬牙切回了RabbitMQ，半天就迁完了，后来大促扛了三倍流量，连个告警都没弹过。 说真的，没必要。 你又不是要做亿级用户的社交平台，犯不上为了那点理论上的性能优势，给自己挖运维的坑。选型的核心从来不是谁的参数好，是你的团队能不能hold住出问题的时候。

那些没人写在官方文档里的细节

我见过太多人，配完消息队列就把它当黑盒扔在那。 尤其是死信队列，很多人觉得消息消费失败三次，自动丢进死信队列就万事大吉了。真碰到事的时候你才会发现，死信队列里悄咪咪堆了几千条用户的退款申请，因为消费端的接口改了个字段名，消息体格式对不上，所有消息全消费失败了。没有告警，没有人工介入，等客服接到用户投诉的时候，已经过了两天。 死信队列从来不是消息的垃圾桶，是你最后一道风险防线。 还有更离谱的。之前帮朋友排查问题，他说队列里的消息经常莫名其妙少一半。查了半天才发现，他为了省磁盘空间，把消息的保留时间设成了一小时，结果高峰期消费端因为CPU打满，消费速度直接掉了一半，消息还没来得及被读，就被系统自动清理了。 官方文档会明明白白写着“消息保留超过时间会被删除”，但不会告诉你，你那个消费端的峰值处理能力，根本配不上你设的保留时间。 我还见过有人把消息队列当数据库用。把所有用户的操作日志全丢在队列里存着，想着等需要做分析的时候再慢慢消费，结果攒了几十T的消息，磁盘直接打满，整个集群挂掉，连带着所有依赖队列的业务全停，当时整个团队加班到凌晨三点才把服务恢复。 前几天在软件大道的鸭血粉丝店碰到个做了十年开发的老工程师，他说用了这么多年消息队列，最大的感悟就是，这东西本质就是个帮你削峰填谷的工具。 没什么玄乎的。 你用得好，大促的时候流量冲上来，它能帮你把洪峰接住，不至于把后端服务直接冲垮；用不好，它就是藏在系统链路里的定时炸弹，哪天网络抖一下，配置改一下，就能给你捅个大篓子。