setnx不能直接当分布式锁用，因其无过期机制易致死锁、无法校验锁持有者、释放不具原子性；应改用set key value ex seconds nx命令加锁，并配合lua脚本原子化释放。
为什么 SETNX 不能直接当分布式锁用
SETNX 确实能实现“键不存在才设值”，看起来像加锁，但实际会立刻掉进三个坑：锁没过期时间（服务宕机就死锁）、没校验持有者身份（别人能随便解锁）、没原子性释放（DEL 前锁已过期，删错别人的锁）。这些不是边缘情况，而是高并发下必现的问题。
用 SET key value EX seconds NX 替代 SETNX
Redis 2.6.12+ 支持带条件和过期时间的原子写入，这才是安全加锁的起点。必须同时满足：NX（仅当 key 不存在）、EX（秒级过期）、value 是唯一请求标识（比如 UUID 或线程 ID）。
示例命令：
SET lock:order:123 "8f4b5a2e-1c9d-4b0f-9a1e-3d7c8b4a5f21" EX 30 NX
返回 OK 表示抢锁成功；返回 (nil) 表示锁已被占用。
- 绝对不要分开执行
SETNX+EXPIRE—— 中间崩溃会导致无过期锁 - value 必须全局唯一，否则释放逻辑无法区分所有权
- 过期时间要明显大于业务最大耗时，但也不能设成几小时——权衡点通常在 10–60 秒
怎么安全地释放锁：Lua 脚本是唯一靠谱方案
释放锁的本质是：「只有 value 匹配的客户端才能删 key」。这必须在一个原子操作里完成，否则 GET 判断 + DEL 删除之间存在竞态窗口。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
用 Lua 脚本封装判断和删除：
EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock:order:123 "8f4b5a2e-1c9d-4b0f-9a1e-3d7c8b4a5f21"
脚本返回 1 表示成功释放；0 表示锁已不属于当前客户端（可能已过期、被别人覆盖或根本没拿到锁）。
- 别用客户端先
GET再DEL—— 这是经典误用，几乎所有手写分布式锁 bug 都出在这步 - 确保 Lua 脚本中比较的是字符串全等（
==），不是模糊匹配 - 如果 Redis 是集群模式，KEYS[1] 对应的 key 必须落在同一个 slot，否则
EVAL会报错
锁自动续期（可选）和超时误释放的现实取舍
业务执行时间不确定时，单纯靠预设过期时间容易导致「锁过期但业务还在跑」，引发重复执行。这时候需要看守线程（watchdog）定期用相同 value 续期：SET lock:xxx value EX 30 XX（XX 表示仅更新已存在 key 的过期时间）。
但要注意：
- 续期操作本身也有失败可能（网络抖动、Redis 拒绝响应），不能假设它 100% 可靠
- 如果业务执行远超预期（比如卡死），续期反而延长了问题暴露时间
- 很多简单场景其实不需要续期——宁可让锁过期后重试，也比锁长期滞留更可控
真正难处理的不是加锁或释放，而是「锁失效边界」：你永远没法 100% 确保业务结束和锁释放严格同步。设计时得接受这个事实，并在业务层做幂等兜底。
