【Redis】【Redis分布式锁】Redis锁的超时时间问题

前言

Redis分布式锁的实现相对来说简单、高效，在并发量很高，且不追求锁的强一致性的一些实际业务场景中，被广发的使用。

在使用过程中，redis分布式锁往往也伴随着很多坑，今天我们围绕着非原子操作、锁超时问题展开来聊一聊，给需要的同学一些参考。

使用Redis分布式锁，我们首先想到的可能是setNx命令

if (this.setNX(lockKey, val) == 1) {
   //TODO
}

加锁操作很简单。加锁之后我们面临的问题就是锁释放，或者说解锁。

这里的解锁操作，有如下两个方案，也都存在各自的问题：

如图： 1.通过del进行锁释放时，是存在死锁问题的，这个时候我的方案是，在锁是否超时的判断上采用超时时间作为value的方案，这样能够避免死锁

2.设置锁超时：

if (this.setNX(lockKey, val) == 1) {
   this.expire(lockkey,timeout);
}

从上述代码可以看到，非原子操作是会带来死锁问题的。

使用set命令加锁并设置锁过期时间

同时，我们可以使用set命令直接设置锁过期时间：

如图所述，这里存在的两个问题： 1.设置过期时间，在实际应用场景中，超时时间的粒度不好把控，且容易出现问题。

2.del操作，能够最终解决，但是比较复杂。

锁续期-针对锁超时时间的问题解决：

针对我们给锁设置的超时时间不合理，过期时间太短，业务还没执行完成，锁就过期了，这种问题，

我们可以考虑引入redssion，它能给 Redis 分布式锁实现过期时间自动续期。

redisson 如何实现过期时间自动续期？

redisson加锁成功后，会单独创建一个线程来监视这个锁。

假设我们锁的过期时间是3s，这个线程在1s的时候就会查看当前的锁是否释放，如果没有释放，将过期时间再次设置成3s。

总结

针对我们不同的实现方案，对应的redis锁有的一些问题，我们进行了梳理，希望给需要的同学能够带来点启发，对应也列举了几个解决方案。

一般在简单的场景里，我会直接选择第一种解决方案：