————— 第二天 —————
————————————
ZooKeeper 的數據模型
ZooKeeper 的數據模型是什麼樣子呢？它很像數據結構當中的樹，也很像文件系統的目錄。
樹是由節點所組成，ZooKeeper 的數據存儲也同樣是基於節點，這種節點叫做Znode。
但是，不同於樹的節點，Znode 的引用方式是路徑引用，類似於文件路徑：
/ 動物 / 倉鼠
/ 植物 / 荷花
這樣的層級結構，讓每一個 Znode 節點擁有唯一的路徑，就像命名空間一樣對不同信息作出清晰的隔離。
data：Znode 存儲的數據信息。
ACL：記錄 Znode 的訪問權限，即哪些人或哪些 IP 可以訪問本節點。
stat：包含 Znode 的各種元數據，比如事務 ID、版本號、時間戳、大小等等。
child：當前節點的子節點引用，類似於二叉樹的左孩子右孩子。
這裏需要注意一點，ZooKeeper 是為讀多寫少的場景所設計。Znode 並不是用來存儲大規模業務數據，而是用於存儲少量的狀態和配置信息，每個節點的數據最大不能超過 1MB。
ZooKeeper 的基本操作和事件通知
ZooKeeper 包含了哪些基本操作呢？這裏列舉出比較常用的 API：
create：創建節點
delete：刪除節點
exists：判斷節點是否存在
getData：獲得一個節點的數據
setData：設置一個節點的數據
getChildren：獲取節點下的所有子節點
這其中，exists、getData、getChildren 屬於讀操作。ZooKeeper 客戶端在請求讀操作的時候，可以選擇是否設置 Watch。
Watch 是什麼意思呢？
我們可以理解成是注冊在特定 Znode 上的觸發器。當這個 Znode 發生改變，也就是調用了 create、delete、setData 方法的時候，將會觸發 Znode 上注冊的對應事件，請求 Watch 的客戶端會接收到異步通知。
具體交互過程如下：
1. 客戶端調用 getData 方法，Watch 參數是 true。服務端接到請求，返回節點數據，並且在對應的哈希表裏插入被 Watch 的 Znode 路徑，以及 Watcher 列表。
2. 當被 Watch 的 Znode 已刪除，服務端會查找哈希表，找到該 Znode 對應的所有 Watcher，異步通知客戶端，並且刪除哈希表中對應的 Key-Value。
ZooKeeper 的一致性
ZooKeeper 的集群長成什麼樣呢？就像下圖這樣：
ZooKeeper Service 集群是一主多從結構。
更新數據時，首先更新到主節點（這裏的節點是指服務器，不是 Znode），再同步到從節點。
在讀取數據時，直接讀取任意從節點。
為了保證主從節點的數據一致性，ZooKeeper 采用了ZAB 協議，這種協議非常類似於一致性算法 Paxos 和 Raft。
在學習 ZAB 之前，我們需要首先了解 ZAB 協議所定義的叁種節點狀態：
Looking：選舉狀態。
Following：Follower 節點（從節點）所處的狀態。
Leading：Leader 節點（主節點）所處狀態。
我們還需要知道最大 ZXID 的概念：
最大 ZXID 也就是節點本地的最新事務編號，包含 epoch 和計數兩部分。epoch 是紀元的意思，相當於 Raft 算法選主時候的 term。
假如 ZooKeeper 當前的主節點掛掉了，集群會進行崩潰恢複。ZAB 的崩潰恢複分成叁個階段：
