《從 PAXOS 到 ZOOKEEPER：分散式一致性原理與實踐》讀書筆記[2]——初識 Zookeeper
1 Zookeeper 概論
Zookeeper 是一個分散式資料管理與協調框架，它是叢集的管理者，監視著叢集中各個節點的狀態根據節點提交的反饋進行下一步合理操作。分散式應用程式可以基於它實現諸如資料釋出/訂閱，負載均衡，命名服務，分散式協調/通知，叢集管理，Master 選舉，分散式鎖和分散式佇列等功能。
Zookeeper 可以保證如下分散式一致性特性：
- 順序一致性：從同一個客戶端發起的事務請求，最終將會嚴格按照其發起順序被應用到 Zookeeper 中
- 原子性：所有事務請求的處理結果在整個叢集中所有機器上的應用情況是一致的。
- 單一檢視：客戶端連線任何一個 Zookeeper 伺服器，其看到的服務端資料模型都是一致的
- 可靠性：事務所引起的服務端狀態變更將會一直被保留下來
- 實時性：保證在一定的時間段內，客戶端最終一定能夠從服務端上讀取到最新的資料狀態
2 ZAB 協議
ZAB 協議是為分散式協調服務 zookeeper 專門設計的一種支援崩潰恢復的原子廣播協議，基於該協議，Zookeeper 實現了一種主備模式的系統架構來保持叢集中各副本之間的資料的一致性。
2.1 協議內容
ZAB 協議包括兩種基本的模式，分別是崩潰恢復和訊息廣播。當整個服務框架在啟動過程中，或者是當 Leader 伺服器出現網路中斷，崩潰退出與重啟等異常情況時，ZAB 協議就會進入恢復模式並選舉產生新的 Leader 伺服器。當選舉產生新的 Leader 伺服器，同時叢集中已經有過半的機器與該 Leader 伺服器完成狀態同步後，ZAB 協議就會退出恢復模式。這時候整個服務框架就進入訊息廣播模式，當其他伺服器加入集群后就會自覺進行資料恢復模式，找到 Leader 所在的伺服器，並與其進行資料同步。
3 Zookeeper 使用
可參考此 Zookeeper 學習
4 Zookeeper 應用
4.1 資料釋出/訂閱
釋出者將資料釋出到 Zookeeper 的一個或者一系列節點上，客戶端向服務端註冊自己需要關注的節點，一旦該節點的資料發生變更，那麼服務端就會向相應的客戶端傳送 Watcher 事件通知，客戶端接收到這個訊息通知後，需要主動到服務端獲取最新的資料。
4.2 命名服務
在 Zookeeper 中，每一個數據節點都能夠維護一份子節點的順序序列，當客戶端對其建立一個順序子節點的時候 Zookeeper 會自動以後綴的形式在其子節點上新增一個序號，客戶端拿到這個返回值後，再拼接上 type 型別，這就可以作為一個全域性唯一的 ID 了。
4.3 分散式協調/通知
不同的客戶端都對 Zookeeper 上同一個資料節點進行 Watcher 註冊，監聽資料節點的變化（包括資料節點本身及其子節點），如果資料節點發生變化，那麼所有訂閱的客戶端都能夠收到相應的 Watcher 通知並做出相應的處理
4.4 叢集管理
叢集管理主要有兩點：機器的加入和退出、master 選舉
- 利用 Zookeeper 的 Watcher 監聽和臨時節點特性，可以實時檢測機器的變動情況
- 客戶端叢集每天會定時往 Zookeeper 節點 A 下建立一個臨時節點，在這個過程中，只有一個客戶端能夠成功建立這個節點（強一致性），那麼這個客戶端所在的機器就成了 master，同時其他沒有在 Zookeeper 上成功建立節點的客戶端，都會在節點 A 上註冊一個子節點變更的 Watcher，用於監控當前的 master 機器是否存活，一旦發現當前的 master 掛了，那麼其餘的客戶端將會重新進行 master 選舉
4.5 分散式佇列
所有客戶端都會到 A 節點下建立一個臨時順序節點，建立一個臨時順序節點，建立玩節點後，通過呼叫 getChildren() 介面來獲取 A 節點下的所有子節點，即獲取佇列中的所有元素，確定自己的節點序號在所有子節點中的順序，如果自己不是序號最小的子節點，那麼就需要進入等待，同時比向自己序號小的最有一個節點註冊 watcher 監聽，接收到 watcher 通知後，重複以上步驟。