redis分布式锁解决可重入 redis分布式锁释放问题

大家好，如果您还对redis分布式锁解决可重入不太了解，没有关系，今天就由本站为大家分享redis分布式锁解决可重入的知识，包括redis分布式锁释放问题的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！

redissession分布式锁原理

redission为redis官网发布的分布式解决方案，redission中包含了我们了解的常用锁的类型，基本的可重入锁，读写锁，以及CountDownLatch的设置及使用，但是他们是分布式锁，以往我们JUC提供的锁都是在单线程的线程模型中使用的，当多个进程多个线程来操作一个无锁的共享资源的时候，就会出现线程不安全的问题，就是我们多次执行后结果和单个线程执行时结果的不一致，为了让线程一致我们是需要一些处理办法的，那就是分布式锁，通过锁进行多线程的同步来进行资源隔离来实现对资源的访问控制，从而达到线程安全

如何使用RedLock实现分布式锁

红锁（RedLock）是用于分布式网络系统中的一种操作控制机制，即分布式锁。它解决的问题是在多个主机的系统里，保证用户的写操作的安全性，一致性和高效性。

在分布式网络中，操作的一致性和高效性是矛盾的，为什么呢？“高效”是指在单位时间里完成的并发操作越多越好，越快越好；而“一致”是指在网络中某个特定数据在各个主机中的值是相同的，当一个用户访问时不会出现在一个主机上是旧值，在另一主机上是新值的情况。为了数据“一致”，在一个用户更新某个数据时，其他的用户请求必须等待前面的用户在全部主机上完成操作后才可以访问，否则就可能出现访问结果不一致的情况。这种等待的时间越长，自然系统的效率就越低。如果缩短等待时间，效率会提高，但是有可能上一个用户还没有完成全部操作，数据就出现不一致。所以，一致性和高效性就成为一对避不开的矛盾。

好的算法自然是把这两项都能提高，就是在保证数据安全的前提下，尽量缩短一个用户占用全部主机资源的时间。红锁就是一个比较好的解决方案。其原理如下：

假设系统中有7台主机，设一个设锁的有效时间作为最长允许用时。用户发出更新请求。

开始计时从第1个到第7个主机挨个加锁，其中：如果某个主机加锁的时间超过预定时间（如：50毫秒），则认为此主机已经不可用，立即放弃并进入下一个主机加锁。如果在尝试7个主机后，只有3个或更少的主机加锁成功（少于N/2+1），则认为本次加锁失败，将成功加锁的主机立即去除锁，返回用户，报告加锁失败。如果全部加锁完毕后所用的时间小于最初设定的有效时间，并且加锁的主机数超过一半（4台或更多），则认为加锁成功。反之，则认为加锁失败。其他的用户不定时的发出加锁请求，一旦请求成功则进入新的加锁程序。

“加锁”，就是用户给主机设一个特定的属性值Key，同一个用户的Key在所有的7台主机是一样的，其对应的属性值是随机产生的值。当Key在预定时间内过半数的主机成功设定，则锁就加上了。如果想解锁，就将这个Key值删除。用户想给主机加锁，要先检查Key是否已经存在。如果Key已经设了值，而这个值不是这个用户自己设定的，就放弃加锁，等待一段时间后再来尝试，直到Key是空值了就可以设定新的Key值来加锁。

红锁这样设定，是保证系统里一台或多台主机宕机了，设锁的程序仍然可以继续而不至于导致整个程序夯停。另外每个用户申请程序的等待时间也是随机的，可以避免多个用户在同一时刻申请加锁导致程序死锁。这样系统锁的排他性就可以保证了。同时，系统处理并发的效率也比较高。

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！