了解Zookeeper的我們都知道，Zookeeper是一種分布式協調服務，在分布式應用中，主要用來實現分布式服務的注冊與發現以及分布式鎖，本文我們簡單介紹一下Zookeeper是如何實現服務的注冊與發現的。
使用Zookeeper實現服務注冊與發現，主要應用的是Zookeeper的Znode數據模型和Watcher機制，因此咱們先從Zookeeper的數據模型說起。
1、Zookeeper數據模型
Zookeeper的數據模型，有點類似咱們數據結構中的樹形結構，也有點類似我們操作系統的目錄結構，數據模型結構圖大致如下；
樹由節點組成，Zookeeper的數據存儲也是基於節點，數據模型中的每一個節點，Zookeeper稱之為Znode。但是與樹的節點不同的是，Zookeeper中Znode的引用方式是路徑引用，即是通過類似於目錄文件訪問的形式引用節點數據。
如上圖要在“汽車”節點下再創建一個“奧迪”節點，創建方式為：
create /汽車/奧迪
1
要獲取“汽車”節點下的節點“寶馬”的數據，獲取方式為：
get /汽車/寶馬
1
基於目錄的結構讓每一個Znode節點擁有了唯一的路徑，就像我們Java中的命名空間一樣，對不同的信息就做出了清晰的隔離。
一個Znode里面主要包含了如下的一些數據：
data : Znode存儲的數據；
ACL：記錄 Znode 的訪問權限，即哪些人或哪些 IP 可以訪問本節點；
stat：包含Znode的各種源數據，包括ZXID、版本號、時間戳、數據長度等；
child：子節點引用；
2、Zookeeper的Watch機制
我們可以將Watch理解成是一個和指定Znode所綁定的監聽器，當這個Znode發生變化，也就是在這個Znode上進行了數據的寫操作（create、delete、setData），這個監聽器監聽到這些寫操作之后會異步向請求Watch的客戶端發送通知。
具體交互流程大致如下：
客戶端調用getData方法向服務器獲取某個Znode節點的數據時，設置watch為true。服務端接到請求后，返回節點的數據，並在維護的WatchTable中插入被Watch的Znode路徑以及Watcher（watch該Znode的客戶端）；
當被Watch的Znode被刪除或者更新之后，Zookeeper服務器會查找Watch Table，找到在Znode上對應的所有Watcher，異步通知對應的客戶端，並且刪除Watch Table中對應的Key：Value；
3、Zookeeper服務注冊與發現流程淺析
Zookeeper的服務注冊與發現，主要應用的是Zookeeper的Znode數據模型和Watcher機制，主要分為如下幾個步驟：
服務注冊：服務提供者（Provider）啟動時，會向Zookeeper服務端注冊服務信息，即會在Zookeeper服務器上創建一個服務節點，並在節點上存儲服務的相關數據（如服務提供者的ip地址、端口等），比如注冊一個用戶注冊服務（user/register）:
服務發現：服務消費者（Consumer）啟動時，會根據本身依賴的服務信息，向Zookeeper服務端獲取注冊的服務信息並設置Watch，獲取到注冊的服務信息之后將服務提供者信息緩存在本地，調用服務時直接根據從Zookeeper注冊中心獲取到的服務注冊信息調用服務，比如發現用戶注冊服務（user/register）並調用。
服務通知：當服務提供者因為某種原因宕機或不提供服務之后，Zookeeper服務注冊中心的對應服務節點會被刪除，因為服務消費者在獲取服務信息的時候在對應節點上設置了Watch，因此節點刪除之后會觸發對應的Watcher，Zookeeper注冊中心會異步向服務所關聯的所有服務消費者發出節點刪除的通知，服務消費者根據收到的通知更新緩存的服務列表。
4、小結
本文我們簡單介紹了Zookeeper實現服務注冊與發現的簡單原理，利用 Znode 和 Watcher，可以實現分布式服務的注冊和發現。最著名的應用就是阿里的分布式 RPC 框架 Dubbo，希望對大家有幫助。
————————————————
版權聲明：本文為CSDN博主「RonTech」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/zyhlwzy/article/details/101847565