Redis怎样实现安全的分布式锁释放-Redis-PHP中文网

正确释放Redis分布式锁必须用Lua脚本原子校验value后再DEL，预加载SCRIPT LOAD+ EVALSHA，配合唯一value、TTL续期及高可用Redis部署。

redis怎样实现安全的分布式锁释放

Redis 分布式锁的核心风险不在加锁，而在释放——如果用 DEL key 直接删，只要锁过期或客户端崩溃，后续任意客户端都能删掉当前持有者的锁，彻底破坏互斥性。

正确做法是：释放前校验锁的 value 是否属于自己。标准方案是用 Lua 脚本原子执行「判断 + 删除」：

if redis.call("GET", KEYS[1]) == ARGV[1] then
  return redis.call("DEL", KEYS[1])
else
  return 0
end

其中 KEYS[1] 是锁名（如 "order:123"），ARGV[1] 是客户端生成的唯一标识（如 UUID 或随机字符串）。

高频调用时反复传输 Lua 脚本会增加网络开销和 Redis 解析负担，还可能触发 maxmemory 策略下的淘汰风险。

生产环境应使用 SCRIPT LOAD 预加载，再用 EVALSHA 执行：

SCRIPT LOAD "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end"

得到 SHA1 值（如 "a1b2c3..."）后，后续释放都用：

EVALSHA a1b2c3... 1 order:123 550e8400-e29b-41d4-a716-446655440000

业务执行时间不确定，而 Redis 锁必须设 TTL（否则宕机不释放），这就导致「锁提前过期」和「业务未结束」的竞态——此时别的客户端可能拿到锁，造成并发写入。

解决方式是：在加锁时启动独立看门狗线程/协程，定期用相同 value 对锁 TTL 做 EXPIRE 延长（注意仍是原子判断：只延长自己持有的锁）。

很多人听说 Redis 单点故障，就直接上 Redlock（向多个独立 Redis 实例加锁），但它的安全模型依赖严格的时间同步和半数以上节点存活，实际部署中 NTP 漂移、GC 暂停、网络分区都会打破假设。

对绝大多数服务，更稳妥的做法是：用单个高可用 Redis（如哨兵或 Cluster），配合合理的锁 TTL、value 校验、续期机制。

锁的安全释放，本质是「身份核验 + 原子操作 + 生命周期管理」三件事。漏掉任何一环，比如只做 value 校验却忘了续期，或者用了 Lua 却没预加载 SHA，问题都会在低概率下突然爆发——而且往往发生在大促或峰值时刻。

Redis怎样实现安全的分布式锁释放