1、Zookeeper 的數據模型
Zookeeper 的數據模型類似於，數據結構中的樹。
樹是由節點所組成，Zookeeper 的數據存儲也同樣是基於節點，這種節點叫做 Znode
但是，不同於樹的節點，Znode 的引用方式是路徑引用，類似於文件路徑：
/動物/貓
/汽車/寶馬
這樣的層級結構，讓每一個 Znode 節點擁有唯一的路徑，就像命名空間一樣對不同信息作出清晰的隔離。
2、Znode 包含哪些元素？
- data：Znode 存儲的數據信息。
- ACL：記錄 Znode 的訪問權限，即哪些人或哪些 IP 可以訪問本節點。
- stat：包含 Znode 的各種元數據，比如事務 ID、版本號、時間戳、大小等等。
- child：當前節點的子節點引用
注：
Zookeeper 是爲讀多寫少的場景所設計。
Znode 並不是用來存儲大規模業務數據，而是用於存儲少量的狀態和配置信息**，每個節點的數據最大不能超過 1MB**。避免被當做數據庫來使用，儘管Zookeeper具有一致性。
3、Zookeeper 的基本操作
創建節點
create
刪除節點
delete
判斷節點是否存在
exists
獲得一個節點的數據
getData
設置一個節點的數據
setData
獲取節點下的所有子節點
getChildren
這其中，exists，getData，getChildren 屬於讀操作。
但是，業務中一旦和寫操作有了掛鉤，就會和事務產生關係。
Zookeeper 客戶端在請求讀操作的時候，可以選擇是否設置 Watch
4、Zookeeper 的事務通知
可以把 Watch 理解成是註冊在特定 Znode 上的觸發器。
當這個 Znode 發生改變，也就是調用了 create，delete，setData 方法的時候，將會觸發 Znode 上註冊的對應事件，請求 Watch 的客戶端會接收到異步通知。
5、Zookeeper 的一致性
Zookeeper 身爲分佈式系統協調服務，如果自身掛了如何處理呢？
爲了防止單機掛掉的情況，Zookeeper 維護了一個集羣。（避免單點故障）
Zookeeper Service 集羣是一主多從結構。
在更新數據時，首先更新到主Zookeeper Service，再同步到從Zookeeper Service。
在讀取數據時，直接讀取任意從Zookeeper Service。
爲了保證主從節點的數據一致性，Zookeeper 採用了 ZAB 協議，這種協議非常類似於一致性算法 Paxos 和 Raft。
6、ZAB 協議
Zookeeper（動物園管理員） Atomic原子的） Broadcast（ 廣播; 散佈，傳播），
有效解決了 Zookeeper 集羣崩潰恢復，以及主從同步數據的問題。
ZAB 協議定義的三種節點狀態
- Looking ：選舉狀態。
- Following ：Follower 節點（從節點）所處的狀態。
- Leading ：Leader 節點（主節點）所處狀態
ZAB 協議既不是強一致性，也不是弱一致性，而是處於兩者之間的單調一致性（順序一致性）。
它依靠事務 ID 和版本號，保證了數據的更新和讀取是有序的。
7、Zookeeper 集羣崩潰恢復
（類似於redis的主從複製，只是類似）
假如Zookeeper 集羣的主Zookeeper server 掛了，集羣會進行崩潰恢復。
1、選舉階段，就是所有的 子Zookeeper server 進行投票選舉。（此時所有的子服務的狀態都爲 Looking ：選舉狀態）
2、選票大於半數的子Zookeeper server，成爲Leader領導者,（Leading ：Leader 節點（主節點）所處狀態），其他的子服務爲Follower跟隨者， （Following ：Follower 節點（從節點）所處的狀態）
3、leader服務，從其他的子服務中，尋找發現，最新的 ZXID 和事務日誌。並對自身進行更新。
4、把 Leader 剛纔收集得到的最新歷史事務日誌，同步給集羣中所有的 Follower。只有當半數 Follower 同步成功，這個準 Leader 才能成爲正式的 Leader。