redlock算法及其问题

背景

redlock算法是为了解决什么问题呢?

在单redis实例实现分布式锁时,可能会出现线程A设置完锁后,master挂掉,slave提升为master,因为异步复制的特性,线程A设置的锁丢失了,这时候线程B设置锁也能够成功,导致线程A和B同时拥有锁

然后redis作者提出了redlock算法

算法描述

  1. 获得当前时间(ms)

  2. 首先设置一个锁有效时间valid_time,也就是超过这个时间后锁自动释放,使用相同的key和value对所有redis实例进行设置,每次链接redis实例时设置一个小于valid_time的超时时间,比如valid_time时10s,那超时时间可以设置成50ms,如果这个实例不行,那么换下一个设置

  3. 计算获取锁总共占用的时间,再加上时钟偏移,如果这个总时间小于valid_time,并且成功设置锁的实例数>= N/2 + 1,那么加锁成功

  4. 如果加锁成功了,那么这个锁的有效时间就是valid_time - 获取锁占用的时间 - 时钟偏移

  5. 如果加锁失败,解锁所有实例(每个redis实例都运行del key)

问题

好了,算法看完了,给我的感觉就是,好像更不靠谱了,因为引入了一个不靠谱的时间,时间偏差在分布式系统中应该是很容易出现的吧,在锁有效时间里虽然减去了时钟偏移,但是应该减多少合适呢,要是这个值设置不好,很容易出现问题

先不提这个,我们回顾一下单redis实例的问题,主从切换时可能会有两个线程占有锁,那么redlock有没有这个问题呢

假设我们有5个redis实例a,b,c,d,e,线程A分别加锁,然后a,b,c加锁成功,因为网络分区问题,d,e失败。同时,线程B也加锁,因为网络分区问题,a,b加锁失败,但是d,e加锁成功。这时候,显然线程A会获得锁,但是如果这时候c的master挂了,然后切换成了slave,slave中没有A加锁的信息,恰巧这时线程B对c加锁的命令到了,那线程B就会加锁成功,这时候,线程A和B都给三个节点加锁成功了,他们同时拥有锁。所以我认为redlock仍然没有解决这个问题,只是让这个问题更不容易发生了,这里如果我想错的话欢迎指正

另外,redis作者也对这个算法进行了分析,建议对锁互斥的安全性要求高的应用不要使用这个算法,分析了GC停顿,page fault,clock jump等等对时间产生的影响,可以参考http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

你可能感兴趣的:(redlock算法及其问题)