【Redis】分布式锁-redission

最新推荐文章于 2024-09-21 23:42:27 发布

洛上言

最新推荐文章于 2024-09-21 23:42:27 发布

阅读量1k

点赞数 14

分类专栏： # Redis 文章标签： redis 分布式数据库

本文链接：https://blog.csdn.net/qq_39921135/article/details/140988294

版权

Redis 专栏收录该内容

58 篇文章 1 订阅

订阅专栏

我们一路走来，利用添加过期时间，防止死锁问题的发生，但是有了过期时间之后，可能出现误删别人锁的问题，这个问题我们开始是利用删之前通过拿锁，比锁，删锁这个逻辑来解决的，也就是删之前判断一下当前这把锁是否是属于自己的，但是现在还有原子性问题，也就是我们没法保证拿锁比锁删锁是一个原子性的动作，最后通过lua表达式来解决这个问题

但是目前还剩下一个问题锁不住，什么是锁不住呢，你想一想，如果当过期时间到了之后，我们可以给他续期一下，比如续个30s，就好像是网吧上网，网费到了之后，然后说，来，网管，再给我来10块的，是不是后边的问题都不会发生了，那么续期问题怎么解决呢，可以依赖于我们接下来要学习redission啦

一、基于setnx实现的分布式锁存在的问题

基于setnx实现的分布式锁存在下面的问题：

重入问题：在JDK中就有一个可重入锁的说法 ReentrantLock，重入问题是指获得锁的线程可以再次进入到相同的锁的代码块中，例如有一个方法A去调用方法B，在方法A中要先去获取锁，然后执行业务去调用方法B，而B又要去获取同一把锁，在这种情况下，如果你的锁是不可重入的，那我在方法A中获取了锁，等我去调方法B的时候，它又想获取这把锁显然是无法获取的。那么此时它就回去等待我们锁的释放，而锁又无法释放，因为方法A还没有执行完，它在调B，于是就会出现死锁的情况了，因此在这种场景下我们其实是要求锁是可重入的。

可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。

不可重试：我们之前实现的锁是一种非阻塞式，我们尝试去获取锁，如果失败会立即返回false，没有重试机制。但是在很多业务下不能立即失败，我们希望的是获取锁的时候如果被别人占用了，我等一等再试，如果最后成功了，那我再去执行业务。

因此在有些业务下我们希望这个锁是阻塞的，或者是可重试的。

**超时释放：**虽然我们之前利用判断锁标识、Lua脚本来去解决了因为超时释放导致的误删问题，但是这种超时的情况还是有可能发生的，虽然不会导致误删，但是也有可能会导致一些其他的隐患发生，所以这个超时问题我们还是要想办法去解决。

如果这个时间你设置的太短，我的业务还没有执行完呢，锁就释放了，这样一来等于我的业务执行过程中其他人也有可能来执行业务，这是一个风险。

但如果你设置的太长，将来我出现故障后，很长一段时间大家都在等待锁自动释放，这样锁的阻塞周期就过长了。

所以这是一个矛盾，我们也要去解决。

我们在加锁时增加了过期时间，这样的我们可以防止死锁，但是如果卡顿的时间超长，虽然我们采用了lua表达式防止删锁的时候，误删别人的锁，但是毕竟没有锁住，有安全隐患

主从一致性： 主从模式你也可以理解成读写分离模式，也就是说redis会有一个主节点和多个从节点，但我们去执行写操作的时候，我们去访问主节点，当我们执行的是读操作的时候，我们去访问从节点。当然主节点需要把自己的数据同步给所有从节点，保证主和从的数据是一致的，这样我们就可以在多个节点上去完成读的操作，提高整个服务的并发能力和高可用性。

而且主机宕机了，我们还可以从从节点中选出一个新的主，这样整个集群的可用性就更强了。

但是主从之间的数据同步是有延迟的，因此在极端情况下可能发生这样一种情况：现在我们有一个线程在主节点获取了锁，因为获取锁是set操作，它是一个写操作，那么这个写操作在主节点完成了，因为存在延迟，假如尚未同步给从节点的时候，突然间主节点就宕机了，此时我们会选一个新的从作为主，而这个从节点上因为没有完成同步，因此它是没有锁标识的，也就是说此时其他线程可以乘虚而入拿到锁，这个时候其实就等于有多个线程拿到锁了，因此可能会在这种极端的情况下出现安全问题，当然它出现的概率比较低，因为主从同步的延迟往往是极低的，它往往可以在毫秒级别甚至更低。

1653546070602