Redis集群无法用单key SETNX实现可靠分布式锁，因其按slot分片导致跨节点操作不原子、多key命令报CROSSSLOT错误、Redlock不适用，唯一可行方案是单key+Lua+UUID校验并严格客户端超时控制。
Redis集群本身不保证跨节点原子性，直接用 SET + EXPIRE 或单个 EVAL 脚本在集群模式下大概率失效——锁可能只落在某个分片上，而其他节点无法感知，导致多个客户端同时持锁。
为什么 Redis Cluster 不能直接用单 key SETNX 实现可靠分布式锁
Redis Cluster 按 slot 分片，key 被哈希到不同节点。当你执行 SET key value NX PX 30000，这个操作只作用于一个节点；但锁的「存在性判断」和「释放验证」若涉及其他 key（比如计数器、租约心跳），就可能跨节点失败。更关键的是：DEL 或 EVAL 脚本无法原子操作多个 slot 上的 key，集群会直接报错 CROSSSLOT Keys in request don't hash to the same slot。
- 所有锁相关操作（加锁、续期、解锁）必须落在同一个 slot —— 也就是必须用 hash tag，例如把锁 key 写成
lock:{order_123}，让{...}内容决定 slot - 集群不支持 multi-key 原子命令（如
MGET多个不同 slot 的 key），所以基于「锁 key + 计数器 key + 时间戳 key」的多 key 设计在 Cluster 下天然不可行 - Redlock 算法在 Cluster 中也不适用：它要求向 N 个独立 Redis 实例发请求，而 Cluster 是逻辑统一、物理分片的“一个实例”，不是 N 个可独立寻址的 server
在 Cluster 模式下安全加锁的唯一可行路径：单 key + Lua + UUID 校验
放弃可重入、放弃计数器、放弃跨 key 协同，只保留最简但安全的语义：「谁加的锁，谁才能解，且带自动过期」。核心是把全部逻辑压进一个 key 和一个 Lua 脚本里。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 加锁必须用
EVAL执行原子脚本，内容类似：if redis.call("set", KEYS[1], ARGV[1], "NX", "PX", ARGV[2]) == "OK" then return 1 else return 0 end - 解锁也必须用
EVAL，且严格校验 value：if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end - value 必须是客户端生成的全局唯一标识（如
UUID.randomUUID().toString()），不能是固定字符串或进程 ID - key 必须带 hash tag，例如
lock:{payment_456}，确保整个锁生命周期都在同一 slot 节点上
防死锁的关键不在锁本身，而在客户端超时与重试策略
Cluster 下没有真正的“锁服务”，只有「带过期时间的 key 占位」。死锁实际来自业务线程卡住不释放，而非 Redis 层面循环等待。因此防死锁重点是控制客户端行为：
- 加锁时设置的
PX时间，必须明显大于最长预期业务耗时（建议至少 3 倍），否则锁提前过期引发误删 - 绝不使用无限重试：每次失败后应指数退避（如 10ms → 30ms → 100ms），并设总超时上限（如 5 秒），超时即放弃，避免雪崩式请求打满集群
- 业务代码必须放在 try-finally 或 defer 中强制解锁，即使 panic/exception 也要触发，否则依赖 TTL 是最后一道防线，不是设计原则
- 禁止在锁内做网络 I/O 或长阻塞操作——这会让锁持有时间不可控，直接破坏 TTL 设计前提
真正容易被忽略的点是：Cluster 模式下，你根本没法实现 Redlock 或可重入锁。所谓“正确使用”，本质是接受它的约束——用最简原子操作 + 严格客户端纪律，换取可用性。任何试图在 Cluster 里模拟单机锁语义的封装，最终都会在 failover 或 slot 迁移时露出破绽。
