【决策层速查 · 30 秒读完】 消息队列是电商系统的"解耦神器"。
5 个真实场景：秒杀削峰 / 订单异步处理 / 对账补偿 / ES 数据同步 / 延迟队列。
核心价值：异步解耦 + 削峰填谷 + 最终一致。

消息队列在电商的 5 个真实场景

一、什么是消息队列？

消息队列（Message Queue，简称 MQ）是一种异步通信机制——生产者把消息放到队列里，消费者从队列里取出消息处理。生产者不需要等消费者处理完，消费者也不需要实时等生产者。

主流消息队列：Kafka（高吞吐）、RabbitMQ（功能丰富）、RocketMQ（阿里双 11 验证）、Redis Stream（轻量）。

二、5 个真实场景

场景 1：秒杀削峰（最经典）

问题：秒杀活动瞬时流量是平时的 100 倍，直接打到数据库 = 数据库崩溃。

解决方案：

1. 用户秒杀请求先进入消息队列
2. 后端秒杀服务从队列按速率消费（每秒处理 1000 单）
3. 超出部分的请求在队列里排队等待

效果：数据库压力从 10 万 QPS 降到 1000 QPS，系统不崩。

场景 2：订单异步处理（最常用）

问题：用户下单成功后需要做很多事——扣库存、扣积分、发短信、发推送、记录日志……如果同步处理，用户下单要等 5-10 秒。

解决方案：

1. 下单主流程：创建订单 → 扣库存 → 返回"下单成功"（耗时 200ms）
2. 异步任务通过消息队列分发：扣积分、发短信、发推送、记录日志

效果：用户下单响应从 5 秒降到 200ms，体验大幅提升。

场景 3：对账补偿（最关键）

问题：支付平台（微信、支付宝）回调有时失败或延迟，导致订单状态不一致。

解决方案：

1. 订单系统先把"待支付"状态写入数据库
2. 发送"对账补偿"消息到队列
3. 补偿服务定时扫描：5 分钟未收到回调的订单，主动查支付平台

效果：对账覆盖率从 95% 提升到 99.99%，避免资金损失。

场景 4：ES 数据同步（架构必备）

问题：商品搜索需要 ES，但 ES 数据不能实时来自 MySQL（双写一致性难保证，且影响性能）。

解决方案：

1. 商品数据变更时，发送"商品变更"消息到队列
2. ES 同步服务消费消息，更新 ES 索引

效果：MySQL 和 ES 数据最终一致（通常 < 1 秒），搜索性能好。

场景 5：延迟队列（订单超时）

问题：用户下单后 30 分钟未支付，需要自动取消订单释放库存。

解决方案：

1. 下单时发送一条延迟 30 分钟的消息到队列
2. 30 分钟后消息被消费，检查订单状态
3. 如果仍未支付，自动取消订单 + 释放库存

效果：避免定时任务轮询（性能浪费），精确触发（误差 < 1 秒）。

三、消息队列选型

四、3 个常见坑

坑 1：消息丢失

原因：生产者发送失败 / 消费者处理失败 / 队列宕机

解决：

• 生产者：发送确认（ACK）机制
• 消费者：手动 ACK + 失败重试
• 队列：开启持久化 + 副本机制

坑 2：消息重复

原因：消费者处理成功后 ACK 失败，队列重发消息

解决：业务系统做幂等性设计（根据业务单号去重）

坑 3：消息积压

原因：消费者处理速度跟不上生产者

解决：增加消费者实例 + 优化消费逻辑 + 设置队列告警