一、CAP理論概述
CAP理論告訴我們，一個分布式系統不可能同時滿足以下三種
一致性（C:Consistency）
可用性（A:Available）
分區容錯性（P:Partition Tolerance）
這三個基本需求，最多只能同時滿足其中的兩項，因為P是必須的,因此往往選擇就在CP或者AP中。
一致性（C:Consistency）
在分布式環境中，一致性是指數據在多個副本之間是否能夠保持數據一致的特性。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操作后，應該保證系統的數據仍然處於一致的狀態。例如一個將數據副本分布在不同分布式節點上的系統來說，如果對第一個節點的數據進行了更新操作並且更新成功后，其他節點上的數據也應該得到更新，並且所有用戶都可以讀取到其最新的值，那么這樣的系統就被認為具有強一致性（或嚴格的一致性，最終一致性）。
可用性（A:Available）
可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠在有限的時間內返回結果。“有效的時間內”是指，對於用戶的一個操作請求，系統必須能夠在指定的時間（即響應時間）內返回對應的處理結果，如果超過了這個時間范圍，那么系統就被認為是不可用的。
“返回結果”是可用性的另一個非常重要的指標，它要求系統在完成對用戶請求的處理后，返回一個正常的響應結果。正常的響應結果通常能夠明確的反映出對請求的處理結果，即成功或失敗，而不是一個讓用戶感到困惑的返回結果。
分區容錯性（P:Partition Tolerance）
分區容錯性約束了一個分布式系統需要具有如下特性：分布式系統在遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網絡環境都發生了故障。
網絡分區是指在分布式系統中，不同的節點分布在不同的子網絡（機房或異地網絡等）中，由於一些特殊的原因導致這些子網絡之間出現網絡不連通的狀況，但各個子網絡的內部網絡是正常的，從而導致整個系統的網絡環境被切分成了若干個孤立的區域。需要注意的是，組成一個分布式系統的每個節點的加入與退出都可以看作是一個特殊的網絡分區。
由於一個分布式系統無法同時滿足上面的三個需求，而只能滿足其中的兩項，因此在進行對CAP定理的應用的時候，需要根據業務的要求拋棄其中的一項，下表所示是拋棄CAP定理中任意一項特性的場景說明。
因此，將精力浪費在思考如何設計能滿足三者的完美系統上是愚鈍的，應該根據應用場景進行適當取舍。
二、一致性的分類
一致性是指從系統外部讀取系統內部的數據時，在一定約束條件下相同，即數據變動在系統內部各節點應該是同步的。根據一致性的強弱程度不同，可以將一致性的分類為如下幾種：
強一致性：（strong consistency）。任何時刻，任何用戶都能讀取到最近一次成功更新的數據。
單調一致性：（monotonic consistency）。任何時刻，任何用戶一旦讀到某個數據在某次更新后的值，那么就不會再讀到比這個值更舊的值。也就是說，可獲取的數據順序必是單調遞增的。
會話一致性：（session consistency）。任何用戶在某次會話中，一旦讀到某個數據在某次更新后的值，那么在本次會話中就不會再讀到比這值更舊的值，會話一致性是在單調一致性的基礎上進一步放松約束，只保證單個用戶單個會話內的單調性，在不同用戶或同一用戶不同會話間則沒有保障。
最終一致性：（eventual consistency）。用戶只能讀到某次更新后的值，但系統保證數據將最終達到完全一致的狀態，只是所需時間不能保障。
弱一致性：（weak consistency）。用戶無法在確定時間內讀到最新更新的值。
三、ZooKeeper提供的一致性服務
ZooKeeper從以下幾點保證了數據的一致性
順序一致性：來自任意特定客戶端的更新都會按其發送順序被提交保持一致。也就是說，如果一個客戶端將Znode z的值更新為a，在之后的操作中，它又將z的值更新為b，則沒有客戶端能夠在看到z的值是b之后再看到值a（如果沒有其他對z的更新）。
原子性：每個更新要么成功，要么失敗。這意味着如果一個更新失敗，則不會有客戶端會看到這個更新的結果。
單一系統映像：一個客戶端無論連接到哪一台服務器，它看到的都是同樣的系統視圖。這意味着，如果一個客戶端在同一個會話中連接到一台新的服務器，它所看到的系統狀態不會比 在之前服務器上所看到的更老。當一台服務器出現故障，導致它的一個客戶端需要嘗試連接集合體中其他的服務器時，所有滯后於故障服務器的服務器都不會接受該 連接請求，除非這些服務器趕上故障服務器。
持久性：一個更新一旦成功，其結果就會持久存在並且不會被撤銷。這表明更新不會受到服務器故障的影響。
實時性：在特定的一段時間內，客戶端看到的系統需要被保證是實時的（在十幾秒的時間里）。在此時間段內，任何系統的改變將被客戶端看到，或者被客戶端偵測到。
四、用CAP理論來分析ZooKeeper
CAP理論告訴我們，一個分布式系統不可能同時滿足以下三種
一致性（C:Consistency）
可用性（A:Available）
分區容錯性（P:Partition Tolerance）
這三個基本需求，最多只能同時滿足其中的兩項，因為P是必須的,因此往往選擇就在CP或者AP中。
在此ZooKeeper保證的是CP
分析：可用性（A:Available）
不能保證每次服務請求的可用性。任何時刻對ZooKeeper的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性；但是它不能保證每次服務請求的可用性（注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果）。所以說，ZooKeeper不能保證服務可用性。
進行leader選舉時集群都是不可用。在使用ZooKeeper獲取服務列表時，當master節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。所以說，ZooKeeper不能保證服務可用性。
參考：https://www.cnblogs.com/xrq730/p/4944768.html
參考：https://blog.csdn.net/xiangxizhishi/article/details/78469027
Contact
作者：鵬磊
出處：http://www.ymq.io/2018/05/18/zookeeper
版權歸作者所有，轉載請注明出處
Wechat：關注公眾號，搜雲庫，專注於開發技術的研究與知識分享
