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