当前位置：首页 > 问答 > 正文

Redis锁怎么快速清理，别犹豫了，这招真管用，解决死锁烦恼

太叔访天
问答
2025-12-27 03:09:29
2

一个用了Redis锁的程序,突然卡死了或者崩溃了，导致它占着的锁一直没有释放，其他程序过来一看，锁还在，就只能干等着，整个系统可能就堵在那儿了，这就是烦人的死锁，这时候你可能第一反应是，“我去Redis里找到那个锁的key，直接把它删掉不就完了？” 这招儿应急可以，但绝对是下下策，因为它会带来新问题，你刚删完，原来那个持有锁的程序万一又“活”过来了，它还以为锁还在自己手里，会继续执行一些危险操作，而此时另一个程序因为锁被你删了，也拿到了锁，两边一冲突，数据就可能乱套了。

清理死锁的关键不是“删”，而是“安全地过期”，下面这招真管用的方法，其核心思想在很多技术讨论中都有体现，比如在开发者社区和博客中常被提及的“设置锁的超时时间”是基本共识。

第一招：基本功必须扎实——给锁设置一个合理的过期时间

这是预防死锁最简单、最有效的一道防线，当你用SET命令加锁时，一定要加上PX或EX参数，给锁一个“寿命”。

在Redis中,你别再用老的SETNX命令了，而是用这个标准命令：

SET lock_key unique_value NX PX 30000

解释一下：

Redis锁怎么快速清理，别犹豫了，这招真管用，解决死锁烦恼

lock_key：就是锁的名字。
unique_value：必须是一个全局唯一的字符串，比如可以用UUID。这个非常重要，它是你安全释放锁的凭证。
NX：表示“只有当这个key不存在时才能设置成功”，也就是抢锁。
PX 30000：表示这个key的存活时间是30000毫秒（30秒）。

这么做的意思是,无论抢到锁的程序后来是正常完成还是意外崩溃，最多30秒后，这个锁都会被Redis自动删除（也就是过期释放），其他程序最多等30秒就能重新来抢，死锁自然就解决了，这一步是根基，如果连这个都没做，那后面都是空谈。

第二招：核心技巧——用脚本自动清理“僵尸锁”

尽管设置了过期时间,但有时候我们可能设得太长（比如为了一个很耗时的任务），还是希望能主动清理那些“占着茅坑不拉屎”的僵尸锁，这时候，不能直接用DEL命令，而是要用Lua脚本。

这个方法是这样的：你写一个脚本，这个脚本的逻辑是“只有当我提供的值匹配锁里存的值时，才删除这个锁”，因为Lua脚本在Redis里是原子性执行的，所以不会出现判断了值之后、删除之前又被其他操作插进来的情况。

Redis锁怎么快速清理，别犹豫了，这招真管用，解决死锁烦恼

清理锁的Lua脚本大致长这样：

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

你怎么用呢？

你得知道那个死锁的key名字（lock_key）。
你更得知道当初设置锁时用的那个唯一的unique_value，这就是为什么强调锁的值必须唯一且要记录下来。

通过Redis客户端执行这个脚本,把key和value作为参数传进去，如果值匹配，锁就被安全地删除了；如果值不匹配（比如锁已经因为超时被系统自动删了，或者被真正的持有者释放了），那脚本什么也不会做，绝对安全。

第三招：治本之策——建立锁的监控和自动巡检机制

Redis锁怎么快速清理，别犹豫了，这招真管用，解决死锁烦恼

上面两招是手动或半自动的,要想真正高枕无忧，就得让系统自动化起来，这思路在一些运维和SRE的实践中很常见。

你可以写一个简单的定时任务（比如Cron Job），让它定期扫描Redis中所有带有特定前缀的key（比如所有以lock:开头的key）。

扫描到之后,不是粗暴地删除，而是这样做：

检查这些key的剩余生存时间（TTL）。
如果发现某个锁的TTL还剩很长（比如你设置的是10分钟，现在才过了1分钟，还剩9分钟），但通过外部检查（比如去数据库里查一下、或者调用一个健康检查接口）发现持有锁的那个服务实例早已经挂掉了。
你的巡检程序就可以安全地执行上面第二招里的Lua脚本,传入正确的unique_value（这个值你需要有地方存储和关联，比如存在一个公共配置中心或者数据库里），把这个“僵尸锁”清理掉。

这套机制相当于给Redis锁请了一个24小时不休息的保安,它能智能地判断哪个锁是坏掉的，然后按照安全流程把它处理掉，从根本上避免了死锁积累导致系统瘫痪。

别再想着直接登录Redis用DEL命令了，那太危险。