在 RabbitMQ 中，默认情况下，不能保证消息不被重复消费，但可以通过 队列绑定方式 + 消费者竞争机制 来确保 同一消息只被一个消费者处理。以下是几种可行的方案：
方案 1：单队列 + 竞争消费者模式（默认行为）
原理
多个消费者订阅同一个队列，RabbitMQ 会以 轮询（Round-Robin） 方式分发消息。
天然保证同一消息只被一个消费者消费（因为队列里的消息被取出后就不再存在）。
代码示例
python
# 生产者发送消息到队列
channel.basic_publish(
exchange="",
routing_key="single_queue", # 直连队列（不经过 Exchange）
body="message1"
)
# 消费者1和消费者2竞争消费同一个队列
channel.basic_consume(queue="single_queue", on_message_callback=consumer1)
channel.basic_consume(queue="single_queue", on_message_callback=consumer2)
✅ 结果：
message1只会被consumer1或consumer2中的一个消费，不会重复。
适用场景
需要 多个消费者并行处理不同消息，但 同一消息只需处理一次。
注意：如果消费者处理失败并
requeue，消息可能被重新投递（需额外处理，见方案3）。
方案 2：单活跃消费者（Single Active Consumer）
原理
RabbitMQ 3.8+ 支持 单活跃消费者模式，同一队列同一时间只有一个消费者能接收消息。
其他消费者处于备份状态，主消费者断开后自动切换。
配置方式
python
channel.queue_declare(
queue="sac_queue",
arguments={"x-single-active-consumer": True} # 启用单活跃消费者
)
✅ 结果：
即使多个消费者订阅
sac_queue，也 只有1个消费者能获取消息。
适用场景
需要 严格串行处理消息（如订单状态机变更）。
缺点：无法利用多消费者并行提升吞吐量。
方案 3：业务幂等性（最佳实践）
原理
允许消息被多次投递，但业务逻辑保证 重复消费不影响结果。
实现方式：
数据库唯一约束（如
order_id防重复）。乐观锁（更新前检查
version字段）。Redis 记录已处理消息ID（如
SET message_id 1 EX 3600）。
代码示例
python
def process_order(message):
order_id = message.body.order_id
if redis.get(f"processed:{order_id}"): # 检查是否已处理
return
# 处理业务逻辑...
redis.set(f"processed:{order_id}", "1", ex=3600) # 标记已处理
✅ 优点：
高可用，可扩展多个消费者。
兼容 RabbitMQ 默认的轮询分发机制。
适用场景
高并发场景（如支付回调、库存扣减）。
方案 4：分布式锁（严格一致性）
原理
消费者处理消息前，先获取 分布式锁（Redis / ZooKeeper）。
确保同一时间只有一个消费者能处理消息。
代码示例
python
def callback(message):
lock_key = f"lock:{message.body.order_id}"
if redis.set(lock_key, "1", nx=True, ex=10): # 尝试加锁
try:
process_message(message)
finally:
redis.delete(lock_key) # 释放锁
else:
channel.reject(message.delivery_tag, requeue=True) # 重新入队
✅ 结果：
同一
order_id的消息 只会被一个消费者处理。
适用场景
严格避免重复消费（如金融交易）。
对比总结
| 方案 | 是否严格唯一消费 | 扩展性 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| 单队列+竞争消费者 | ✅ 是 | ★★★ | ★ | 默认场景，需防止 requeue |
| 单活跃消费者 | ✅ 是 | ★ | ★★ | 严格串行处理 |
| 业务幂等性 | ❌ 否（业务防重） | ★★★ | ★★★ | 高并发系统（推荐） |
| 分布式锁 | ✅ 是 | ★★ | ★★★★ | 金融级严格一致性 |
最终建议
优先使用业务幂等性（方案3），兼容高并发和故障恢复。
如果需要严格单消费者：
低吞吐场景 → 单活跃消费者（方案2）。
高吞吐场景 → 分布式锁（方案4）。
不要依赖 Direct Exchange 的
routing_key来防重复，它只影响消息进入哪个队列，不影响队列内消息的分发方式。
🚀 关键结论：
RabbitMQ 的 队列（Queue） 是保证消息只被一个消费者消费的关键，而不是 Exchange 类型。正确绑定队列和消费者，配合业务幂等或锁机制，即可避免重复消费。