一、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不能保證服務可用性。
參考：www.cnblogs.com/xrq730/p/49…