在分布式的應用中，為了防止單點故障，保障高可用，通常會采用主從結構，當主節點掛掉后，從節點可以代替主節點提供服務。
Redis通過復制 + sentinel哨兵來實現主從模式。
Zookeeper通過replicated mode復制模式來實現主從模式。
單從結構上看，Redis和Zookeeper都是主從架構，那Zookeeper的優勢是什么？為什么要選擇Zookeeper？難道只是因為Zookeeper是目錄結構，Redis是K-V結構嗎？
同步機制的不同
Redis
Redis在給從節點同步數據時，正常情況是增量同步，也就是主節點的數據修改語句（DML）會異步的同步給從節點。Redis的數據同步沒有保障數據一致性的機制，也就是說，一條DML在主節點執行成功時，不能保障其他從節點成功執行了這條數據，這就會造成一個問題，如果在數據沒有同步到從節點時，主節點掛掉，就會產生數據丟失的情況。
Zookeeper
Zookeeper使用類paxos算法（zab）來保障數據的一致性。簡單的講，當一個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如果要解決分布式鎖的問題，對於一些復雜的情況，很難解決，成本較高。