标签：加锁 RedLock Redis redis 算法 Redisson master 节点

前言

　　主要记录下，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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。