在使用消息队列时防止消息重复消费是一个常见且关键的问题，尤其是在分布式系统中。以下是几种典型的解决方案，涵盖生产者、消费者和系统设计层面：

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去重，低频场景用数据库去重表。
• 监控与补偿：通过日志和定时任务检查未处理或重复消息，人工或自动修复。

通过以上方法，可以在绝大多数场景下有效避免消息重复消费问题。