Redis死锁日志到底是怎么冒出来的，背后原因其实挺复杂的分析探讨

Redis死锁日志到底是怎么冒出来的,背后原因挺复杂的，很多人以为Redis是单线程的，不会死锁，但实际情况是，死锁确实会发生，只不过这个“锁”的概念和我们传统多线程编程里的锁不太一样，这里的死锁，通常指的是在应用层面，也就是我们的业务代码里，因为使用Redis分布式锁不当，导致多个客户端（应用服务器）互相等待，业务流程卡住的现象，当你看到日志里某个操作一直超时，或者某个锁迟迟不释放，很可能就是遇到了这种“死锁”。

要搞清楚这个,得先明白大家是怎么用Redis做分布式锁的，最经典的方法就是用SET命令加上NX（不存在才设置）和PX（过期时间）参数，SET lock_key unique_value NX PX 30000，这条命令的意思是，只有当lock_key不存在时，我才去设置它，并且给它30秒的自动过期时间，unique_value是每个客户端生成的唯一标识，用来保证只能由加锁的客户端来解锁。

死锁是怎么一步步冒出来的呢？原因确实比较复杂，往往是好几个因素搅在一起。

第一个核心原因，也是最常见的原因，就是锁过期时间设置得不合理。 想象一个场景：客户端A成功加锁，然后去执行一段业务逻辑，这段逻辑本来预计10秒就能跑完，但因为某些意外，比如查询数据库慢了、调用了外部接口超时、或者是服务器本身CPU负载太高，导致执行了35秒才完事，可是，你设置的锁过期时间只有30秒，这意味着，在第30秒的时候，Redis已经自动把那个锁给删除了，这时，一直等在旁边的客户端B一看锁没了，立马高兴地给自己加上了锁，过了5秒，也就是总时间第35秒，客户端A的业务逻辑终于执行完了，它开始执行解锁的Lua脚本，坏就坏在这里，因为Redis只认unique_value，而客户端A的脚本里用的是自己当初的unique_value，这个脚本依然能执行成功，它会把客户端B刚刚才加上的锁给删掉！这下就乱套了，更可怕的是，如果此时有客户端C也在等待，它可能就会拿到锁，然后客户端B的业务逻辑可能还在执行中，就被客户端C的操作干扰了，整个系统的状态就错了，从日志上看，你会发现锁好像被“提前”释放了，不同客户端的操作交织在一起，报出各种奇怪的超时或数据不一致错误。

第二个原因，是客户端在释放锁之前突然崩溃了。 这看起来和第一个原因结果类似，都是锁没被正确释放，但起因不同，比如客户端A加锁成功，刚开始执行业务逻辑，还没来得及执行解锁命令，它所运行的那台服务器突然宕机了，或者进程被强制杀掉了，这样一来，那个锁就会一直在Redis里躺着，直到过期时间到了才会被清除，在这段“僵尸锁”存续期间，其他所有客户端都无法获得这个锁，业务就会完全卡死，你在日志里看到的将是大量的获取锁失败的超时记录，直到那个锁自然消亡，这种情况虽然不完全是“死锁”，但它造成的现象和死锁一样——流程无法继续进行。

第三个原因，更隐蔽一些，涉及到网络问题。 Redis的客户端和服务器之间是靠网络连接的，可能会发生一种叫做“网络分区”的情况，通俗讲就是网络突然闪断，客户端和Redis服务器失联了，假设客户端A加锁后，网络出现故障，但客户端A本身并没有崩溃，它还在傻傻地执行自己的业务逻辑，而Redis服务器这边，因为长时间收不到客户端A的心跳（如果用了Redis集群），可能会认为客户端A已经挂了，于是它为了数据一致性，可能会把这个锁释放掉（具体行为取决于Redis的配置和版本），这时，另一个客户端B就能成功加锁并操作共享资源，过了一会网络恢复了，客户端A还以为自己牢牢握着锁呢，它执行完逻辑后，还是会去执行解锁操作，这又会错误地释放掉客户端B的锁，这种由网络不确定性引发的锁失效，非常难以排查，从日志的时间线上看会显得非常混乱。

除了这些,还有一些人为失误，有的开发人员在写代码时，忘记了在finally代码块中释放锁，导致一旦业务逻辑抛出异常，锁就永远无法被释放，或者，在解锁时，没有使用Lua脚本来保证“判断锁归属+删除锁”这两个操作的原子性，可能在判断完锁是自己的之后，在执行删除命令之前，锁恰好过期了，结果又误删了别人的锁。

你看,一个简单的Redis分布式锁，背后竟然藏着这么多坑，死锁日志的出现， rarely 是单一因素造成的，它往往是业务逻辑执行时间、锁的超时时间、客户端的稳定性、网络的质量以及代码的严谨性等多个环节串联起来，某个环节一掉链子，问题就暴露出来了，排查的时候，就得像侦探一样，结合日志的时间戳、错误信息、服务器监控和网络状况，一点点还原当时的现场，才能找到那个“冒出来”的真正根源。