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

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如果要解決分布式鎖的問題，對于一些復雜的情況，很難解決，成本較高。

以上就是分布式鎖為什么要選擇Zookeeper而不是Redis?看完這篇你就明白了的詳細內容，更多關于分布式鎖Zookeeper Redis的資料請關注腳本之家其它相關文章！