在使用消息队列时，面对重复投递的消息，通常有哪些策略来确保业务处理的幂等性？

回答思路

1. 【回答框架 1】消息队列可能因网络、消费者处理超时等导致重复消息，幂等性是指对同一操作执行多次结果一致。核心思路是让业务操作具备天然幂等或通过额外机制去重。
2. 【回答框架 2】常见方案包括：利用数据库唯一约束，如唯一索引或主键，对相同业务标识（如订单号）插入或更新时直接冲突或忽略；使用分布式锁或Redis setnx等保证同一时刻只有一个处理；记录已处理的消息ID或业务ID，在处理前检查状态。
3. 【回答框架 3】对于更新操作，可使用版本号或乐观锁，版本不匹配则返回失败；或采用状态机，仅允许在特定状态下流转；对于非关键操作，可通过重试补偿。
4. 【回答框架 4】幂等服务要求操作本身设计为可重入，例如支付回调中先查单再改状态。选择方案需结合业务场景和性能要求，最终达到重复消费不重复处理的效果。
5. 【关键点 1】幂等性需结合业务设计，如数据库唯一键和业务状态字段
6. 【关键点 2】通用机制包括唯一键约束、分布式锁、消息ID去重和版本号控制
7. 【关键点 3】处理重复消息时优先检查状态，避免重复写入或多次扣减
8. 【易错点 1】不能仅依赖消息队列的至少一次投递来保证严格不重，需在消费端实现幂等
9. 【易错点 2】分布式锁不是万能，需考虑锁失效和释放问题，应结合业务标识和状态记录
10. 【易错点 3】设计幂等时要考虑并发和性能，避免锁长期占用或全表扫描