RabbitMQ重复消费主因是网络抖动致ACK丢失，导致消息重投；解决核心是手动ACK与幂等性结合：业务完成且幂等标识（Redis/DB）原子落库后才ACK，前置校验唯一ID并设合理过期。
防止消费端因网络抖动导致重复 ACK，本质不是“阻止发 ACK”，而是避免 RabbitMQ 误判消息状态、进而重复投递。网络抖动时，消费者可能已处理完业务、正要发 ACK，但 ACK 包丢失——RabbitMQ 没收到，就会重发消息；而消费者其实已经处理过了，这就触发了重复消费。所以关键在：让 ACK 行为与业务处理真正绑定，且具备可重试、可识别的幂等性。
手动 ACK 必须配合业务完成时机
自动 ACK 绝对不可用。手动 ACK 是基础前提，但光“手动”不够，必须确保：
- ACK 只在业务逻辑完全成功执行后才调用；
- 不能在 try 块开头就 ACK（否则异常时消息已删，业务失败却无从补偿）；
- 也不能在 catch 中盲目 nack 并 requeue（可能造成无限循环重试）；
- 推荐结构：业务执行 → 成功写入幂等标识（如 Redis 或 DB）→ 再发 basicAck()。
幂等校验必须前置且原子
ACK 前必须确认“这条消息是否已被处理过”。这不是可选步骤，是必经关卡：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 提取消息唯一 ID（由生产者注入，如
message.getMessageProperties().getMessageId()或自定义 header）； - 查 Redis：用
SETNX key value EX seconds，成功则继续，失败则直接 ACK 并 return； - 查数据库：用
INSERT INTO dedup_table (msg_id) VALUES (?)，捕获DuplicateKeyException，捕获到即跳过业务； - 无论哪种方式，查+写必须在同一事务或同一原子操作中完成，避免“查了没写成，业务执行了，但幂等记录丢失”。
ACK 失败本身也要有兜底策略
即使你严格按流程做了，网络抖动仍可能导致 channel.basicAck() 调用失败（抛 IOException）。此时：
立即学习“Java免费学习笔记（深入）”；
- 不要静默吞异常，也不要 retry ACK（RabbitMQ 不支持重复 ACK 同一个 deliveryTag）；
- 应记录 warn 日志 + 上报监控，同时确保幂等标识已落库/落 Redis；
- 因为幂等已生效，后续重投的消息会被直接过滤，ACK 是否成功已不影响业务一致性；
- 真正的风险点不在 ACK 失败，而在业务成功但幂等标识未持久化——这才是要严防的断点。
避免常见反模式
这些做法看似省事，实则埋雷：
- 在业务方法里先
basicAck()再处理逻辑（ACK 后宕机 → 消息丢失）； - 用本地内存（如 ConcurrentHashMap）存已处理 ID（JVM 重启即失效）；
- Redis Key 不设过期时间（内存泄漏）或过期太短（高并发下刚过期就被重投）；
- 数据库去重表没加唯一索引，只靠应用层判断（并发插入时仍可能双写）。
