在 RabbitMQ 的使用场景中，消息被重复消费通常有哪些原因？请说明如何从生产端、消费端以及 Broker 层面进行预防和处理，确保消息处理的幂等性。
考察说明
考查对 RabbitMQ 消息投递与消费机制的理解，以及在实际系统中保证消息处理幂等性的工程能力。
回答思路
- 【回答框架 1】重复消费的根源在于消息投递的 at-least-once 语义：当消费者处理完消息但尚未确认（ack）时，若连接断开或消费端异常，Broker 会重新投递该消息；此外，消费者在手动 ack 前发生故障、或使用了自动确认但处理过程中宕机，也会导致重复。
- 【回答框架 2】消费端幂等是核心防线。常用方案包括：利用业务唯一标识（如订单号、消息内携带的 ID）配合数据库唯一约束或 Redis 的 SETNX 进行去重；或维护消费记录表，在处理前先查询是否已处理。幂等设计需覆盖插入、更新等场景，且要确保去重记录与业务操作在同一事务内，避免并发重复。
- 【回答框架 3】在生产端的预防包括：利用消息的 messageId 属性生成稳定业务键，或合理设置重试和确认机制，减少因生产者重复投递带来的重复。但生产端只能减少，无法完全避免，最终仍需消费端兜底。
- 【回答框架 4】RabbitMQ 层面可开启 publisher confirms 和手动 consumer ack，配合 requeue 策略，确保消息可靠投递，但这反而可能增加重复概率，因此必须与消费端幂等配套使用。
- 【回答框架 5】实际项目中，应结合具体业务场景，选择最适合的幂等方案，并通过监控与告警及时发现重复消费问题，不断优化处理策略。
- 【关键点 1】重复消费根因是 at-least-once 语义，消费者需实现幂等。
- 【关键点 2】幂等核心是去重，可基于业务唯一键加数据库唯一约束或 Redis 锁。
- 【关键点 3】生产端可用 messageId 和发布确认减少重复，但无法根除。
- 【关键点 4】手动 ack 结合幂等设计是标准做法，自动确认风险更高。
- 【易错点 1】仅靠消息确认无法避免重复，必须实现消费端幂等。
- 【易错点 2】用 Redis 做去重时，需注意设置过期时间和事务一致性，避免误判或数据不一致。
- 【易错点 3】勿将重复消费与消息丢失混为一谈，应分别设计各自策略。