1. 不得不說的CAP原理
要介紹分佈式中的一致性，肯定會關聯出CAP原理，那什麼是CAP呢？
- 一致性（C）：分佈式系統更新操作之後，所有的節點數據一致。
- 可用性（A）：每一個非故障的節點必須對每一個請求作出響應。
- 分區容錯性（P）：分區容錯性。以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇，也就是說無論任何消息丟失，系統都可用。
根據CAP原理可知，任何一個分佈式系統，不可能同時滿足C、A、P，只能取其二。而且在分佈式系統中，網絡分區是必然存在的事實，所以要成爲一個分佈式系統必須保證P，也就是說一個有效的分佈式系統只能是CP/AP這兩種組合特性。
2.Zookeeper和CAP理論
根據分佈式CAP理論分析，可知Zookeeper只能是CP/AP,它到底是哪個呢？答案是CP,即Zookeeper保證了一致性和分區容錯性。
相信肯定有人會產生疑問，爲什麼說Zookeeper不滿足A這個特性呢？其實很簡單，就是在zookeeper啓動或者leader節點宕機等情況下會進行zookeeper的leader選舉，這個時候zookeeper進行只讀狀態，所以客戶端的更新請求將全部失敗，即可用性在此時是沒有辦法保證的。
雖然zookeeper是一個CP系統，但是它不是一個強一致性的系統，它是一種順序一致性的系統。爲了說明這種差別，需要介紹一下一致性的分類。
- 強一致性（strong consistency）。任何時刻，任何用戶都能讀取到最近一次成功更新的數據。
- 弱一致性（weak consistency）。用戶無法在確定時間內讀到最新更新的值。
- 最終一致性（eventual consistency）。用戶只能讀到某次更新後的值，但系統保證數據將最終達到完全一致的狀態，只是所需時間不能保障。
上面說了，三種常見的一致性分類，zookeeper是比最終一致性更高的順序一致性（可以看成保證最終一致性的前提下，順序響應請求）
3.Zookeeper順序一致性原理
- 所有的Follower的寫請求都會有leader進行處理，並等待所有的follower處理結果確認。
- follower收到leader發送來非自身的需要處理的客戶端請求，就會和leader同步，即保證follower的處理（主要是持久化和響應客戶端）順序和leader一致。
4.zookeeper一致性的缺陷
在前面介紹的一致性分類中，可知最好的是能實現強一致性，即保證任何時刻所有節點的數據是一致的，但是這種實現的代價是非常大的。在分佈式系統中存在多個節點，如果節點數過多爲了保證強一致性，需要將所有的節點全部確認一遍才能繼續響應。所以zookeeper默認是保證一半節點確認通過即可，但是它會帶來其他的問題。
主要是如果客戶端連接的是沒有參與確認的服務器，會出現客戶端讀取的"最新"數據其實是舊的數據，所以要保證客戶端讀取到真正的最新數據，需要先發起sync請求，保證最新數據已經同步完成。