思考
可以保证消费不被重复消费，因为通过轮询一个消息只会投递给一个消费者。
但是不是一个消费者消费，而是多个轮询消费
在 RabbitMQ 中，如果多个消费者（Consumers）同时订阅 同一个队列（Queue），并且这个队列是通过 Direct Exchange 绑定的（使用相同的 routing_key），那么默认情况下 不能保证只有一个消费者消费，而是会按照 轮询（Round-Robin） 的方式分发给多个消费者。
1. 默认行为（多个消费者订阅同一个队列）
场景描述
Direct Exchange 绑定了 1 个队列（Queue），并指定了
routing_key（如payment.success）。多个消费者 同时订阅这个队列。
消息分发方式
✅ 轮询（Round-Robin）：
RabbitMQ 会 依次 将消息分发给不同的消费者，不会保证唯一消费。
例如：
Consumer1收到消息1、消息3、消息5...Consumer2收到消息2、消息4、消息6...
代码示例
python
# 生产者发送消息到 Direct Exchange
channel.basic_publish(
exchange="direct_exchange",
routing_key="payment.success", # 匹配绑定的队列
body="Order123 paid"
)
# 多个消费者订阅同一个队列
channel.basic_consume(queue="payment_queue", on_message_callback=consumer1)
channel.basic_consume(queue="payment_queue", on_message_callback=consumer2)
结果：消息会被 consumer1 和 consumer2 轮流消费，而不是仅由一个消费者处理。
2. 如何确保只有一个消费者消费？
如果你希望 同一消息只被一个消费者处理，有以下几种方案：
方案 1：单队列 + 单消费者
只启动 1 个消费者，其他消费者不订阅该队列。
缺点：无法扩展，吞吐量低。
方案 2：RabbitMQ 单活跃消费者（Single Active Consumer）
RabbitMQ 3.8+ 支持 单活跃消费者 模式：
python
channel.queue_declare( queue="payment_queue", arguments={"x-single-active-consumer": True} # 启用单活跃消费者 )行为：
多个消费者可以注册，但 只有第一个注册的消费者能接收消息。
如果该消费者断开，RabbitMQ 会自动切换到下一个消费者。
优点：
无需额外组件（如 Redis 锁）。
自动故障转移。
缺点：
仍然不能并行处理消息。
方案 3：业务幂等性（推荐）
允许消息被多个消费者消费，但业务逻辑保证 重复消费不影响结果（如数据库唯一约束、乐观锁）。
优点：
高可用，可扩展多个消费者。
缺点：
业务逻辑需要支持幂等。
方案 4：分布式锁（Redis / DB 锁）
消费者处理消息前先获取锁：
python
def callback(message): lock_key = f"lock:{message.body.order_id}" if redis.set(lock_key, "1", nx=True, ex=60): # 加锁 process_payment(message) redis.delete(lock_key) # 释放锁 else: channel.reject(message.delivery_tag, requeue=True) # 重新入队优点：
严格保证唯一消费。
缺点：
依赖外部存储（Redis/DB）。
锁超时时间需合理设置。
3. 总结
| 方案 | 适用场景 | 是否严格唯一消费 | 扩展性 |
|---|---|---|---|
| 单队列 + 单消费者 | 低吞吐场景 | ✅ 是 | ❌ 差 |
| 单活跃消费者（RabbitMQ 3.8+） | 需要自动故障转移 | ✅ 是 | ❌ 差 |
| 业务幂等性 | 高并发场景 | ❌ 否（但业务层防重） | ✅ 好 |
| 分布式锁 | 严格一致性 | ✅ 是 | ⚠️ 中等 |
推荐：
如果业务允许，优先采用 幂等性（方案 3）。
如果需要严格单消费者，使用 单活跃消费者（方案 2）或 分布式锁（方案 4）。
关键结论
🚨 Direct Exchange + 相同 routing_key + 相同队列 + 多个消费者 = 消息轮询分发（不保证唯一消费）
如果业务需要 严格单消费者，必须额外控制（如单活跃消费者或分布式锁）