消息队列实战：解耦、削峰与最终一致

MQ 不是免费的：它把同步调用换成异步投递，同时引入丢失、重复、顺序、积压四类新问题。这篇讲清三个价值、四类故障的防御、最终一致性的落地方式与选型建议。

一、MQ 的三个核心价值

一个下单接口要同步做完这些事：扣库存、写订单、发优惠券、通知物流、发短信。链路一长，任何一环抖动都会把用户按在 loading 上等；某一环挂了，整条链路一起挂。解耦——下单服务只管发一条「订单已创建」事件，发券、物流、短信各自订阅，加一个新下游不用改下单代码；削峰——瞬时 10 倍流量先写进队列，消费者按自己的能力匀速消费，保护数据库等脆弱下游；异步——用户请求链路只做核心步骤，非核心步骤异步完成，响应时间直接砍半。

二、什么时候不该用 MQ

MQ 是拿复杂度换吞吐与弹性，不是所有场景都划算。需要即时结果的查询类接口、强一致要求的扣款记账、以及三个人的小项目都不适合——等「同步链路顶不住」再引入。一条判断标准：拆开之后，业务能接受「稍后一致」吗？能，才谈引入。

MQ 把「网络调用会失败」从一个点扩散成了三处——生产、Broker、消费。补完四门功课再上线。

三、核心概念与投递语义

基本模型：生产者发送消息到 Broker（按主题或队列组织），消费者组订阅并消费。投递语义有三档：至多一次（可能丢、不重复，日志采集类可用）；至少一次（可能重复、不丢，绝大多数业务的选择）；恰好一次（理想态，端到端完全精确的代价极高）。工程界的成熟做法是：至少一次投递 + 消费端幂等 = 事实上的恰好一次。另一个关键细节是 ack 时机——先处理后 ack 保证不丢（处理失败不 ack、消息重投），代价是可能重复；先 ack 后处理换来不重复，但处理中途宕机就丢消息。业务消息选前者，配合幂等。

四、四类故障与防御

四条里最容易被低估的是重复消费——几乎所有 MQ 在异常路径上都会重复投递，幂等不是「优化项」，是必选项。好消息是它有固定套路：给每条消息一个业务唯一键（订单号 + 事件类型），消费前先查去重表或 SETNX，处理过就跳过。顺序问题则要认清：分区内才有序——用订单号做路由键让同一笔订单固定落在同一分区，代价是热点订单会影响该分区的吞吐。

五、削峰填谷的正确姿势

削峰的本质是「用队列当缓冲池」，三个量必须算清楚：峰值倍数与持续时间（峰值是均值 10 倍、持续 1 分钟，队列就要能装下这一分钟多出来的约 9 倍流量）；消费能力（按 lag 指标扩缩容，否则队列只会一直涨）；下游容量（消费端扩到 10 个实例，数据库还是那个数据库——队列保护的是缓冲，不是下游本身的极限）。再配两件兜底：死信队列（反复失败的消息进 DLQ 并告警）与降级策略（积压超阈值时丢弃非关键消息，保住核心链路）。

六、最终一致性怎么落地

「用 MQ 保证一致性」是个常见误区——MQ 保证的是投递，不是一致性。生产级做法通常是「本地事务 + 消息表」：发消息与业务写入在同一个本地事务里（写订单的同时往 outbox 消息表写待投递记录，要么都成功要么都失败）；异步投递（独立进程扫消息表或订阅 binlog 变更投递到 MQ，成功后标记）；消费端幂等 + 重试 + 死信告警；对账兜底（T+1 跑对账任务，比对两边数据并补偿差异）。思想一句话：不追求任何时刻都一致，追求任何差异最终都会被收敛。

七、选型速查

选型顺序建议：先看业务消息形态（是否需要事务 / 延迟 / 顺序），再看吞吐量级，最后看团队运维能力——别为了「技术先进」选一个没人会运维的引擎。

八、实践清单

• 引入前先回答：业务能接受「稍后一致」吗
• 业务消息一律「至少一次 + 消费端幂等」
• 生产者开确认、Broker 开持久化与副本、消费者手动 ack
• 需要顺序就用业务键路由到同一分区，接受吞吐代价
• 配 lag 监控、按 lag 扩缩容、死信队列与告警
• 一致性用「本地消息表 + 重试 + 对账」三件套，不指望 MQ 本身

速查卡

写在最后

消息队列的价值在「弹性」：把波动的流量和稳定的处理能力解耦开。但它同时把「网络调用会失败」这件事从一个点扩散成了三处（生产、Broker、消费）——所以引入 MQ 的正确姿势，是把丢失、重复、顺序、积压这四门功课提前补完，而不是等出事再补。