rabbitmq 不提供原生分布式锁能力，其设计定位是消息路由与异步协调，而非强互斥控制；它缺乏cas操作和租约机制，常见“锁实现”易出错且违背本质用途。
直接说结论：RabbitMQ 本身不提供原生分布式锁能力，用它“实现”分布式锁本质是绕路设计，容易出错且违背其核心定位——它适合做任务分发与异步协调，不适合做强互斥控制。
为什么 RabbitMQ 不该被当作分布式锁的底层
RabbitMQ 的 Exchange/Queue/Binding 机制面向消息路由，没有原子性 CAS（compare-and-swap）操作，也没有租约（lease）超时自动释放语义。你无法靠 queue.declare 或 exchange.bind 等调用来保证“仅一个消费者能成功声明某资源”。常见错误包括：
- 误以为创建同名 queue 失败 = 锁已被占用 —— 实际上 RabbitMQ 允许多个连接同时
queue.declare同一个 durable queue，不会报错 - 用消息投递 + 消费者 ack 当锁 —— 但消费者 crash 后消息会重回队列，其他消费者立刻可取，无法保障互斥窗口
- 依赖 TTL + DLX 做“过期锁” —— TTL 是消息级的，不是锁状态级的；无法表达“锁持有中，且还有 30 秒有效期”这样的状态
Go 中真正可行的 RabbitMQ 协同方案：用消息驱动锁生命周期
与其强行把 RabbitMQ 当锁服务，不如让它当“锁事件广播器”。真正的锁由 Redis 或 etcd 管理，RabbitMQ 负责通知锁变更、触发重试或清理。例如：
- 业务节点获取
redis.NewMutex("order:123")成功后，向 RabbitMQ 的lock.acquiredexchange 发送一条消息，含锁 ID 和持有者 ID - 其他节点订阅该 exchange，收到消息后主动放弃本地竞争逻辑，或转入等待状态
- 锁释放时（正常 unlock 或租约过期），同样发一条
lock.released消息，唤醒等待队列中的协程 - 关键点：
amqp.Publishing.DeliveryMode = 2（持久化）、mandatory = true（确保路由失败可捕获）、消费端必须手动d.Ack()防止消息堆积
Go + RabbitMQ 实现任务同步的推荐路径
如果你的真实目标是“多个 worker 同步执行同一类任务，避免重复处理”，那应该放弃“锁”这个抽象，改用 RabbitMQ 原生语义：
- 所有任务统一发往一个
task.queue，设置durable = true和autoAck = false - 每个 worker 启动时声明自己专属的 consumer tag，并在
ch.Qos(1, 0, false)下严格控制预取数为 1 —— 这才是 RabbitMQ 对“一次只处理一个”的可靠保障 - 任务消息体里带唯一
task_id字段，worker 处理前先查 Redis：SETNX lock:task_id ${worker_id} EX 300；失败则nack(requeue=true)让消息稍后重试 - 不要在 RabbitMQ 层做去重（比如用
x-message-ttl配合死信），而要在业务层用幂等 key（如idempotency_key）+ DB 唯一索引兜底
最常被忽略的一点：RabbitMQ 的 connection/channel 生命周期和锁的租期必须解耦。worker 拿到锁后宕机，Redis 里的 key 会因 TTL 自动清除；但 RabbitMQ channel 若未关闭，对应 unacked 消息会在 reconnect 后重新投递 —— 这两个时间轴不能混为一谈。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
