RabbitMQ不保证消息不重复，幂等性需消费者实现；最可靠方式是全局唯一message ID加Redis setIfAbsent，因其原子性可防竞态，且需设TTL避免key堆积。
直接说结论：RabbitMQ 本身不保证消息不重复，幂等性必须由消费者自己实现；最常用、最可靠的方式是「全局唯一 message ID + Redis setIfAbsent」，而不是依赖数据库主键或内存 Set。
为什么 RabbitMQ 一定会出现重复消费？
RabbitMQ 的 at-least-once 投递语义决定了它无法 100% 避免重复：消费者处理完消息后，网络抖动导致 ack 未送达 broker，broker 就会重发该消息。这不是 bug，是设计取舍 —— 宁可多发，不可丢。
常见错误认知包括：
- 以为开了
durable=true+acknowledgement=manual就能防重复 - 以为用
prefetchCount=1就能串行化避免冲突 - 以为消费者 crash 后自动 requeue 不会触发重复逻辑
这些都和幂等性无关，只是影响消息可见性或投递节奏。
用 setIfAbsent 做去重的实操要点
核心是利用 Redis 的原子性操作判断是否首次消费。不要用 get + set 两步，那是竞态漏洞。
关键步骤：
- 生产者必须为每条消息生成并设置
message.getMessageProperties().setMessageId("xxx")（Spring AMQP 中）；若用原生客户端，需手动注入messageId字段 - 消费者拿到
message后，立即调用stringRedisTemplate.opsForValue().setIfAbsent(messageId, "1", Duration.ofHours(24)) - 返回
true表示首次消费，继续执行业务；返回false表示已存在，直接channel.basicAck()并 return -
Duration必须设 —— 不设 TTL 会导致 Redis key 永久堆积；24 小时是常见经验值，可根据业务消息生命周期调整
注意：messageId 不能靠 RabbitMQ 自动生成（默认为空），必须由生产者显式赋值，否则所有消息都共享同一个空字符串 key，全变成“已消费”。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
数据库唯一约束方案的适用边界
用 INSERT INTO t_consume_log (msg_id) VALUES (?) ON CONFLICT DO NOTHING（PostgreSQL）或 INSERT IGNORE（MySQL）也能做幂等，但只适合低频、强一致性要求场景。
问题在于：
- 每次消费都要写 DB，高并发下成为瓶颈，尤其当消费逻辑本身很轻（比如只是发个通知）时，DB 反而成了拖累
- 如果业务表本身没加
UNIQUE(msg_id)，那插入失败就等于没校验，白忙活 - 事务回滚时，
INSERT可能已落盘（取决于隔离级别），导致后续即使业务失败，也再无法重试
所以它更适合「消费即落库 + 落库即终态」的场景，比如订单创建成功后发 MQ 更新库存，此时库存扣减本身就要走 DB，顺手加个唯一索引即可，不用额外 Redis。
容易被忽略的三个细节
第一，messageId 必须全局唯一且稳定 —— 不能用时间戳+随机数拼接后 Base64，因为不同节点可能生成相同组合；推荐用 UUID v4 或雪花 ID。
第二，Redis key 过期时间不能短于消息最大重试窗口 —— 如果你配置了死信队列 + 最多重试 3 次，每次间隔 10 秒，那 TTL 至少要 > 30 秒，否则重试消息进来时 key 已过期，又会重复消费。
第三，别在消费逻辑里 catch 所有异常后吞掉 —— 如果业务抛出 RuntimeException 导致未走到 ack，RabbitMQ 会重发，但 Redis key 还在，下次来就会被拦截；这看似安全，实则掩盖了真实失败原因，应区分「业务失败」和「系统异常」，前者可 ack + 记录失败日志，后者才该让消息重回队列。
