mq消息重复消费策略

MQ消息重复消费策略：高并发场景下的必考面试题

在分布式系统面试中，MQ消息重复消费问题绝对是高频考点。作为开发过多个高并发系统的老码农，今天就和大家口述聊聊这个问题的本质和落地解决方案，帮你轻松拿下这类面试题。

为什么会出现MQ消息重复消费？

想象一下这个场景：订单支付成功后，系统会往MQ发条消息通知库存服务扣减库存。如果消费端处理完业务，但MQ没有及时收到ACK（确认），这条消息就可能被重新投递。结果就是：库存被重复扣减，老板脸都绿了！这就是典型的重复消费问题，尤其在网络抖动或服务重启时高发。

根治重复消费的四种核心策略

消费端幂等设计（最推荐！）

核心思想： 让业务逻辑具备“多次执行=一次执行”的特性。举个真实案例：

• 支付回调通知：用支付单号+回调类型作为唯一键，处理前先查库
• 创建订单场景：客户端生成唯一请求ID，服务端校验ID是否已存在
• 数据库层面：对业务主键建立唯一索引（最简单粗暴有效）

MQ服务端去重（特定场景）

像RocketMQ有消息指纹机制，通过SHA1算法生成唯一指纹。但注意！跨地域部署或集群切换时仍可能失效，不能完全依赖。

中间表/日志表（保底方案）

建个consumed_messages表记录已处理消息ID（msg_id）。伪代码逻辑：

START TRANSACTION;
SELECT * FROM consumed_messages WHERE msg_id='xxx' FOR UPDATE;
IF not found THEN
  -- 执行业务逻辑
  INSERT INTO consumed_messages VALUES ('xxx');
COMMIT;

业务状态机（高级玩法）

比如订单状态从"已支付"到"发货中"，设计成状态机模式：

stateDiagram-v2
    [*] --> 已支付
    已支付 --> 发货中 ： 扣减库存成功
    发货中 --> 已发货

即使重复收到扣库存消息，只要状态不是"已支付"就直接跳过。

面试官最爱问的坑点

1. Redis做去重靠谱吗？
   集群切换可能导致数据丢失，必须配合持久化方案。我们生产环境用Redis+MySQL双写保障

2. 消息过期时间设多久？
   根据业务容忍度定！金融类建议72小时，活动类2小时足够

3. 全局ID生成方案？
   Snowflake > UUID > 数据库自增ID（有性能瓶颈）

🔥 2025最新Java面试题库已更新：
🔗 百度网盘下载链接
提取码：9b3g（覆盖Kafka/RabbitMQ/RocketMQ高频题）

实践中的血泪经验

1. 消息表要分库分表：用msg_id做hash分片，避免单表瓶颈
2. 定期清理数据：写个定时任务删除3个月前的记录
3. 监控报警最关键：用Prometheus监控重复消息率，超过1%立即告警

💡 小技巧：如果大家准备买面试鸭会员，记得走 面试鸭返利网 找我返25元！操作步骤：

1. 访问面试鸭返利网
2. 搜索"面试鸭"获取专属链接
3. 下单后联系客服返现
   

总结

解决MQ消息重复消费的核心还是幂等设计+状态机，重点要理解业务场景的容忍度。下次面试被问到，就从业务影响、技术方案、容错机制三个维度展开，保证让面试官眼前一亮！