如何保证mq消息的幂等性

大家好，今天咱们聊聊一个面试高频考点：如何保证mq消息的幂等性。在分布式系统中，消息中间件（MQ）异步解耦的能力很强大，但消息重复消费的问题也让人头大。比如面试官问你："订单支付成功后，发MQ通知库存系统扣减库存，如果消息重复消费了怎么办？" 这时候，mq消息的幂等性设计就是关键了。

2025年Java面试宝典（含分布式、高并发、MQ等高频考点）已经整理好： 链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g 提取码: 9b3g

为什么需要处理mq消息的幂等性？

MQ本身不保证消息只消费一次（Exactly-Once）。网络抖动、Consumer重启都可能导致mq消息被重复投递。如果处理不当，重复扣款、重复发货这种严重问题就来了。因此，幂等性设计不是可选项，而是分布式系统的基本功。

保证mq消息幂等性的核心方案

方案1：消费方生成唯一业务ID

最常用也最有效！在生产者（Producer）发送mq消息时，给每条消息绑定一个全局唯一ID（比如业务ID+场景+时间戳）。消费者（Consumer）在处理前，先去查数据库或Redis：

SELECT * FROM message_log WHERE msg_id = 'unique_id_123'

如果记录已存在，说明这条mq消息已经被处理过，直接丢弃或ack就行。没有记录？那就处理业务，处理完立刻落库记录这个ID。这个方案对mq消息的幂等性保障效果显著。

方案2：利用数据库唯一键约束

处理扣款、订单状态更新这类操作时，业务表本身可以加唯一索引。比如订单流水表：

CREATE TABLE payment_flow (
    order_id VARCHAR(64) NOT NULL,
    tx_id VARCHAR(128) NOT NULL UNIQUE, -- 支付平台返回的唯一流水号
    amount DECIMAL(10,2),
    ...
);

当重复消费导致第二次插入相同tx_id时，数据库直接报DuplicateKeyException，业务代码捕获异常后返回成功即可。这样用数据库的能力来保证幂等性，非常靠谱。

方案3：基于状态机的乐观锁

适合更新型操作。比如订单状态从"已支付"->"已发货"，可以在更新时加条件：

UPDATE orders 
SET status = 'SHIPPED', version = version + 1 
WHERE order_id = '1001' AND status = 'PAID' AND version = 2;

如果因为mq消息重复导致第二次更新，status或version条件不满足，影响行数为0，直接忽略。这样既避免状态乱跳，又保证了幂等性。

方案4：使用Redis原子操作

Redis的SETNX（或Redisson的分布式锁）适合做幂等性拦截。例如：

String key = "order_pay_1001";
Boolean result = redisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.MINUTES);
if (!result) {
    return; // 已处理过
}
// 执行业务逻辑...

注意设置合理的过期时间，避免死锁。Redis性能高，但对数据一致性要求严格的场景要谨慎。