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 通知後，重複以上步驟。
文章來源：https://gongfukangee.github.io/2018/10/02/Zookeeper-2/
下一篇：《從 PAXOS 到 ZOOKEEPER：分佈式一致性原理與實踐》讀書筆記[3]——Zookeeper 技術內幕 https://blog.csdn.net/Rabbit_Judy/article/details/83302417