為什么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都作為需要上鎖的目標，那么也是沒有問題的。