释放锁:为所有Redis NOD启动美国服务器锁释放操作

2019-03-27 21:58:21 美国机房 高防IP

V3.1版本仅在一个实例场景中是安全的。针对如何实现分布式Redis的锁,国外的分布式专家进行了热烈的讨论,antirez提出了一种分布式锁定算法,Redlock,。您可以在dislock主题下看到Redlock的详细描述。以下是Redlock算法的中文描述(引用)。

美国服务器租用机房:假设有N个独立的Redis Nod

获取当前时间(毫秒数)。

N个Redis节点被依次执行以获取锁。这个抓取操作与以前基于单个Redis节点获取锁的过程相同,包括随机字符串My_RANGINT_VALUE,以及过期时间(比如PX 30000,即锁的有效时间)。为了确保在Redis节点不可用时该算法能够继续运行,锁捕获操作也有一个time out(time out),这比锁的有效时间(几十毫秒量级)要小得多。客户端无法从Redis节点获得锁后,应该立即尝试下一个Redis节点。这里的失败应该包含任何类型的失败,例如Redis节点的不可用性,或者Redis节点上的锁已经被其他客户端持有的事实(注:Redlock原文中这里只提到了Redis节点不可用的情况,但也应该包含其它的失败情况)。但其他失败也应包括在内)。

通过从当前时间减去步骤1中记录的时间,计算整个获得锁的过程所消耗的总时间。如果客户端成功地从大多数Redis节点(>= N/2+1)获取锁,并且获取锁所花费的总时间不超过锁的有效时间(lock validity time),那么客户端认为锁最终被成功地获得了。否则,锁的最终获取失败。
如果锁最终获得成功,则应重新计算锁的有效时间,这等于初始锁的有效时间减去步骤3中计算的捕获锁所消耗的时间。

如果锁的最终获取失败(可能由于获取到锁的Redis节点个数少于N/2+1,或者整个获取锁的过程消耗的时间超过了锁的最初有效时间),那么客户端应该立即启动对所有Redis节点(即前面介绍的Redis Lua脚本)的锁定释放。

释放锁:为所有Redis NOD启动锁释放操作

然而,Martin Kleppmann对此算法提出了质疑,并建议该算法应基于击剑令牌机制(每次对资源进行操作都需要进行token验证)。

1.Redlock提出了系统模型的假设,特别是分布式时钟一致性问题,在实际情况下存在时钟不一致和时钟跳频问题,Redlock正是基于时序的分布式锁。

2.此外,由于Redlock基于自动过期机制,仍然无法解决长期GC暂停等导致的锁自动故障,从而导致安全问题。

然后antirez回答了Martin Kleppmann的问题,并给出了过期机制的合理性,以及如果出现暂停问题导致多个客户同时访问资源,该如何处理。
为了解决Redlock问题,对基于Redis的分布式锁的安全性进行了详细的中文说明,并分析了Redlock算法存在的问题。