1、ZK節點資料
Zookeeper 提供一個多層級的節點名稱空間（節點稱為 znode）。與檔案系統不同的是，這些節點都可以設定關聯的資料，而檔案系統中只有檔案節點可以存放資料而目錄節點不行。Zookeeper 為了保證高吞吐和低延遲，在記憶體中維護了這個樹狀的目錄結構，這種特性使得 Zookeeper 不能用於存放大量的資料，每個節點的存放資料上限為1M。
2、Zookeeper 如何保證分散式資料的一致性特性
Zookeeper 的一些特性和工作原理，包括順序一致性、原子性、單一檢視、可靠性和實時性（最終一致性）。
-
順序一致性： Zookeeper 保證所有的更新操作都是全域性有序的，每個更新都有一個唯一的時間戳（zxid），並且讀請求的返回結果中會帶有最新的 zxid，確保了更新操作的順序性。
-
原子性： 對於寫請求，Zookeeper 會同時將請求傳送給其他 Zookeeper 機器，並在達成一致後才返回成功，保證了寫操作的原子性，即要麼全部寫入成功，要麼全部失敗。因此， 隨著 zookeeper 的叢集機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。
-
單一檢視： Zookeeper 提供了一個單一檢視，即對於所有的客戶端，他們看到的資料都是一致的，這也是 Zookeeper 的可靠性和一致性基礎之一。
-
可靠性： Zookeeper 的可靠性體現在其提供了高可用和容錯性，透過叢集機器的增多，可以提高讀請求的吞吐，同時保證寫請求的可靠性和一致性。
-
實時性（最終一致性）： 對於讀請求，Zookeeper 允許任意一臺機器處理，並且會相對於更新有序，但並不保證實時性，而是保證最終一致性，即資料最終會達到一致狀態。
總體來說，Zookeeper 是一個分散式協調服務，透過其特性保證了資料的一致性、可靠性和順序性，在分散式系統中有著廣泛的應用。
3、zab協議
ZAB（Zookeeper Atomic Broadcast）協議是專門為分散式協調服務 Zookeeper 設計的一種支援崩潰恢復的原子廣播協議。它包括兩種基本模式：崩潰恢復和訊息廣播。
-
崩潰恢復模式： 當整個 Zookeeper 叢集剛啟動、Leader 伺服器當機、重啟或者網路故障導致不存在過半的伺服器與 Leader 伺服器保持正常通訊時，所有程序（伺服器）進入崩潰恢復模式。在該模式下，首先會選舉產生新的 Leader 伺服器，然後叢集中的 Follower 伺服器開始與新的 Leader 伺服器進行資料同步。一旦超過半數的機器與新的 Leader 伺服器完成資料同步，叢集就會退出恢復模式，進入訊息廣播模式。
-
訊息廣播模式： 一旦叢集中超過半數的機器與新的 Leader 伺服器完成資料同步，叢集就會退出恢復模式進入訊息廣播模式。在這個模式下，Leader 伺服器開始接收客戶端的事務請求，並生成事務提案來處理這些請求。
ZAB 協議透過這兩種模式，確保了在 Zookeeper 叢集中保持資料的一致性和可靠性。崩潰恢復模式確保在發生故障或初始啟動時，能夠重新選舉 Leader，並進行資料同步；訊息廣播模式則確保了在叢集正常執行時，能夠處理客戶端的事務請求並保持資料的一致性。