上面我們已經討論了zookeeper在應用程序中的一些操作，以下我們須要理解一下服務端的工作的原理。client是怎樣通過一個client的類庫與服務端進行通信的，然後服務端又是怎樣回應client的。

以下這張圖顯示了client和服務端的關系，每一個client都須要導入到client的類庫中。然後才幹夠與zookeeper的節點進行交互

Zookeeper能夠運行在兩種模式中各自是獨立模式和復制模式，獨立模式就是同意在一臺主機上。zookeeper的狀態並不能被復制；對於集群模式，我們能夠保證服務端的狀態一致。而且同一時候一起收到來自client的請求。

Zookeeper的集群模式

在集群模式中。zookeeper須要復制他們的數據信息來保證全部的服務端信息一致性。那麽假設每一個client都須要等全部的信息一致的話。時間將會很的長。在一個公共的管理中，我們能夠採取以下辦法，比如有5臺zookeeperserver。可是能夠有三個集群的話，那麽client僅僅須要在3個集群信息保持一致的話，就能夠進行以下的操作，後面的2臺zookeeperserver終於會趕上和存儲數據。

重要的是怎樣選擇一個適當的大小的群體，最後必須保證，不管延遲和系統崩潰,不論什麽更新請求，服務都能夠運行下去。

在一個有5個節點的集合體中，每一個Follower節點的數據都是Leader節點數據的副本，也就是說我們的每一個節點的數據視圖都是一樣的，這樣就能夠有五個節點提供ZooKeeper服務。而且集合體中隨意2臺機器出現問題，都能夠保證服務繼續，由於剩下的3臺機器超過了半數。

回話

在client與zookeeper交互之前，client必須與服務端建立一個回話。回話是必須的，不論什麽client的操作都必須在回話中完畢，一旦回話結束，暫時節點也將會消失。

會話保證了順序的運行,這意味著請求在一個會話中運行

連續會話同樣的客戶,即使他們不重疊,也不一定保持先進先出順序。

這是可能發生在這樣的情況下:

1. client建立一個會話,使連續兩個異步調用創建/task和/worker

2. 第一個回話過期了

3. client創建了另外一個回話，異步的調用創建了/assign

在這個調用序列,它是可能的,僅僅有創建了/task和/assign,它保留了第一次回話中先進先出的順序,但違反了跨回話。

Zookeeper體系結構