ZooKeeper和CAP理論及一致性原則

1、CAP理論概述

CAP理論告訴咱們，一個分佈式系統不可能同時知足如下三種

• 一致性（C:Consistency）
• 可用性（A:Available）
• 分區容錯性（P:Partition Tolerance）

這三個基本需求，最多隻能同時知足其中的兩項，由於P是必須的,所以每每選擇就在CP或者AP中。

一致性（C:Consistency）

在分佈式環境中，一致性是指數據在多個副本之間是否可以保持數據一致的特性。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操做後，應該保證系統的數據仍然處於一致的狀態。例如一個將數據副本分佈在不一樣分佈式節點上的系統來講，若是對第一個節點的數據進行了更新操做而且更新成功後，其餘節點上的數據也應該獲得更新，而且全部用戶均可以讀取到其最新的值，那麼這樣的系統就被認爲具備強一致性（或嚴格的一致性，最終一致性）。

可用性（A:Available）

可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每個操做請求老是可以在有限的時間內返回結果。「有效的時間內」是指，對於用戶的一個操做請求，系統必須可以在指定的時間（即響應時間）內返回對應的處理結果，若是超過了這個時間範圍，那麼系統就被認爲是不可用的。

「返回結果」是可用性的另外一個很是重要的指標，它要求系統在完成對用戶請求的處理後，返回一個正常的響應結果。正常的響應結果一般可以明確的反映出對請求的處理結果，即成功或失敗，而不是一個讓用戶感到困惑的返回結果。

分區容錯性（P:Partition Tolerance）

分區容錯性約束了一個分佈式系統須要具備以下特性：分佈式系統在遇到任何網絡分區故障的時候，仍然須要可以保證對外提供知足一致性和可用性的服務，除非是整個網絡環境都發生了故障。

網絡分區是指在分佈式系統中，不一樣的節點分佈在不一樣的子網絡（機房或異地網絡等）中，因爲一些特殊的緣由致使這些子網絡之間出現網絡不連通的情況，但各個子網絡的內部網絡是正常的，從而致使整個系統的網絡環境被切分紅了若干個孤立的區域。須要注意的是，組成一個分佈式系統的每一個節點的加入與退出均可以看做是一個特殊的網絡分區。

因爲一個分佈式系統沒法同時知足上面的三個需求，而只能知足其中的兩項，所以在進行對CAP定理的應用的時候，須要根據業務的要求拋棄其中的一項，下表所示是拋棄CAP定理中任意一項特性的場景說明。

所以，將精力浪費在思考如何設計能知足三者的完美系統上是愚鈍的，應該根據應用場景進行適當取捨。

2、一致性的分類

一致性是指從系統外部讀取系統內部的數據時，在必定約束條件下相同，即數據變更在系統內部各節點應該是同步的。根據一致性的強弱程度不一樣，能夠將一致性的分類爲以下幾種：

強一致性：（strong consistency）。任什麼時候刻，任何用戶都能讀取到最近一次成功更新的數據。

單調一致性：（monotonic consistency）。任什麼時候刻，任何用戶一旦讀到某個數據在某次更新後的值，那麼就不會再讀到比這個值更舊的值。也就是說，可獲取的數據順序必是單調遞增的。

會話一致性：（session consistency）。任何用戶在某次會話中，一旦讀到某個數據在某次更新後的值，那麼在本次會話中就不會再讀到比這值更舊的值，會話一致性是在單調一致性的基礎上進一步放鬆約束，只保證單個用戶單個會話內的單調性，在不一樣用戶或同一用戶不一樣會話間則沒有保障。

最終一致性：（eventual consistency）。用戶只能讀到某次更新後的值，但系統保證數據將最終達到徹底一致的狀態，只是所需時間不能保障。

弱一致性：（weak consistency）。用戶沒法在肯定時間內讀到最新更新的值。

3、ZooKeeper提供的一致性服務

ZooKeeper從如下幾點保證了數據的一致性

順序一致性：來自任意特定客戶端的更新都會按其發送順序被提交保持一致。也就是說，若是一個客戶端將Znode z的值更新爲a，在以後的操做中，它又將z的值更新爲b，則沒有客戶端可以在看到z的值是b以後再看到值a（若是沒有其餘對z的更新）。

原子性：每一個更新要麼成功，要麼失敗。這意味着若是一個更新失敗，則不會有客戶端會看到這個更新的結果。

單一系統映像：一個客戶端不管鏈接到哪一臺服務器，它看到的都是一樣的系統視圖。這意味着，若是一個客戶端在同一個會話中鏈接到一臺新的服務器，它所看到的系統狀態不會比 在以前服務器上所看到的更老。當一臺服務器出現故障，致使它的一個客戶端須要嘗試鏈接集合體中其餘的服務器時，全部滯後於故障服務器的服務器都不會接受該 鏈接請求，除非這些服務器遇上故障服務器。

持久性：一個更新一旦成功，其結果就會持久存在而且不會被撤銷。這代表更新不會受到服務器故障的影響。

實時性：在特定的一段時間內，客戶端看到的系統須要被保證是實時的（在十幾秒的時間裏）。在此時間段內，任何系統的改變將被客戶端看到，或者被客戶端偵測到。

4、用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不能保證服務可用性。

參考：http://www.javashuo.com/article/p-edywrnfp-da.html

參考：https://blog.csdn.net/xiangxizhishi/article/details/78469027

Contact

• 做者：鵬磊
• 出處：http://www.ymq.io/2018/05/18/zookeeper
• 版權歸做者全部，轉載請註明出處
• Wechat：關注公衆號，搜雲庫，專一於開發技術的研究與知識分享