如何使用Redis Lua脚本实现分布式锁以避免死锁？-Redis-PHP中文网

直接用setnx+expire会出问题，因为二者非原子：若setnx成功后进程崩溃或网络中断，expire未执行，锁将永久存在导致死锁；必须用lua脚本（如eval）将加锁与设过期合并为原子操作，并通过唯一value校验防止误删。

如何使用redis lua脚本实现分布式锁以避免死锁？

为什么直接用 `SETNX` + `EXPIRE` 会出问题？

因为这两条命令不是原子的：如果客户端执行 SETNX 成功，但网络中断或进程崩溃导致 EXPIRE 没发出去，锁就永远卡住——这就是典型死锁源头。Redis 2.6+ 支持 Lua 脚本原子执行，必须用它把“加锁 + 设过期”合并成一步。

`EVAL` 脚本里怎么安全加锁？

核心是用 redis.call('set', key, val, 'NX', 'PX', expire_ms)，其中 NX 保证只在 key 不存在时设置，PX 直接指定毫秒级过期时间，整个操作由 Redis 单线程完成，天然原子。

key 建议带业务前缀，比如 "lock:order:123"
val 必须是唯一标识（如 UUID 或 client_id + thread_id），不能硬编码字符串，否则解锁时无法验证所有权
expire_ms 别设太短（低于业务最大耗时）或太长（影响故障恢复），一般取 3–10 倍预估执行时间

解锁时为什么不能只用 `DEL`？

直接 DEL lock:key 会删掉别人持有的锁——只要你的客户端误删了其他人的锁，分布式系统就可能并发写坏数据。正确做法是 Lua 脚本先查 value 是否匹配，再删：

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

if redis.call('get', KEYS[1]) == ARGV[1] then
  return redis.call('del', KEYS[1])
else
  return 0
end

这个脚本必须用 EVAL 执行，且传入的 ARGV[1] 是加锁时生成的唯一 value。

超时重入和锁续期怎么处理？

Redis 锁本身不支持重入，Lua 脚本也没法判断“当前客户端是否已持锁”。真需要重入，得自己维护一个计数器（比如用哈希存 client_id → count），但会显著增加复杂度。更实际的做法是：业务层避免嵌套加锁；对长任务，用独立线程定期调用 GET + SET（带 XX 和新 PX）来刷新过期时间——注意刷新也得校验 value，否则变成“帮别人续期”。

真正容易被忽略的是锁释放时机：必须在 try/catch finally 里确保解锁逻辑执行，哪怕业务异常也要触发 Lua 解锁脚本；另外网络超时可能导致 EVAL 结果未返回，此时需结合本地超时 + 冗余解锁机制（比如最多重试 2 次），但别无脑重试——重复解锁本身不危险，重复加锁才致命。