为什么RedLock并不能100%解决Redis做分布式锁的问题？

1：首先Redis性能变差了，这和zookeeper一样，多台机器都写成功了，才返回，性能会有下降。写了一部分成功，一部分失败，回滚也会造成性能损失。

 

2：加锁，加锁的时候Redis1节点挂了，Redis2和Redis3成功。

 

 

 

3：如果客户端线程在执行的时候，Redis2实例挂掉了，如果锁没有持久化，那么，那么Redis2的锁也就丢失了。重启后另外一个客户端线程来加锁。

 

在Redis1和Redis2加锁成功了，那么这个时候就会有两把一样的锁。

 

 

4：但是大部分情况下，加锁的时候Redis1、Redis2、Redis3都会加锁，所以99.999999999999999999999%的情况RedLock就是可用的。

 

 

5：但是如果你的redis锁是持久化了的，是可以达到100%可用的，其实就是zookeeper了（半数以上）。

 

 

red lock 本身没有思想没有任何问题，但是在cluster模式下会有问题。

 

假设一共有5个Redis节点：A, B, C, D, E。设想发生了如下的事件序列：

 

1. 客户端1成功锁住了A, B, C，获取锁成功（但D和E没有锁住）。
2. 节点C崩溃重启了，但客户端1在C上加的锁没有持久化下来，丢失了。
3. 节点C重启后，客户端2锁住了C, D, E，获取锁成功。

 

假设一共有5个Redis节点：A, B, C, D, E。设想发生了如下的事件序列：

 

1. 客户端1成功锁住了A, B, C，获取锁成功，也做了持久化（但D和E没有锁住）。
2. 节点C崩溃重启了，C的slaveC1替代了C作为master，。
3. 客户端2锁住了C1, D, E，获取锁成功。

 red lock 在cluster模式中使用时，可以将master和slave都作为需要上锁的目标，那么也是没有问题的。