在使用消息队列时防止消息重复消费是一个常见且关键的问题，尤其是在分布式系统中。以下是几种典型的解决方案，涵盖生产者、消费者和系统设计层面：
1. 生产者端：避免消息重复发送
（1）消息唯一标识（Message ID）
- 原理：为每条消息生成全局唯一ID（如UUID、雪花算法ID），并在发送前记录该ID。
- 实现：
- 发送消息时，携带唯一ID。
- 消息队列服务端（如Kafka、RocketMQ）或业务端维护已发送消息的ID集合（可存储在Redis、数据库）。
- 发送前检查该ID是否已存在，若存在则不再发送。
- 优点：简单直接，适用于所有消息队列。
- 缺点：需额外存储和查询ID，可能增加延迟。
（2）消息队列的幂等性支持
- 原理：利用消息队列自身的幂等性机制。
- 示例：
- Kafka：通过 enable.idempotence=true 开启生产者幂等性，结合 acks=all 和事务机制，保证消息仅发送一次。
- RocketMQ：事务消息机制（二阶段提交）避免重复。
- 优点：无需业务代码介入，由中间件保障。
- 缺点：依赖特定消息队列的功能。
2. 消费者端：保证消息处理的幂等性
（1）业务逻辑幂等设计
- 原理：设计业务逻辑时，确保多次处理同一消息的结果一致。
- 常见方法：
- 数据库唯一约束：例如订单ID唯一键，重复插入会失败。
- 乐观锁：使用版本号（Version）或状态字段，更新时校验版本。
- 去重表：单独维护已处理消息ID表，处理前先查询。
- 示例：
- -- 订单表唯一键
CREATE TABLE orders (
order_id VARCHAR(64) PRIMARY KEY,
...
);
-- 乐观锁更新
UPDATE account SET balance = balance - 100, version = version + 1
WHERE user_id = 123 AND version = current_version;
（2）消费者端消息去重
- 原理：消费者维护已处理消息的ID集合。
- 实现：
- 本地缓存：将已处理消息ID缓存在内存（如ConcurrentHashMap），适合单机且数据量小的场景。
- 分布式缓存：使用Redis的 SETNX 或布隆过滤器（Bloom Filter）判断消息是否已处理。
- 数据库查询：处理前查询业务表或去重表。
- 优点：通用性强，适用于所有消息队列。
- 缺点：需权衡存储成本和性能（如Redis的TPS）。
3. 消息队列服务端：消息去重机制
（1）Broker端去重
- 原理：消息队列服务端根据消息ID自动去重。
- 示例：
- RocketMQ：通过 UNIQUE_KEY 属性实现服务端去重。
- RabbitMQ：结合 message_id 和插件（如 rabbitmq_message_deduplication）实现。
- 优点：对业务透明。
- 缺点：依赖消息队列的支持，可能增加Broker负载。
（2）消息过期机制
- 原理：设置消息TTL（Time-To-Live），过期后自动删除，避免堆积导致重复消费。
- 实现：配置队列或消息的 expiration 属性（如RabbitMQ）。
- 适用场景：对时效性敏感的业务（如秒杀）。
4. 最终一致性方案
（1）事务消息
- 原理：通过消息队列的事务机制（如RocketMQ事务消息）保证生产者发送和业务操作的一致性。
- 流程：
- 发送半事务消息。
- 执行本地事务。
- 根据事务结果提交或回滚消息。
- 优点：严格避免重复。
- 缺点：实现复杂，依赖消息队列支持。
（2）消息状态表
- 原理：业务系统维护消息状态（如“已发送”、“已消费”），通过定时任务补偿未完成的消息。
- 实现：结合数据库事务和消息发送，确保两者原子性。
5. 典型场景的解决方案
场景1：支付回调通知
- 问题：支付平台可能多次发送相同通知。
- 方案：
- 生成唯一支付流水号，入库时校验唯一性。
- 更新订单状态时使用乐观锁（如 UPDATE order SET status='paid' WHERE status='unpaid'）。
场景2：库存扣减
- 问题：消息重复消费导致超卖。
- 方案：
- 扣减库存时检查当前库存是否充足。
- 记录扣减流水，通过唯一订单ID防止重复扣减。
总结
- 优先选择业务层幂等设计（如唯一键、乐观锁），这是最根本的解决方案。
- 结合消息队列特性（如Kafka幂等生产者、RocketMQ事务消息）减少重复发送。
- 权衡性能与可靠性：高频场景用Redis去重，低频场景用数据库去重表。
- 监控与补偿：通过日志和定时任务检查未处理或重复消息，人工或自动修复。
通过以上方法，可以在绝大多数场景下有效避免消息重复消费问题。