SETNX不能单独用作分布式锁，因其无法原子性地设置值和过期时间，易导致死锁；必须用SET key value NX EX seconds原子命令，并配合唯一value和Lua脚本校验解锁。
SETNX 为什么不能单独用作分布式锁
因为 SETNX 只能判断 key 是否存在并设置，不支持原子性地设置值 + 过期时间。如果先执行 SETNX 成功，再调用 EXPIRE，中间进程崩溃或网络中断，就会留下一个永不过期的锁，导致死锁。
常见错误现象：SETNX 返回 1（加锁成功），但后续 EXPIRE 没执行，锁永远卡住；多个客户端反复抢锁失败却查不到谁持有锁。
- 必须用
SET命令的NX+EX组合替代SETNX+EXPIRE - Redis 2.6.12+ 才支持
SET key value NX EX seconds这种原子写法 - value 必须是唯一标识（比如 UUID 或 client ID），否则解锁时无法验证所有权
解锁时为什么不能直接 DEL key
直接 DEL 会删掉别人持有的锁。比如 A 加锁后处理超时，锁自动过期；B 获得锁开始执行；A 结束后仍执行 DEL，把 B 的锁删了——这是典型的误删。
使用场景：任何需要安全释放锁的业务逻辑，尤其是耗时不确定的服务（如支付回调、文件处理）。
- 解锁必须用 Lua 脚本保证“校验 value + 删除”原子执行
- 脚本内容类似：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end - 客户端传入的
ARGV[1]必须和加锁时的 value 完全一致（建议用UUID.randomUUID().toString()）
Redis 单点故障对锁可靠性的影响
用单台 Redis 实例实现分布式锁，一旦它宕机，所有锁状态丢失，可能引发重复执行或数据错乱。这不是“锁没生效”，而是“锁系统不可用”。
性能 / 兼容性影响：Redis Cluster 或哨兵模式下，SET ... NX EX 在跨 slot 时可能失败；Lua 脚本在集群中必须确保 key 在同一 slot（可用 {xxx} 包裹 key 名强制路由）。
- 生产环境别指望单节点 Redis 提供强一致性锁
- Redlock 算法理论上更安全，但实际落地复杂、延迟高、多数业务并不需要那幺半毫秒级的严谨
- 更务实的做法：接受小概率失效，配合幂等设计（比如用唯一订单号 + 数据库唯一索引兜底）
Java 客户端用 Jedis/Lettuce 写锁要注意什么
很多封装库（比如老版本 Redisson）默认用 SETNX + EXPIRE，表面看没问题，压测一高就暴露问题。关键不在“有没有锁”，而在“锁是否可重入、可续期、可安全释放”。
参数差异：SET key value NX EX 30 中的 30 是秒级过期，但业务执行时间可能波动。设太短容易误释放，太长又拖慢故障恢复。
- 过期时间建议设为「平均执行时间 × 3」，并记录日志监控超时率
- Jedis 示例：
jedis.set(key, value, "NX", "EX", 30)—— 注意参数顺序，旧版 Jedis 不支持该重载 - Lettuce 推荐用
StatefulRedisConnection.sync().set(key, value, SetArgs.Builder.nx().ex(30))
真正难的不是写对一行 SET，而是让加锁、续期、解锁、异常清理整套逻辑在各种网络分区、GC 暂停、机器重启下依然不越界。这些边界情况，文档里通常不写，但线上会咬人。
