Java面试之消息队列如何解决消息幂等性_网络技术

RabbitMQ 重复投递源于“至少一次”语义，未及时 ACK 时会重发；需用 Redis SETNX 实现幂等消费，并辅以 DB 唯一索引兜底，避免事务与 Redis 耦合。

为什么 RabbitMQ 会重复投递消息？

不是 RabbitMQ 故意“发两遍”，而是它默认采用“至少一次”（at-least-once）投递语义。只要消费者没在 channel.basicAck() 前正常返回 ACK，Broker 就认为消费失败，会重新入队或投递给其他消费者。常见触发点包括：网络超时、JVM Full GC 导致消费线程卡住、消费者进程突然 kill -9、手动调用 channel.basicNack(requeue=true)。这些都不是 Bug，是分布式系统为保障可靠性做的权衡。

消费者处理耗时 > consumer_timeout（RabbitMQ 3.8+ 默认 30 分钟），Broker 主动 requeue
消费者在 basicConsume() 后崩溃，未发送任何 ack/nack，消息重回 ready 状态
集群主从切换期间，部分 unacked 消息被误判为“未确认”，触发重发

用 Redis + SETNX 实现最简幂等消费

这是生产环境最常用、落地最快的方式。核心就一条：收到消息后，先用消息 ID 向 Redis 写一个带过期时间的 key；写成功才执行业务逻辑；写失败（key 已存在）直接跳过。不用事务、不查 DB，性能损耗极小。

messageId 必须全局唯一且稳定——优先用业务字段（如 order_id），其次用 MessageProperties.getMessageId()，慎用内容哈希（同一业务逻辑多次发相同内容，但语义不同）
必须设过期时间（如 24 小时），否则 Redis 内存无限增长；过期时间要远大于单次业务最大耗时，但不宜超过业务生命周期（比如订单超时关单是 30 分钟，幂等 key 过期设 2 小时足够）
用 StringRedisTemplate.opsForValue().setIfAbsent(key, "1", Duration.ofHours(2))，不要用 hasKey() + set() 两步操作（非原子，竞态失败）

@Autowired
private StringRedisTemplate redisTemplate;

public void handleMessage(Message message) {
    String messageId = extractMessageId(message); // 如：从 headers 取 "x-order-id"
    String dedupKey = "mq:dedup:" + messageId;

    Boolean isFresh = redisTemplate.opsForValue()
        .setIfAbsent(dedupKey, "1", Duration.ofHours(2));
    
    if (Boolean.TRUE.equals(isFresh)) {
        processBusiness(message); // 执行下单、扣库存等真实逻辑
    } else {
        log.warn("Duplicate message ignored: {}", messageId);
    }
}

数据库唯一索引兜底，不是替代方案

有人觉得“我 DB 有唯一索引，插入失败就说明重复”，这只能作为第二道防线，绝不能当主方案。因为：唯一索引冲突是业务异常，会打断正常流程；高并发下大量 insert 失败再 catch，对 MySQL 是无效压力；且无法防止“已插入但事务未提交时重复消费”的中间态问题。

适合场景：最终一致性要求极高、且业务本身天然带唯一键（如支付流水号、退款单号），可配合 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE
必须搭配 Redis 去重使用——Redis 判断“该不该进 DB”，DB 索引只拦住漏网之鱼
注意：MySQL 的 INSERT ... SELECT 或自增 ID 不构成幂等保障，别被误导

Spring AMQP 的 @RabbitListener 怎么加幂等？

别在 listener 方法里裸写去重逻辑。Spring AMQP 提供了更干净的切面式接入方式：用 ChannelAwareMessageListener 或自定义 AdviceChain，但最推荐的是封装一个幂等代理 Consumer Bean。

把去重逻辑抽成独立组件（如 DeduplicationService），所有 @RabbitListener 方法第一行调用 deduplicationService.checkAndMark(messageId)
避免在 listener 上加 @Transactional 后再去 Redis——事务和 Redis
不在一个上下文，回滚不联动；应确保 Redis 操作在事务外完成
若用 Spring Retry，必须关闭 requeue = true，否则重试会不断触发重复消费；建议改用死信队列 + 人工干预

幂等不是“加个判断就行”，本质是承认分布式系统没有银弹。Redis 去重失效、DB 唯一索引被绕过、消息体解析出错导致 ID 提取错误……这些细节比框架选型更容易决定成败。

# mysql # java # redis # ai # 退款 # 为什么 # red # asic # spring # rabbitmq # 分布式 # jvm # 封装 # select # catch # 线程 # 并发 # channel # 数据库 # bug # 的是 # 重发 # 这是 # 就行 # 这只 # 自定义 # 再去 # 极高 # 更容易 # 两步

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】