分佈式鎖為什麼要選擇Zookeeper而不是Redis？

2021 年 5 月 21 日
筆記

在分佈式的應用中，為了防止單點故障，保障高可用，通常會採用主從結構，當主節點掛掉後，從節點可以代替主節點提供服務。

Redis通過複製 + sentinel哨兵來實現主從模式。

Zookeeper通過replicated mode複製模式來實現主從模式。

單從結構上看，Redis和Zookeeper都是主從架構，那Zookeeper的優勢是什麼？為什麼要選擇Zookeeper？難道只是因為Zookeeper是目錄結構，Redis是K-V結構嗎？

同步機制的不同

Redis

Redis在給從節點同步數據時，正常情況是增量同步，也就是主節點的數據修改語句（DML）會異步的同步給從節點。Redis的數據同步沒有保障數據一致性的機制，也就是說，一條DML在主節點執行成功時，不能保障其他從節點成功執行了這條數據，這就會造成一個問題，如果在數據沒有同步到從節點時，主節點掛掉，就會產生數據丟失的情況。

Zookeeper

Zookeeper使用類paxos算法來保障數據的一致性。簡單的講，當一個DML語句發送給主節點時，Zookeeper需要保證一半以上的節點接收到數據，才會返回成功。並且當主節點掛掉，從節點重新選舉時，同步到最新的數據的節點會有優先選舉權。

舉個例子：

一個4節點Zookeeper（A、B、C、D），A是主節點，當執行一個create語句成功時，至少有3台節點執行成功（一半以上），例如A、C、D成功。此時如果A節點掛了，B、C、D進行選舉，由於C、D都執行成功了create語句，B沒有執行，C、D的數據更加新，具有優先選舉權，再根據名稱排序，選擇C做為主節點。在整個選舉過程中，服務不可用，選舉完成後，C節點和A節點數據一致，不會出現丟失的情況。

分佈式鎖

要實現分佈式鎖，需要滿足一些要求：

只能有一個服務的一個線程能獲取鎖
一個持有鎖的線程掛掉後，鎖應該被釋放，用來給其他線程用
一個持有鎖的線程沒執行完，鎖不能釋放
鎖釋放後，其他等待者可以繼續爭搶
管理鎖的主節點（Redis或Zookeeper）掛了，重新選舉後，不影響鎖的持有情況

Redis解決方案

問題1、問題2：使用「SET key value EX seconds NX」語句獲取鎖並設置過期時間

問題3：另開一個監控線程，監控主線程執行情況，用來延長過期時間

問題4：等待線程定時檢查鎖的持有情況

問題5：暫無或者解決成本很高，需要自己實現類paxos的算法

Zookeeper解決方案

通過創建臨時節點可以解決問題1，2，3

watch機制可以解決問題4，並且相比定時檢查，watch可以做到更高實時性

zookeeper的paxos同步機制保障了節點間數據一致性，即使主節點掛掉，也可以保障數據不丟，可以解決問題5

對比可以發現：

Zookeeper的機制可以保證分佈式鎖實現業務代碼簡單，成本低。

Redis如果要解決分佈式鎖的問題，對於一些複雜的情況，很難解決，成本較高。