文章目錄
推薦閱讀
什麼是ZooKeeper?
ZooKeeper 是一種分佈式協調服務，用於管理大型主機。在分佈式環境中協調和管理服務是一個複雜的過程。ZooKeeper 通過其簡單的架構和 API 解決了這個問題。ZooKeeper 允許開發人員專注於核心應用程序邏輯，而不必擔心應用程序的分佈式特性。
ZooKeeper提供的常見服務
- 命名服務 - 按名稱標識集羣中的節點。它類似於DNS，但僅對於節點。
- 配置管理 - 加入節點的最近的和最新的系統配置信息。
- 集羣管理 - 實時地在集羣和節點狀態中加入/離開節點。
- 選舉算法 - 選舉一個節點作爲協調目的的leader。
- 鎖定和同步服務 - 在修改數據的同時鎖定數據。此機制可幫助你在連接其他分佈式應用程序（如Apache HBase）時進行自動故障恢復。
- 高度可靠的數據註冊表 - 即使在一個或幾個節點關閉時也可以獲得數據。
Zookeeper 的數據模型
- 它很像數據結構當中的樹，也很像文件系統的目錄。
- 樹是由節點所組成，Zookeeper 的數據存儲也同樣是基於節點，這種節點叫做 Znode。但是，不同於樹的節點，Znode 的引用方式是路徑引用，類似於文件路徑。這樣的層級結構，讓每一個 Znode 節點擁有唯一的路徑，就像命名空間一樣對不同信息作出清晰的隔離。
Znode 包含哪些元素
- data：Znode 存儲的數據信息。
- ACL：記錄 Znode 的訪問權限，即哪些人或哪些 IP 可以訪問本節點。
- stat：包含 Znode 的各種元數據，比如事務 ID、版本號、時間戳、大小等等。
- child：當前節點的子節點引用
注意：Zookeeper 是爲讀多寫少的場景所設計。Znode 並不是用來存儲大規模業務數據，而是用於存儲少量的狀態和配置信息，每個節點的數據最大不能超過 1MB。
Znode的類型
- Znode被分爲持久（persistent）節點，順序（sequential）節點和臨時（ephemeral）節點。
- 持久節點 - 即使在創建該特定znode的客戶端斷開連接後，持久節點仍然存在。默認情況下，除非另有說明，否則所有znode都是持久的。
- 臨時節點 - 客戶端活躍時，臨時節點就是有效的。當客戶端與ZooKeeper集合斷開連接時，臨時節點會自動刪除。因此，只有臨時節點不允許有子節點。如果臨時節點被刪除，則下一個合適的節點將填充其位置。臨時節點在leader選舉中起着重要作用。
- 順序節點 - 順序節點可以是持久的或臨時的。當一個新的znode被創建爲一個順序節點時，ZooKeeper通過將10位的序列號附加到原始名稱來設置znode的路徑。例如，如果將具有路徑 /myapp 的znode創建爲順序節點，則ZooKeeper會將路徑更改爲 /myapp0000000001 ，並將下一個序列號設置爲0000000002。如果兩個順序節點是同時創建的，那麼ZooKeeper不會對每個znode使用相同的數字。順序節點在鎖定和同步中起重要作用。
ZooKeeper的架構
- ZooKeeper的“客戶端-服務器架構”
![在這裏插入圖片描述]()
- 每個組件的描述
| 部分 | 描述 |
|---|---|
| Client | 客戶端，我們的分佈式應用集羣中的一個節點，從服務器訪問信息。對於特定的時間間隔，每個客戶端向服務器發送消息以使服務器知道客戶端是活躍的。類似地，當客戶端連接時，服務器發送確認碼。如果連接的服務器沒有響應，客戶端會自動將消息重定向到另一個服務器。 |
| Server | 服務器，我們的ZooKeeper總體中的一個節點，爲客戶端提供所有的服務。向客戶端發送確認碼以告知服務器是活躍的。 |
| Ensemble | ZooKeeper服務器組。形成ensemble所需的最小節點數爲3。 |
| Leader | 服務器節點，如果任何連接的節點失敗，則執行自動恢復。Leader在服務啓動時被選舉。 |
| Follower | 跟隨leader指令的服務器節點。 |
Zookeeper 的基本操作
- 創建節點
create - 刪除節點
delete - 判斷節點是否存在
exists - 獲得一個節點的數據
getData - 設置一個節點的數據
setData - 獲取節點下的所有子節點
getChildren
exists，getData，getChildren 屬於讀操作。
- Zookeeper 客戶端在請求讀操作的時候，可以選擇是否設置 Watch。
Watches（監視）
- 監視是一種簡單的機制，使客戶端收到關於ZooKeeper集合中的更改的通知。客戶端可以在讀取特定znode時設置Watches。Watches會向註冊的客戶端發送任何znode（客戶端註冊表）更改的通知。
- Znode更改是與znode相關的數據的修改或znode的子項中的更改。只觸發一次watches。如果客戶端想要再次通知，則必須通過另一個讀取操作來完成。當連接會話過期時，客戶端將與服務器斷開連接，相關的watches也將被刪除。
Sessions（會話）
- 會話對於ZooKeeper的操作非常重要。會話中的請求按FIFO順序執行。一旦客戶端連接到服務器，將建立會話並向客戶端分配會話ID 。
- 客戶端以特定的時間間隔發送心跳以保持會話有效。如果ZooKeeper集合在超過服務器開啓時指定的期間（會話超時）都沒有從客戶端接收到心跳，則它會判定客戶端死機。
- 會話超時通常以毫秒爲單位。當會話由於任何原因結束時，在該會話期間創建的臨時節點也會被刪除。
Zookeeper 工作流
- 一旦ZooKeeper集合啓動，它將等待客戶端連接。客戶端將連接到ZooKeeper集合中的一個節點。它可以是leader或follower節點。一旦客戶端被連接，節點將向特定客戶端分配會話ID並向該客戶端發送確認。如果客戶端沒有收到確認，它將嘗試連接ZooKeeper集合中的另一個節點。 一旦連接到節點，客戶端將以有規律的間隔向節點發送心跳，以確保連接不會丟失。
- 如果客戶端想要讀取特定的znode，它將會向具有znode路徑的節點發送讀取請求，並且節點通過從其自己的數據庫獲取來返回所請求的znode。爲此，在ZooKeeper集合中讀取速度很快。
- 如果客戶端想要將數據存儲在ZooKeeper集合中，則會將znode路徑和數據發送到服務器。連接的服務器將該請求轉發給leader，然後leader將向所有的follower重新發出寫入請求。如果只有大部分節點成功響應，而寫入請求成功，則成功返回代碼將被髮送到客戶端。 否則，寫入請求失敗。絕大多數節點被稱爲 Quorum 。
![在這裏插入圖片描述]()
| 組件 | 描述 |
|---|---|
| 寫入（write） | 寫入過程由leader節點處理。leader將寫入請求轉發到所有znode，並等待znode的回覆。如果一半的znode回覆，則寫入過程完成。 |
| 讀取（read） | 讀取由特定連接的znode在內部執行，因此不需要與集羣進行交互。 |
| 複製數據庫（replicated database） | 它用於在zookeeper中存儲數據。每個znode都有自己的數據庫，每個znode在一致性的幫助下每次都有相同的數據。 |
| Leader | Leader是負責處理寫入請求的Znode。 |
| Follower | follower從客戶端接收寫入請求，並將它們轉發到leader znode。 |
| 請求處理器（request processor） | 只存在於leader節點。它管理來自follower節點的寫入請求。 |
| 原子廣播（atomic broadcasts） | 負責廣播從leader節點到follower節點的變化。 |
Zookeeper 的一致性
Zookeeper 身爲分佈式系統協調服務，如果自身掛了如何處理呢？
- 爲了防止單機掛掉的情況，Zookeeper 維護了一個集羣。如下圖：
![在這裏插入圖片描述]()
- Zookeeper Service 集羣是一主多從結構。
- 在更新數據時，首先更新到主節點（這裏的節點是指服務器，不是 Znode），再同步到從節點。
- 在讀取數據時，直接讀取任意從節點。
- 爲了保證主從節點的數據一致性，Zookeeper 採用了 ZAB 協議，這種協議非常類似於一致性算法 Paxos 和 Raft。
Zookeeper 的應用場景
分佈式鎖
- 這是雅虎研究員設計 Zookeeper 的初衷。利用 Zookeeper 的臨時順序節點，可以輕鬆實現分佈式鎖。
服務註冊和發現
- 利用 Znode 和 Watcher，可以實現分佈式服務的註冊和發現。最著名的應用就是阿里的分佈式 RPC 框架 Dubbo。
共享配置和狀態信息
- Redis 的分佈式解決方案 Codis，就利用了 Zookeeper 來存放數據路由表和 codis-proxy 節點的元信息。同時 codis-config 發起的命令都會通過 ZooKeeper 同步到各個存活的 codis-proxy。
- 此外，Kafka、HBase、Hadoop，也都依靠Zookeeper同步節點信息，實現高可用。
你知道的越多，你不知道的越多。
有道無術，術尚可求，有術無道，止於術。
如有其它問題，歡迎大家留言，我們一起討論，一起學習，一起進步