Zookeeper有兩種運行模式：
獨立模式（standalone mode):只運行在一臺服務器上，適合測試環境
復制模式（replicated mode)：運行于一個集群上，適合生產環境，這個計算機集群被稱為一個“集合體”（ensemble）。Zookeeper通過復制來實現高可用性，只要集合體中半數以上的機器處于可用狀態，它就能夠保證服務繼續。為什么一定要超過半數呢？這跟Zookeeper的復制策略有關：zookeeper確保對znode樹的每一個修改都會被復制到集合體中超過半數的機器上。
生產環境，zookeeper集群的服務器數目應該是奇數。
Zookeeper集群中的角色及其職責
領導者
1.管理寫請求
跟隨者
1.響應客戶端的讀請求
2.負責把客戶端提交的寫請求轉發給領導者
znode的觀察機制
znode以某種方式發生變化時，“觀察”（watch）機制可以讓客戶端得到通知。可以針對ZooKeeper服務的“操作”來設置觀察，該服務的其他操作可以觸發觀察。比如，客戶端可以對某個客戶端調用exists操作，同時在它上面設置一個觀察，如果此時這個znode不存在，則exists返回false，如果一段時間之后，這個znode被其他客戶端創建，則這個觀察會被觸發，之前的那個客戶端就會得到通知。
sync： 將客戶端的znode視圖與ZooKeeper同步
SYNC消息：返回SYNC結果到客戶端，這個消息最初由客戶端發起，用來強制得到最新的更新。
跨客戶端視圖的并發一致性：
ZooKeeper并不保證在某時刻，兩個不同的客戶端具有一致的數據視圖。因為網絡延遲的原因，一個客戶端可能在另一個客戶端得到修改通知之前進行更新。假定有兩個客戶端A和B。如果客戶端A將一個節點/a的值從0修改為1，然后通知客戶端B讀取/a，客戶端B讀取到的值可能還是0，這取決于它連接到了哪個服務器。如果客戶端A和B讀取到相同的值很重要，那么客戶端B應該在執行讀取之前調用sync()方法。
所以，ZooKeeper本身不保證修改在多個服務器間同步地發生，但是可以使用ZooKeeper原語來構建高層功能，提供有用的客戶端同步。
設計目的
1.最終一致性：client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。
2 .可靠性：具有簡單、健壯、良好的性能，如果消息m被到一臺服務器接受，那么它將被所有的服務器接受。
3 .實時性：Zookeeper保證客戶端將在一個時間間隔范圍內獲得服務器的更新信息，或者服務器失效的信息。但由于網絡延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。
4 .等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。
5.原子性：更新只能成功或者失敗，沒有中間狀態。
6 .順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺服務器上消息a在消息b前發布，則在所有Server上消息a都將在消息b前被發布；偏序是指如果一個消息b在消息a后被同一個發送者發布，a必將排在b前面。
節點宕機：
應用集群中，我們常常需要讓每一個機器知道集群中（或依賴的其他某一個集群）哪些機器是活著的，并且在集群機器因為宕機，網絡斷鏈等原因能夠不在人工介入的情況下迅速通知到每一個機器。
Zookeeper同樣很容易實現這個功能，比如我在zookeeper服務器端有一個znode叫/APP1SERVERS,那么集群中每一個機器啟動的時候都去這個節點下創建一個EPHEMERAL類型的節點，比如server1創建/APP1SERVERS/SERVER1(可以使用ip,保證不重復)，server2創建/APP1SERVERS/SERVER2，然后SERVER1和SERVER2都watch /APP1SERVERS這個父節點，那么也就是這個父節點下數據或者子節點變化都會通知對該節點進行watch的客戶端。因為EPHEMERAL類型節點有一個很重要的特性，就是客戶端和服務器端連接斷掉或者session過期就會使節點消失，那么在某一個機器掛掉或者斷鏈的時候，其對應的節點就會消失，然后集群中所有對/APP1SERVERS進行watch的客戶端都會收到通知，然后取得最新列表即可。
zookeeper是一個高可用性，高性能的協調服務
解決哪些問題
在分布式應用中，經常會出現部分失敗的情況，即當節點間傳遞消息的時候由于網絡或者接收者進程死掉等原因，發送者無法知道接收者是否收到消息。
由于部分失敗是分布式系統固有的特征因此zookeeper并不能避免部分失敗，但是它可以幫你在部分失敗的時候進行正確處理
為了解決這個問題zookeeper具有以下特征：
1：zookeeper提供豐富的構件（building block）來實現很多協調數據結構和協議
2：訪問原子性，客戶端要么讀到所有數據，要么讀取失敗，不會出現只讀取部分的情況
3：zookeeper運行在一組機器上，具有高可用性，幫助系統避免單點故障，同時刪掉故障服務器
4：順序一致性：任意客戶端的更新請求會被按照發送順序提交
5：單一系統映像：當一臺服務器故障，導致它的客戶端需要連接其它服務器的時候，所有更新晚于故障服務器的服務器都不會接收請求，一直到更新趕上故障服務器
6：及時性：任何客戶端能看到的滯后都是有限的，不會超過幾十秒，且提供sync操作強制客戶端所連的服務器與領導者同步
7：會話：每個客戶端連接時會嘗試連接到配置列表中的一臺服務器，一旦失敗會自動連接另一臺服務器依次類推，知道成功連接一臺服務器，從而創建一個會話，客戶端可以位每個會話設置超時時間，一旦會話過期，則所有短暫znode會丟失，因為zookeeper會自動發送心跳包，所以很少發生
8：約會機制（rendezvous），在交互的過程中，被協調的各方不許要事先彼此了解，甚至不必同時存在
9：ACL：zookeeper提供了digest（通過用戶名密碼），host（通過主機名），ip（通過ip地址）3種身份驗證模式，依賴與zookeeper的身份驗證機制每個ACL都是一個身份對應一組權限，如果我們要給demo.com的客戶端域一個讀權限在java語言中可以這樣創建：
new ACL(Perms.READ, new Id("host", "demo.com"));
Ids.OPEN_ACL_UNSAFE是將所有ADMIN之外的權限授予每個人
另zookeeper還可以集成第三方的身份驗證系統
10：提供關于通用協調模式的開源共享資源庫
11：高性能的（官方數據）對以寫為主的工作負載來說使用5臺不錯的機器基準吞吐量達到10000+