在使用 RocketMQ 时，有哪些机制或策略可以用来防止消息被重复消费？

回答思路

1. 【回答框架 1】消息重复消费的根本原因在于网络和分布式场景下的至少一次投递语义。RocketMQ 默认提供至少一次投递，即消息可能因重试、故障转移、消费者重启等原因被多次投递给消费者。
2. 【回答框架 2】要确保不重复消费，核心策略是消费端幂等。实现幂等通常需要业务标识去重，例如使用唯一业务键结合数据库唯一约束、Redis setnx 或状态记录，在消费前检查是否已处理过，处理中或处理后记录状态，再次消费时直接返回成功。
3. 【回答框架 3】RocketMQ 本身也提供一些优化：消费组可以配置消费模式为集群或广播，集群模式下每条消息只投递给同一消费组内的一个消费者，但重试仍可能造成重复；消费者启动时可设置消费位点，但这不是幂等的替代方案。
4. 【回答框架 4】另外，消费失败后的重试机制可能造成顺序重复，可在业务层记录消费成功状态并使用分布式锁或唯一标识来保证并发场景下的幂等，但分布式锁只保证互斥，不直接保证业务幂等，需要配合唯一约束或去重记录。
5. 【回答框架 5】在实际项目中，建议将幂等设计放在消费入口，建立全局唯一的消费记录表，利用数据库唯一索引或 Redis 的 setnx 操作确保相同消息只被成功处理一次，同时考虑消息重投和业务回滚的风险。
6. 【关键点 1】RocketMQ 默认是至少一次投递语义，重复消费在所难免。
7. 【关键点 2】确保不重复消费的关键是消费端幂等设计，而非仅在 MQ 端规避。
8. 【关键点 3】常用幂等方案包括唯一业务键加数据库唯一约束、Redis setnx、状态记录等。
9. 【关键点 4】分布式锁只能保证互斥，不能单独保证业务幂等，需结合唯一标识和状态记录。
10. 【关键点 5】消费失败重试会引发重复，幂等逻辑应覆盖所有重试路径。
11. 【易错点 1】误以为开启消费者手动 ACK 就能避免重复消费，实际 ACK 只影响重试，不能保证不重复。
12. 【易错点 2】在消费逻辑中只依赖分布式锁，而不做唯一性校验，可能导致锁失效时重复处理。
13. 【易错点 3】未对重试消息做幂等处理，导致相同业务数据被多次写入或执行多次。