Redis死锁问题老是遇到，咋才能不被卡住，有啥实用办法解决呢

锁住不放

Redis死锁最常见的原因,说白了就是“锁住不放”，比如你的程序用SETNX命令加了个锁，本来打算操作一下数据就立刻释放，但万一程序运行到一半，突然崩溃了，或者你的服务器网络抽风了，导致释放锁的那行代码根本没执行，这下好了，这把锁就永远留在Redis里了，其他所有想来操作的进程，一看锁还在，全都得干等着，系统就“卡死”了。

解决思路万变不离其宗：想尽办法让锁能自动释放，别让它成为一把“永生锁”。

实用办法一：给锁加个“保质期”（设置过期时间）

这是最基本,也是必须要做的一步，你在加锁的时候，不能只加锁，必须同时给这把锁设置一个过期时间，比如5秒或10秒，这样，就算你的程序崩溃了，顶多过5秒钟，Redis也会自动把锁删除，其他进程就能继续工作了。

在Redis里,现在最推荐的做法是使用一条命令同时完成加锁和设置过期时间，比如用SET key value NX PX 3000（NX表示仅当key不存在时设置，PX 3000表示过期时间是3000毫秒）。这里有个关键点（来源：Redis官方文档建议）：一定要用一条命令！如果你先执行SETNX，再执行EXPIRE，这是两条命令，万一在两命令之间程序崩溃了，过期时间就没设上，死锁还是会发生。

实用办法二：设置合理的过期时间

设置了过期时间就高枕无忧了吗？也不是，你可能会遇到两种新问题：

1. 时间设得太短：你的业务逻辑可能比较复杂，需要操作8秒，但锁的过期时间只设了5秒，结果就是，你的程序还在吭哧吭哧干活呢，锁自己没了，这时候另一个进程趁机加锁成功，然后你的程序执行完了，顺手把别人刚加的锁给删了……这就乱套了。
2. 时间设得太长：如果程序真的挂了，你需要等待很长的时间（比如30秒）锁才释放，这段时间系统的并发能力就大打折扣。

这个过期时间需要你根据平时业务代码的执行时间,留出充足的余量，比如平时操作大概1秒，那你设个5秒或10秒就比较安全。

实用办法三：给锁配上“身份证”（使用唯一值）

上面提到,可能会误删别人的锁，怎么避免呢？办法就是给锁加上标识。

当你加锁时,value不要简单地设为1或true，而是设成一个全局唯一的值，比如UUID，或者用雪花算法生成一个唯一ID，这个值就是这把锁的“身份证”。

当你要释放锁的时候,不能直接删除key，而是要先比一比：用GET命令看看当前锁的value，是不是自己当时设置的那个唯一ID，如果是，说明锁还是自己的，那就执行删除；如果不是，说明锁已经因为过期而被别人拿去了，你就不能删。

注意（来源：Redis官方文档）：获取value和删除key这是两步操作，不是原子的，中间可能有风险，所以更稳妥的做法是使用Lua脚本，把判断和删除的操作打包成一个原子操作，让Redis一次性执行。

实用办法四：用现成的“工具箱”（使用成熟客户端）

上面说的自己设置过期时间、自己管理唯一ID、自己写Lua脚本……听起来就麻烦，而且容易出错，对于大部分常见场景，我们完全没必要重复造轮子。

现在很多流行的Redis客户端,比如Java的Redisson（来源：Redisson开源项目），就内置了非常完善的分布式锁功能，你只需要简单调用一下，它背后帮你实现了：

• 自动续期（看门狗机制）：如果你的业务执行时间比较长，在锁快要过期的时候，它会自动帮你延长过期时间，防止你还在干活锁却没了。
• 可重入：同一个线程可以多次获取同一把锁。
• 各种复杂的锁类型,比如公平锁、读写锁等。

直接用这些成熟的工具,能帮你避开很多坑，是性价比最高的选择。

实用办法五：换个思路（尽量不用锁）

最高级的解决方式,就是不解决——因为压根不用锁，是不是所有场景都非用锁不可呢？有时候可以换个思路。

可以用Redis的原子操作来避免竞争,像INCR（自增）、DECR（自减）、HINCRBY（哈希字段自增）这些命令，都是原子性的，Redis保证执行它们的时候不会被打断，对于一些计数类的场景，用这些原子命令代替“先读后写”的操作，就可以完美避开加锁。

再比如,如果你的业务允许，可以使用消息队列，把并发的请求排成队，一个一个顺序处理，从根源上避免资源竞争。

总结一下

对付Redis死锁,你可以这样一步步来：

1. 底线：加锁必须和设置过期时间一起做，而且要用一条原子命令。
2. 进阶：给锁value设置唯一ID，释放时用Lua脚本核对，防止误删。
3. 省心：直接使用像Redisson这样的成熟客户端，省时省力。
4. 高手：review业务，看看是否能利用原子操作或消息队列，从根本上避免使用锁。

把这些办法结合起来用,Redis死锁基本上就卡不住你了，核心就是别让锁变成“永久”的，并且处理好各种边界情况。