正确实现分布式锁需用set命令的nx和ex选项原子加锁并设超时，解锁须通过lua脚本校验value唯一标识后删除，续期也需lua原子比对持有权，禁用非原子的setnx+expire或无校验的del。
直接用 SETNX 命令实现分布式锁看似简单，但若不处理超时、误删、原子性等关键问题，极易引发死锁或并发冲突。正确做法不是单独调用 SETNX，而是将其与过期时间、唯一标识、原子校验组合使用，形成具备互斥性、防死锁、可验证性的锁机制。
加锁必须带超时，且一步完成
不能分两步执行 SETNX key value 再执行 EXPIRE key seconds —— 这两者非原子操作，中间若服务崩溃或网络中断，会导致锁无超时，变成永久死锁。
正确方式是：用 SET 命令的 NX 和 EX（或 PX）选项一次性完成加锁+设过期：
-
SET lock:order:123 "8f4a2b9c" NX EX 30—— 表示只有键不存在时才设置值，并自动设置 30 秒过期 - 返回
OK表示加锁成功；返回(nil)表示锁已被占用 - 该命令等价于
SETNX + EXPIRE的原子组合，从 Redis 2.6.12 起支持
解锁必须验证持有权，防止误删
直接 DEL lock:order:123 是危险的：若线程 A 拿到锁后执行超时，锁自动过期，线程 B 成功加锁；此时 A 执行完再删锁，实际删掉的是 B 的锁。
解决方案：加锁时 value 使用唯一标识（如 UUID），解锁前先检查 value 是否匹配，再删除——整个过程需用 Lua 脚本保证原子性：
- 加锁：
SET lock:order:123 "a1b2c3d4" NX EX 30 - 解锁脚本（推荐）：
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end - 调用：
EVAL ... 1 lock:order:123 a1b2c3d4
避免“锁续期”场景下的竞争漏洞
当业务执行时间可能超过锁过期时间（如长事务、外部调用延迟），需支持自动续期（renew）。但不能由客户端随意延长 TTL，否则可能破坏互斥性。
安全续期的前提是：仅当前锁持有者可更新过期时间，且更新动作本身需原子判断：
- 用 Lua 脚本读取当前 value，比对是否为本客户端标识
- 若匹配，执行
EXPIRE；否则拒绝续期 - 典型脚本：if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("expire", KEYS[1], ARGV[2]) else return 0 end
不推荐纯 SETNX 循环重试的原始写法
像下面这种轮询式实现虽能工作，但存在明显缺陷：
while not redis.setnx("lock", "1"): time.sleep(0.01)- 无超时控制 → 可能无限等待
- 无持有标识 → 解锁无法验证归属
- 高并发下大量失败请求冲击 Redis，增加延迟和连接压力
现代实践应优先采用 SET ... NX EX + Lua 安全解锁组合，兼顾简洁性、安全性与可观测性。
