数据库
首页 > 数据库> > 【Redisson】五.Redisson RedLock算法的实现

【Redisson】五.Redisson RedLock算法的实现

作者:互联网

前言

  主要记录下,Redisson中RedLock加锁算法的实现

 

Redisson分布式锁的缺点

  由于Redisson的加锁方式,本质上时是判断某个Redis节点(主节点)是否具有某个key,且Redis集群间会发生异步的主从复制行为,可能会出现重复加锁的问题

  在极端情况下,

  客户端A加锁成功后,master节点数据会异步复制到slave节点,此时当前持有Redis锁的master节点宕机,slave节点被提升为新的master节点;

  客户端B再次加锁,在新的master节点上加锁也也会成功,这个时候客户端B也会认为加锁成功,出现两个节点同时持有一把锁的问题;

  此时就会产生脏数据的问题

 

RedLock算法

  场景是假设有一个redis cluster,有3个redis master实例

  然后执行如下步骤获取一把分布式锁:

   1)获取当前时间戳,单位是毫秒

  2)跟上面类似,轮流尝试在每个master节点上创建锁,过期时间较短,一般就几十毫秒,在每个节点上创建锁的过程中,需要加一个超时时间,一般来说比如几十毫秒如果没有获取到锁就超时了,标识为获取锁失败

  3)尝试在大多数节点上建立一个锁,比如3个节点就要求是2个节点(n / 2 +1)

  4)客户端计算建立好锁的时间,如果建立锁的时间小于超时时间,就算建立成功了

  5)要是锁建立失败了,那么就依次删除已经创建的锁

  6)只要别人创建了一把分布式锁,你就得不断轮询去尝试获取锁

  注意:普通的redis分布式锁,其实是在redis集群中根据hash算法选择一台redis实例创建一个锁就可以了

  RedLock算法思想,不能只在一个redis实例上创建锁,应该是在多个redis实例上创建锁,n / 2 + 1,必须在大多数redis节点上都成功创建锁,才能算这个整体的RedLock加锁成功,避免说仅仅在一个redis实例上加锁

 

RedLock缺点:

  1.红锁是很少使用的。这是因为使用了红锁后会影响高并发环境下的性能,使得程序的体验更差。

  2.使用红锁时,需要提供多套Redis的主从部署架构,同时,这多套Redis主从架构中的Master节点必须都是独立的,相互之间没有任何数据交互。

  3.使用红锁后,当加锁成功的RLock个数不超过总数的一半时,会返回加锁失败,即使在业务层面任务加锁成功了,但是红锁也会返回加锁失败的结果。

 

备注:实际场景中,一般都是要保证Redis集群的可靠性,而不使用RedLock算法实现的分布式锁

标签:加锁,RedLock,Redis,redis,算法,Redisson,master,节点
来源: https://www.cnblogs.com/july-sunny/p/15866621.html