ZooKeeper是一種高效能，可擴充套件的服務，雖然讀取速度比寫入快，但是讀取和寫入操作都設計的極為快速，這樣做的原因是在讀取的情況下，ZooKeeper可能會提供較舊的資料
為分散式應用提供高效、高可用的分散式協調服務，提供了諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知和分散式鎖等分散式基礎服務
Zab協議是Zookeeper保證資料一致性的核心演算法，Zab借鑑了Paxos演算法，但又不像Paxos那樣，是一種通用的分散式一致性演算法，基於該協議，zk實現了一種主備模型（即Leader和Follower模型），保證了事務的最終一致性
資料一致性是靠Paxos演算法保證的 Paxos可以說是分散式一致性演算法的鼻祖 是ZooKeeper的基礎
1，首先客戶端所有的寫請求都由一個Leader接收，而其餘的都是Follower(從者)
2，Leader 負責將一個客戶端事務請求，轉換成一個 事務Proposal，並將該 Proposal 分發給叢集中所有的 Follower(備份) ，也就是向所有 Follower 節點發送資料廣播請求（或資料複製）記住這裡傳送給的不光是資料本身，還有其他的，相當於包裝
3，分發之後Leader需要等待所有Follower的反饋（Ack請求），在Zab協議中，只要超過半數的Follower進行了正確的反饋後（也就是收到半數以上的Follower的Ack請求），那麼 Leader 就會再次向所有的 Follower傳送 Commit 訊息，要求其將上一個 事務proposal 進行提交。

CAP理論
在理論電腦科學中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer’s theorem），它指出對於一個分散式計算系統來說，不可能同時滿足以下三點：
一致性（Consistence) （等同於所有節點訪問同一份最新的資料副本）
可用性（Availability）（每次請求都能獲取到非錯的響應——但是不保證獲取的資料為最新資料）
分割槽容錯性（Network partitioning）（以實際效果而言，分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇。）
根據定理，分散式系統只能滿足三項中的兩項而不可能滿足全部三項。理解CAP理論的最簡單方式是想象兩個節點分處分割槽兩側。允許至少一個節點更新狀態會導致資料不一致，即喪失了C性質。如果為了保證資料一致性，將分割槽一側的節點設定為不可用，那麼又喪失了A性質。除非兩個節點可以互相通訊，才能既保證C又保證A，這又會導致喪失P性質。

對於zookeeper來說，它實現了A可用性、P分割槽容錯性、C中的寫入強一致性，喪失的是C中的讀取一致性。
如果客戶端A將znode / a的值從0設定為1，則告訴客戶端B讀取/ a，則客戶端B可以讀取舊值0，這取決於它連線到的伺服器。如果客戶端A和客戶端B讀取相同的值很重要，則客戶端B應該在執行讀取之前從ZooKeeper API方法呼叫sync()方法。