ZooKeeper是什麼 ZooKeeper設計目的 ZooKeeper工作原理 Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議（ZooKeeper Atomic Broadcast protocol）。Zab協議有兩種模式，它們分別是 ...
ZooKeeper是什麼
| ZooKeeper是一個分散式的，開放源碼的分散式應用程式協調服務，是Google的Chubby一個開源的實現，它是集群的管理者，監視著集群中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的介面和性能高效、功能穩定的系統提供給用戶。 |
ZooKeeper設計目的
- 最終一致性：client不論連接到那個Server，展示給它的都是同一個視圖。
- 可靠性：具有簡單、健壯、良好的性能、如果消息m被到一臺伺服器接收，那麼消息m將被所有伺服器接收。
- 實時性：Zookeeper保證客戶端將在一個時間間隔範圍內獲得伺服器的更新信息，或者伺服器失效的信息。但由於網路延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()介面。
- 等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。
- 原子性：更新只能成功或者失敗，沒有中間狀態。
- 順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺伺服器上消息a在消息b前發佈，則在所有Server上消息a都將在消息b前被髮布；偏序是指如果一個消息b在消息a後被同一個發送者發佈，a必將排在b前面。
ZooKeeper工作原理
Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議（ZooKeeper Atomic Broadcast protocol）。Zab協議有兩種模式，它們分別是恢復模式（Recovery選主）和廣播模式（Broadcast同步）。當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以後，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。
為了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。
1、在zookeeper的集群中，各個節點共有下麵3種角色和4種狀態：
角色：leader,follower,observer
狀態：leading,following,observing,looking
2、每個Server在工作過程中有4種狀態：
LOOKING：當前Server不知道leader是誰，正在搜尋。
LEADING：當前Server即為選舉出來的leader。
FOLLOWING：leader已經選舉出來，當前Server與之同步。
OBSERVING：observer的行為在大多數情況下與follower完全一致，但是他們不參加選舉和投票，而僅僅接受(observing)選舉和投票的結果。
