瞭解Zookeeper的我們都知道，Zookeeper是一種分佈式協調服務，在分佈式應用中，主要用來實現分佈式服務的註冊與發現以及分佈式鎖，本文我們簡單介紹一下Zookeeper是如何實現服務的註冊與發現的。
使用Zookeeper實現服務註冊與發現，主要應用的是Zookeeper的Znode數據模型和Watcher機制，因此咱們先從Zookeeper的數據模型說起。
1、Zookeeper數據模型
Zookeeper的數據模型，有點類似咱們數據結構中的樹形結構，也有點類似我們操作系統的目錄結構，數據模型結構圖大致如下；
樹由節點組成，Zookeeper的數據存儲也是基於節點，數據模型中的每一個節點，Zookeeper稱之爲Znode。但是與樹的節點不同的是，Zookeeper中Znode的引用方式是路徑引用，即是通過類似於目錄文件訪問的形式引用節點數據。
如上圖要在“汽車”節點下再創建一個“奧迪”節點，創建方式爲：
create /汽車/奧迪
要獲取“汽車”節點下的節點“寶馬”的數據，獲取方式爲：
get /汽車/寶馬
基於目錄的結構讓每一個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，希望對大家有幫助。