【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