数据库
首页 > 数据库> > 基于Redission实现分布式锁

基于Redission实现分布式锁

作者:互联网

实现Redis的分布式锁,除了自己基于redis client原生api来实现之外,还可以使用开源框架:Redission

Redisson是一个企业级的开源Redis Client,也提供了分布式锁的支持。

回想一下上一篇文章《基于Redis实现分布式锁》说的,如果自己写代码来通过redis设置一个值,是通过下面这个命令设置的。

SET anyLock unique_value NX PX 30000

这里设置的超时时间是30s,假如我超过30s都还没有完成业务逻辑的情况下,key会过期,其他线程有可能会获取到锁。

这样一来的话,第一个线程还没执行完业务逻辑,第二个线程进来了也会出现线程安全问题。所以我们还需要额外的去维护这个过期时间,太麻烦了~

我们来看看redisson是怎么实现的?先感受一下使用redission的爽:

过程:

就是这么简单,我们只需要通过它的api中的lock和unlock即可完成分布式锁,他帮我们考虑了很多细节:

1:redisson所有指令都通过lua脚本执行,redis支持lua脚本原子性执行

2:redisson设置一个key的默认过期时间为30s,如果某个客户端持有一个锁超过了30s怎么办? redisson中有一个watchdog的概念,翻译过来就是看门狗,它会在你获取锁之后,每隔10秒帮你把key的超时时间设为30s 这样的话,就算一直持有锁也不会出现key过期了,其他线程获取到锁的问题了。

3:redisson的“看门狗”逻辑保证了没有死锁发生。 (如果机器宕机了,看门狗也就没了。此时就不会延长key的过期时间,到了30s之后就会自动过期了,其他线程可以获取到锁)

 

 

示例代码:

 

 

// 加锁以后30秒钟自动解锁

// 无需调用unlock方法手动解锁

redissionLock.lock(30, TimeUnit.SECONDS);

其实上面截图的代码

应该改为下面这个才好,这样子看门狗才能真正生效,不然上面的代码会造成30秒后,锁会自动解锁的。

redissionLock.lock();

但是我们除了要考虑客户端要怎么实现分布式锁之外,还需要考虑redis的部署问题。

 

redis有三种部署方式:

1:单机模式

如果采用单机部署模式,会存在单点问题,只要redis故障了,加锁就不行了。

2:master-slave + sentinel 哨兵模式

采用master-slave模式,即便通过sentinel做了高可用(Master 宕机后立马切换Slave作为新的Master),但是由于节点之间是采用异步通信的方式,如果A客户端刚刚在 Master 节点上加了锁,但是数据还没被同步到 Salve,这时 Master 节点挂了,它上面的锁就没了,这时进行主从切换,等新的 Master 出来后,B客户端此时就可以再获取同样的锁,出现一把锁被拿到了两次的场景,从而导致系统出现脏数据。

3:redis cluster 集群模式

采用redis cluster集群模式,比如3主3从,主备切换。但是由于节点之间是采用异步通信的方式,如果A客户端刚刚根据路由规则在其中一台Master 节点上加了锁,但是数据还没被同步到 它的Salve,这时 这台Master 节点挂了,它上面的锁就没了,这时进行主备切换,等新的 Master 出来后,B客户端此时就可以再获取同样的锁,出现一把锁被拿到了两次的场景,从而导致系统出现脏数据。

 

为了解决上面的问题,Redis 的作者提出了名为 Redlock 的算法。

在 Redis 的分布式环境中,我们假设有 N 个 Redis Master。这些节点完全互相独立,不存在主从复制或者其他集群协调机制。(要注意这点)

前面已经描述了在单点 Redis 下,怎么安全地获取和释放锁,我们确保将在 N 个实例上使用此方法获取和释放锁。

在下面的示例中,我们假设有 5 个完全独立的 Redis Master 节点,他们分别运行在 5 台服务器中,可以保证他们不会同时宕机。

从官网上我们可以知道,一个客户端如果要获得锁,必须经过下面的五个步骤:

步骤描述来源:

http://redis.cn/topics/distlock.html

1:获取当前Unix时间,以毫秒为单位。

2:依次尝试从N个实例,使用相同的key和随机值获取锁。在步骤2,当向Redis设置锁时,客户端应该设置一个网络连接和响应超时时间,这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒,则超时时间应该在5-50毫秒之间。这样可以避免服务器端Redis已经挂掉的情况下,客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应,客户端应该尽快尝试另外一个Redis实例。

3:客户端使用当前时间减去开始获取锁时间(步骤1记录的时间)就得到获取锁使用的时间。当且仅当从大多数(这里是3个节点)的Redis节点都取到锁,并且使用的时间小于锁失效时间时,锁才算获取成功。如果取到了锁,key的真正有效时间等于有效时间减去获取锁所使用的时间(步骤3计算的结果)。

4:如果因为某些原因,获取锁失败(没有在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间),客户端应该在所有的Redis实例上进行解锁(即便某些Redis实例根本就没有加锁成功)。

 

通过上面的步骤我们可以知道,只要大多数的节点可以正常工作,就可以保证 Redlock 的正常工作。这样就可以解决前面单点 Redis 的情况下我们讨论的节点挂掉,由于异步通信,导致锁失效的问题。

延迟重启

但是,还是不能解决故障重启后带来的锁的安全性的问题。你想一下下面这个场景,这个场景让redis的创始人提出了“延迟重启”的概念。

红锁之redis持久化失败后重启场景

我们一共有 A、B、C 这三个节点。

客户端 1 在 A,B 上加锁成功。C 上加锁失败。

这时节点 B 崩溃重启了,但是由于持久化策略导致客户端 1 在 B 上的锁没有持久化下来。

客户端 2 发起申请同一把锁的操作,在 B,C 上加锁成功。

这个时候就又出现同一把锁,同时被客户端 1 和客户端 2 所持有了。

(接下来又得说一说Redis的持久化策略了,全是知识点啊,朋友们)

比如,Redis 的 AOF 持久化方式默认情况下是每秒写一次磁盘,即 fsync 操作,因此最坏的情况下可能丢失 1 秒的数据。

当然,你也可以设置成每次修改数据都进行 fsync 操作(fsync=always),但这会严重降低 Redis 的性能,违反了它的设计理念。(我也没见过这样用的,可能还是见的太少了吧。)

而且,你以为执行了 fsync 就不会丢失数据了?天真,真实的系统环境是复杂的,这都已经脱离 Redis 的范畴了。上升到服务器、系统问题了。

所以,根据墨菲定律,上面举的例子:由于节点重启引发的锁失效问题,总是有可能出现的。

为了解决这一问题,Redis 的创始人又提出了延迟重启(delayed restarts)的概念。

意思就是说,一个节点崩溃后,不要立即重启它,而是等待一定的时间后再重启。等待的时间应该大于锁的过期时间(TTL)。这样做的目的是保证这个节点在重启前所参与的锁都过期。相当于把以前的帐勾销之后才能参与后面的加锁操作。

 

看门狗和红锁

看门狗和红锁和延迟重启其实都是redis的分布式锁的概念,真正用redis去实现是比较困难的,所以我们一般用reddission去实现,人家已经帮我们做好了,只要学会用它的代码就行。

这个红锁以及延迟重启思路的加锁算法在Redisson的红锁RedissonRedLock对象上面实现了,接下来我们来看是怎么用Reddsion实现的

该RedissonRedLock对象也可以用来将多个RLock对象关联为一个红锁,每个RLock对象实例可以来自于不同的Redisson实例。

红锁之有看门狗手动解锁方式:

Config config1 = new Config();

config1.useSingleServer().setAddress("redis://172.0.0.1:5378").setPassword("a123456").setDatabase(0);

RedissonClient redissonClient1 = Redisson.create(config1);

Config config2 = new Config();

config2.useSingleServer().setAddress("redis://172.0.0.1:5379").setPassword("a123456").setDatabase(0);

RedissonClient redissonClient2 = Redisson.create(config2);

Config config3 = new Config();

config3.useSingleServer().setAddress("redis://172.0.0.1:5380").setPassword("a123456").setDatabase(0);

RedissonClient redissonClient3 = Redisson.create(config3);

/**

* 获取多个 RLock 对象

*/

RLock lock1 = redissonClient1.getLock(lockKey);

RLock lock2 = redissonClient2.getLock(lockKey);

RLock lock3 = redissonClient3.getLock(lockKey);

/**

* 根据多个 RLock 对象构建 RedissonRedLock (最核心的差别就在这里)

*/

RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);

try {

    //有看门狗,业务没执行完可以不停的延长锁的过期时间

    boolean res = redLock.lock();

    if (res) {

        //成功获得锁,在这里处理业务

    }

} catch (Exception e) {

    throw new RuntimeException("aquire lock fail");

}finally{

    //无论如何, 最后都要解锁

    redLock.unlock();

}

 

大家都知道,如果负责储存某些分布式锁的某些Redis节点宕机以后,而且这些锁正好处于锁住的状态时,这些锁会出现锁死的状态。为了避免这种情况的发生,Redisson内部提供了一个监控锁的看门狗,它的作用是在Redisson实例被关闭前,不断的延长锁的有效期。默认情况下,看门狗的检查锁的超时时间是30秒钟,也可以通过修改Config.lockWatchdogTimeout来另行指定。

另外Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开了。

//给lock1,lock2,lock3加锁

RedissonRedLock lock=newRedissonRedLock(lock1, lock2, lock3);

 

红锁之无看门狗自动解锁方式1:

//如果没有手动解开的话,10秒钟后将会自动解开

lock.lock(10,TimeUnit.SECONDS);

...

lock.unlock();

 

红锁之无看门狗自动解锁方式2:

//为加锁等待100秒时间,并在加锁成功10秒钟后自动解开

booleanres=lock.tryLock(100,10,TimeUnit.SECONDS);

... 

lock.unlock(); 

下面代码采用的是红锁之无看门狗自动解锁方式2

Config config1 = new Config();

config1.useSingleServer().setAddress("redis://172.0.0.1:5378").setPassword("a123456").setDatabase(0);

RedissonClient redissonClient1 = Redisson.create(config1);

Config config2 = new Config();

config2.useSingleServer().setAddress("redis://172.0.0.1:5379").setPassword("a123456").setDatabase(0);

RedissonClient redissonClient2 = Redisson.create(config2);

Config config3 = new Config();

config3.useSingleServer().setAddress("redis://172.0.0.1:5380").setPassword("a123456").setDatabase(0);

RedissonClient redissonClient3 = Redisson.create(config3);

/**

* 获取多个 RLock 对象

*/

RLock lock1 = redissonClient1.getLock(lockKey);

RLock lock2 = redissonClient2.getLock(lockKey);

RLock lock3 = redissonClient3.getLock(lockKey);

/**

* 根据多个 RLock 对象构建 RedissonRedLock (最核心的差别就在这里)

*/

RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);

try {

    /**

    * 尝试获取锁

    * waitTimeout 尝试获取锁的最大等待时间,超过这个值,则认为获取锁失败

    * leaseTime  锁的持有时间,超过这个时间锁会自动失效(值应设置为大于业务处理的时间,确保在锁有效期内业务能处理完)

    */

    boolean res = redLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);

    if (res) {

        //成功获得锁,在这里处理业务

    }

} catch (Exception e) {

    throw new RuntimeException("aquire lock fail");

}finally{

    //无论如何, 最后都要解锁

    redLock.unlock();

}

 

Reddsion的红锁有一个宕机细节

如果采用红锁之有看门狗手动解锁方式,按照上面的“红锁之redis持久化失败后重启场景”,有3个节点ABC,其实我们已经解决了延迟重启问题,但是这时候,只有AC节点在正常运行,B节点还未重启的情况:

客户端2要获取一样的锁,是获取不了的,因为AB节点获取失败,C节点就算获取成功,也是只有1个获取成功,所以会获取不了一样的锁,这点是正常的。

客户端2要获取不一样的锁,AC可以获取得到,还是有办法的,这点是正常的。

这但是如果这时候C节点也挂了,剩下一个A节点有锁,

这时候想要获取一样的锁,不成功,这是正常的,等到这个锁解锁了,其他节点就可以重启了!

这时候想要获取不一样的锁,不成功,因为只剩下1个正常的节点!

 

比如5个节点的话,ABCDE,ABC加锁成功,DE加锁失败,这时候B又挂了,剩下AC有锁而已,DE没有锁。

客户端2要获取一样的锁,是获取不了的,因为ABC节点获取失败,DC节点就算获取成功,也是只有2个获取成功,所以会获取不了一样的锁,这点是正常的。

客户端2要获取不一样的锁,ACDE可以获取得到,还是有办法的,这点是正常的。

但是如果这时候C节点也挂了,剩下一个A节点有锁,DE没锁,

这时候想要获取一样的锁,不成功,这是正常的,等到这个锁解锁了,其他节点就可以重启了!

这时候想要获取不一样的锁,可能会成功,因为有3个正常的节点!

 

比如6个节点的话,ABCDEF,ABCD加锁成功,EF加锁失败,这时候B又挂了,剩下ACD有锁而已,EF没有锁。

客户端2要获取一样的锁,是获取不了的,因为ABCD节点获取失败,EF节点就算获取成功,也是只有2个获取成功,所以会获取不了一样的锁,这点是正常的。

客户端2要获取不一样的锁,ACDEF可以获取得到,还是有办法的,这点是正常的。

但是如果这时候C节点也挂了,剩下一个AD节点有锁,EF没锁,

这时候想要获取一样的锁,不成功,这是正常的,等到这个锁解锁了,其他节点就可以重启了!

这时候想要获取不一样的锁,可能会成功,因为有4个正常的节点!

但是如果这时候CD节点都挂了,剩下一个A节点有锁,EF没锁,

这时候想要获取一样的锁,不成功,这是正常的,等到这个锁解锁了,其他节点就可以重启了!

这时候想要获取不一样的锁,不会成功,因为只有3个正常的节点!

总结:如果大多数节点,进入了等待。就会导致系统的不可用,因为系统在业务执行完程序手动解锁的时间内(或者TTL时间内)任何锁(一样的锁和不一样的锁)都将无法加锁成功,其实等待 执行完手动解锁或者TTL时间内,其他节点自动重启就没事了,所以没有太大的问题!

Reddsion的红锁有一个释放锁细节

释放锁的时候是要向所有节点发起释放锁的操作的。这样做的目的是为了解决有可能在加锁阶段,这个节点收到加锁请求了,也set成功了,但是由于返回给客户端的响应包丢了,导致客户端以为没有加锁成功。所有,释放锁的时候要向所有节点发起释放锁的操作。

 

红锁算法最重要的问题来了!!!也算要注意红锁算法的bug所在吧!

 

如果采用“看门狗失效红锁自动解锁方式1和2”,

问题1:

1、如果A客户端获取到了锁,然后它的A线程GC暂停了,经过一段时间,锁自动解锁了

2、此时B客户端来获取一样的锁,这时候A线程GC恢复了,此时A线程继续执行他的业务代码,B客户端的B线程也同时执行它的业务代码

3、这时候会导致同一时间内两个客户端有同一把锁,没有满足同一时间内一个锁只能有一个客户端持有的原则,所以会导致系统出现脏数据

从客户端的角度来看,就是这玩意不靠谱啊,你给我一把锁,我还没用呢,你就过期了,但是我还以为我能用,哪还知道其他人也有跟我一样的锁,这下好了这个锁同时被两个人用,这是不靠谱的做法!

(我觉得无法反驳)

问题2:

1、客户端 1 向 Redis 节点 A, B, C, D, E 发起锁请求。

2、各个 Redis 节点已经把请求结果返回给了客户端 1,但客户端 1 在收到请求结果之前进入了长时间的 GC 阶段。

3、长时间的 GC,导致在所有的 Redis 节点上,锁过期了。

4、客户端 2 在 A, B, C, D, E 上申请并获取到了锁。

5、客户端 1 从 GC 阶段中恢复,收到了前面第 2 步来自各个 Redis 节点的请求结果。客户端 1 认为自己成功获取到了锁。

6、客户端 1 和客户端 2 现在都认为自己持有了锁。

我觉得可以反驳,这种情况其实对于 Redlock 是没有影响的,因为在第 5 步,客户端 1 从 GC 阶段中恢复过来以后,在 Redlock 算法中,如果取到了锁,key 的真正有效时间等于有效时间减去获取锁所使用的时间,客户端1通过这个检查发现锁已经过期了,不会再认为自己成功获取到锁了)

对于问题1问题2,redis创始人有反驳,我只看得懂能够反驳问题2,反驳不了问题1。

 

redis创始人的反驳:“Redlock 没有提供类似于fencing机制那样的单调递增的令牌,但是也有一个随机串,把这个随机串当做token,也可以达到同样的效果啊。当需要和共享资源交互的时候,我们检查一下这个token是否发生了变化,如果没有再执行“获取-修改-写回”的操作”

如果有人能理解这段话能反驳问题1的话,麻烦在文章下面评论一下。让我好好理解一下,谢谢!(后面我跟程序圈的why神聊过,redis的创始人是没法反驳问题1的,只能反驳问题2)

 

问题3:时钟发生跳跃(关于马丁哥的疑问)

1:客户端 1 从 Redis 节点 A, B, C 成功获取了锁。由于网络问题,无法访问 D 和 E。

2:节点 C 上的时钟被人修改了或者从NTP服务收到了一个大的时钟更新事件,导致它上面维护的锁过期了。

3:客户端 2 从 Redis 节点 C, D, E 成功获取了同一个资源的锁。由于网络问题,无法访问 A 和 B。

4:现在,客户端 1 和客户端 2 都认为自己持有了锁。

这样的场景是可能出现的,因为 Redlock 严重依赖系统时钟,所以一旦系统的时间变得不准确了,那么该算法的安全性也就得不到保障了。

延迟启动方案,延迟启动还不是依赖于合理准确的时间度量,如果时钟不准确,该算法的安全性也一样没有保障。

总结:

1:运维人员手动修改了系统时钟。

2:从NTP服务收到了一个大的时钟更新事件。

redis创始人进行了回击:

第一点这个运维人员手动修改时钟,属于人为因素,这个我也没办法啊,人家就是要搞你,怎么办?加强管理,不要这样做。

第二点从NTP服务收到一个大的时钟更新,对于这个问题,需要通过运维来保证,通过正确配置NTP。需要将大的时间更新到服务器的时候,应当采取少量多次的方式。多次修改,每次更新时间尽量小。

关于这个地方的争论,就看你是信马丁哥的时间一定会跳跃,还是redis创始人的时间跳跃我们也是可以处理的。

redis创始人的想法:他是同意大的系统时钟跳跃会造成 Redlock 失效的。在这一点上,他与马丁哥的观点的不同在于,他认为在实际系统中是可以通过好的运维方式避免大的时钟跳跃的。

 

对于问题123,其实Redission使用“看门狗生效红锁方式”就能解决,A线程GC的时候,看门狗一直续锁的过期时间,使这个锁不会过期,而且确保系统时钟不要出现大的时间跳跃(比如人为修改系统时钟或者收到大的时钟更新时间的话,就正确配置NTP,其实这里的时间跳跃不要超过20秒就好,因为每个10秒,看门狗会去自动更新过期时间为30秒,不过这个30秒也是可以设置的,可以更改为60甚至更多,改为60的话,就是60/3=20,每隔20秒去重置过期时间),基本可以保证redission的分布式锁的零失误率,系统不出现脏数据!!!

还有就是各个redis应用不要大多数宕机,这会导致系统一时间没法加锁,但是不会导致系统出现脏数据。

但是其实上面这个方式,还有一个bug的存在,非常极端的条件。

问题4:看门狗gc暂停场景

1、如果A客户端获取到了锁,然后它的A线程GC暂停了,它的看门狗线程也GC暂停,经过一段时间,锁自动解锁了

2、此时B客户端来获取一样的锁,这时候A线程GC恢复了,它的看门狗线程GC没有恢复(其实此时恢复与不恢复都没关系吧,比较锁都过期了,而且别的客户端也一样拿到一样的锁了),此时A线程继续执行他的业务代码,B客户端的B线程也同时执行它的业务代码

3、这时候会导致同一时间内两个客户端有同一把锁,没有满足同一时间内一个锁只能有一个客户端持有的原则,所以会导致系统出现脏数据

所以在使用“看门狗生效红锁方式”的这种方式,保证时钟不会出问题,如果出现“看门狗gc暂停”场景,reddission的红锁算法也是不靠谱的,在极端条件下还是会出现bug的!

或者可以考虑,只使用redis单机模式的reddission分布式锁就好了,简单而且效率高。用 Redlock 太重。

但是单机模式的话,有一个场景:

A客户端拿到锁,然后 此时A客户端的线程GC暂停了,看门狗GC不GC没有关系,此时单机redis也宕机了,等到锁过期了,我们重启了redis,此时B客户端的拿到一样的锁,此时A客户端的线程GC恢复了,继续执行他的业务,此时同一个时间有两个客户端拿到同一把锁!

解决方法:

redis宕机的时候,别那么快去重启redis,防止有线程在GC暂停中,应该等线程超时之后再去重启,或者你的方法里面有事务,等到事务超时再去重启redis应用!

 

总结:

redis暂时也没实现这种令牌思维,所以采用redission分布式锁,用哪种都可以,

红锁:只能更好的避免出现脏数据的几率,而且不会出现单点问题。

单机redis:会出现单点故障,但是小心点处理重启时间,也不会出现脏数据。

主从哨兵模式,cluster模式:宕机的话比较容易出现脏数据。

其实用redis做分布式锁,在极端环境下,是无法完全保证不出现脏数据。

对付脏数据的方法:

其实多下了订单的话超出了库存,可以在业务层面去解决,比如多预留一些商品库存,把多下的订单商品也进行发货,

库存表如果有库存总数量,维护的时候就要把库存的总数量进行修改,剩余库存总数量就不用更改,避免脏数据。

,或者将超出库存多下的订单,回滚,设置为无效,修复脏数据,其中的数据修改细节,每个系统的都不一样,有些系统还可能涉及到积分还有其他会员等级之类的变动,所以修复脏数据,应该依照自己的系统情况来做。

 

redis分布式锁在这个地方有一个缺点没做好,也是之前马丁哥所说的例子:

 

 

也就是说 GC 恢复了,但是你其实已经锁已经失效了,但是你还觉得自己是有效的,然后业务继续执行,殊不知道还有人也拿到这把一样的锁,跟你一起在执行。

要实现这一目标,可以采用fencing令牌思维。

1、客户端 1 获得一个具有超时时间的锁的同时得到了令牌号 33,但随后陷入了一个长时间的暂停直到锁到期。

2、这时客户端2已经获得了锁和令牌号 34 ,然后发送写请求(以及令牌号 34 )到存储服务。 

3、接下来客户端 1 恢复过来,并以令牌号 33 来尝试写入,存储服务器由于记录了最近已经完成了更高令牌号(34 ),因此拒绝令牌号 33 的写请求。

这种版本号的机制,让我不禁想起了 Zookeeper。当使用 ZK 做锁服务时,可以用事务标识 zxid 或节点版本 cversion 来充当 fencing 令牌,这两个都可以满足单调递增的要求。

长发哥在书中也说到了:在服务端检查令牌可能看起来有点复杂,但是这其实是推荐的正确的做法:系统服务不能假定所有的客户端都表现的符合预期。从安全角度讲,服务端必须防范这种来自客户端的滥用。

 

对于redis的分布式锁而言,优缺点:

1、它获取锁的方式简单粗暴,获取不到锁直接不断尝试获取锁,比较消耗性能。

2、另外来说的话,redis的设计定位决定了它的数据并不是强一致性的,在某些极端情况下,可能会出现问题。锁的模型不够健壮

3、即便使用redlock算法来实现,在某些复杂场景下,也无法保证其实现100%没有问题,关于redlock的讨论可以看How to do distributed locking

4、但是另一方面使用redis实现分布式锁在很多企业中非常常见,而且大部分情况下都不会遇到所谓的“极端复杂场景”

所以使用redis作为分布式锁也不失为一种好的方案,最重要的一点是redis的性能很高,可以支撑高并发的获取、释放锁操作。

 

另外还有一种分布式锁是zookeeper分布式锁

对于zookeeper的分布式锁而言,优缺点:

1、zookeeper天生设计定位就是分布式协调,强一致性。锁的模型健壮、简单易用、适合做分布式锁。

2、如果获取不到锁,只需要添加一个监听器就可以了,不用一直轮询,性能消耗较小。

3、如果有较多的客户端频繁的申请加锁、释放锁,对于zk集群的压力会比较大。

 

建议:

如果注重数据的准确性,数据不允许有一点错误:可以用zookeeper分布式锁解决,可以保证绝对不出问题,但是性能比redis差。

如果能容忍redis宕机问题导致reddsion分布式锁出现的锁失效问题,从而可能会导致数据出现问题,则可以还是使用redis。

如果使用“看门狗生效红锁方式”,则只需要确保系统时钟不要出现大的跳跃就可以保证零失误,极端条件下出现脏数据的话,就按照自己的系统的情况去处理脏数据吧!

标签:基于,加锁,Redis,redis,获取,Redission,分布式,节点,客户端
来源: https://blog.csdn.net/weixin_40918067/article/details/116561409