Redlock算法不建议在Redis Cluster等集群模式中使用，因其要求5个独立无复制的主节点，而集群的分片路由、重定向机制和时钟漂移使其无法满足前提；应改用带哈希标签的单slot锁方案。
Redlock 算法在多节点 Redis 集群中**不建议直接应用**，尤其当集群启用 cluster mode（如 Redis Cluster）时，它本质上无法按设计运行。
Redlock 的前提与集群现实严重冲突
Redlock 要求向「5 个完全独立、无复制关系、时钟基本同步」的主节点并发发锁请求。但真实 Redis 集群中：
- 节点间存在自动分片和重定向机制（MOVED/ASK），客户端无法绕过集群路由直连指定主节点
- 所有写操作由 key 的 slot 决定路由，你无法保证同一把锁被发往多个不同节点——更可能被全部打到同一个主节点上
- 集群模式下不存在“5 个独立实例”的拓扑；所谓“5 节点集群”实际是 5 个分片（shard），每个分片含主从，不是 Redlock 所需的并列主节点
强行在集群上用 Redlock 的典型问题
若忽略上述约束硬套 Redlock 流程（比如用 Redisson 的 RedissonRedLock 连接集群地址），会出现：
- 锁分散失效：不同客户端对同一资源加锁，因 key hash 到不同 slot，锁被写入不同节点，互斥性彻底丢失
- 多数派计算失真：客户端以为向 5 个节点发了请求，实际请求被集群代理转发或重定向，真正响应的可能只有 1–2 个节点
- 时钟漂移不可控：虚拟机暂停、容器调度、NTP 调整常导致节点间时间差超 50ms，而 Redlock 安全模型要求该偏差远小于此
集群环境下真正可行的锁方案
放弃 Redlock，改用符合集群语义的单点强一致性锁：
-
强制 key 落在同一 slot：用大括号包裹资源标识，例如
lock:{order:12345}或lock:{global_inventory}，确保所有同类锁命中同一个主节点 -
单实例原子加锁：在该 slot 所在的主节点上执行
SET lock:key uuid NX PX 30000，NX+PX 保证原子性与防死锁 -
Lua 脚本安全解锁：使用如下脚本，仅当 value 匹配才删锁，避免误删他人锁：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end - 依赖高可用而非多节点冗余：只要该 slot 对应的主节点有哨兵或 Cluster 自动故障转移保障，锁服务就足够可靠
什么场景才考虑 Redlock？
仅当满足全部以下条件时可谨慎评估：
- 你手动部署并维护 5 个完全独立的 Redis 主实例（无任何复制、无集群协议、无代理）
- 各节点物理隔离（跨机房）、时钟由高精度 NTP 同步且 drift 持续
- 业务能接受锁有效时间 = 原设定 TTL − 获取锁总耗时，且该剩余时间可能极短甚至为负
- 已充分测试网络抖动、节点瞬断等边界情况下的锁误判率
