深入淺出分佈式框架之註冊中心"Zookeeper"

大家好，我是閒水，每天更新java最新最熱技術，對java感興趣的朋友記得關注一下哦。

今天給大家介紹了一下分佈式架構的一個重要組件 ，就是zookeeper。首先現行最主流的分佈式框架有兩個，一個就是大名鼎鼎的springboot，另一個就是咱們阿里巴巴出品的Dubbo

所以作為一個想走技術路線的程序員必須要掌握兩套分佈式架構，而我們今天講的就是Duboo框架不可或缺的一個組件--註冊中心“zookeeper”。

zookeeper是什麼？

zookeeper是一個基於觀察者模式設計的分佈式服務管理框架，它負責存儲和管理大家都關心的數據，然後接受觀察者的註冊，一旦這些數據的狀態發生變化，Zookeeper就將負責通知已經在Zookeeper上註冊的那些觀察者做出相應的反應，從而實現集群中類似Master/Slave管理模式。

一句話總結zookeeper=類似unix文件系統+通知機制+Znode節點，它的作用就是：服務註冊+分佈式系統的一致性通知協調，

zookeeper怎麼玩

在介紹zookeeper怎麼用之前，我們不得不先了解一下Duboo，Dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，是阿里巴巴SOA服務化治理方案的核心框架，每天為2,000+個服務提供3,000,000,000+次訪問量支持，並被廣泛應用於阿里巴巴集團的各成員站點。

基於Dubbo的zookeeper實現

①統一命名服務（Name Service如Dubbo服務註冊中心)

服務提供者在啟動的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的發佈。

服務消費者啟動的時候，訂閱/dubbo/${serviceName}/providers目錄下的提供者URL地址，向/dubbo/${serviceName} /consumers目錄下寫入自己的URL地址。注意，所有向ZK上註冊的地址都是臨時節點，這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化。 另外，Dubbo還有針對服務粒度的監控，方法是訂閱/dubbo/${serviceName}目錄下所有提供者和消費者的信息。

②配置管理（Configuration Management如淘寶開源配置管理框架Diamond）

在大型的分佈式系統中，為了服務海量的請求，同一個應用常常需要多個實例。如果存在配置更新的需求，常常需要逐臺更新，給運維增加了很大的負擔同時帶來一定的風險(配置會存在不一致的窗口期，或者個別節點忘記更新)。zookeeper可以用來做集中的配置管理，存儲在zookeeper集群中的配置，如果發生變更會主動推送到連接配置中心的應用節點，實現一處更新處處更新的效果

現在把這些配置全部放到zookeeper上去，保存在 Zookeeper 的某個目錄節點中，然後所有相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每個應用程序就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置信息應用到系統中就好。

Zookeeper的數據模型--znode節點

zookeeper內部維護了一套類似UNIX的樹形數據結構：由znode構成的集合，

znode的集合又是一個樹形結構，每一個znode又有很多屬性進行描述。 Znode = path + data + Stat

Znode維護了一個stat結構，這個stat包含數據變化的版本號、訪問控制列表變化、還有時間戳。版本號和時間戳一起，可讓Zookeeper驗證緩存和協調更新。每次znode的數據發生了變化，版本號就增加。

例如，無論何時客戶端檢索數據，它也一起檢索數據的版本號。並且當客戶端執行更新或刪除時，客戶端必須提供他正在改變的znode的版本號。如果它提供的版本號和真實的數據版本號不一致，更新將會失敗。

Zookeeper的通知機制

客戶端註冊監聽它關心的目錄節點，當目錄節點發生變化（數據改變、被刪除、子目錄節點增加刪除）時，zookeeper會通知客戶端。

ZooKeeper 支持watch(觀察)的概念。客戶端可以在每個znode結點上設置一個觀察。如果被觀察服務端的znode結點有變更，那麼watch就會被觸發，這個watch所屬的客戶端將接收到一個通知包被告知結點已經發生變化，把相應的事件通知給設置過Watcher的Client端。

watch事件理解

①一次觸發

當數據有了變化時zkserver向客戶端發送一個watch,它是一次性的動作，即觸發一次就不再有效，類似一次性紙杯。只監控一次，如果想繼續Watch的話，需要客戶端重新設置Watcher。因此如果你得到一個watch事件且想在將來的變化得到通知，必須新設置另一個watch。

②異步發往客戶端

Watches是異步發往客戶端的，Zookeeper提供一個順序保證：在看到watch事件之前絕不會看到變化，這樣不同客戶端看到的是一致性的順序。

在（導致觀察事件被觸發的）修改操作的成功返回碼到達客戶端之前，事件可能在去往客戶端的路上，但是可能不會到達客戶端。觀察事件是異步地發送給觀察者（客戶端）的。ZooKeeper會保證次序：在收到觀察事件之前，客戶端不會看到已經為之設置觀察的節點的改動。網絡延遲或者其他因素可能會讓不同的客戶端在不同的時間收到觀察事件和更新操作的返回碼。這裡的要點是：不同客戶端看到的事情都有一致的次序。

③為數據設置watch

節點有不同的改動方式。可以認為ZooKeeper維護兩個觀察列表：數據觀察和子節點觀察。getData()和exists()設置數據觀察。getChildren()設置子節點觀察。此外，還可以認為不同的返回數據有不同的觀察。getData()和exists()返回節點的數據，而getChildren()返回子節點列表。所以，setData()將為znode觸發數據觀察。成功的create()將為新創建的節點觸發數據觀察，為其父節點觸發子節點觀察。成功的delete()將會為被刪除的節點觸發數據觀察以及子節點觀察（因為節點不能再有子節點了），為其父節點觸發子節點觀察。

觀察維護在客戶端連接到的ZooKeeper服 務器中。這讓觀察的設置、維護和分發是輕量級的。客戶端連接到新的服務器時，所有會話事件將被觸發。同服務器斷開連接期間不會收到觀察。客戶端重新連接 時，如果需要，先前已經註冊的觀察將被重新註冊和觸發。通常這都是透明的。有一種情況下觀察事件將丟失：對還沒有創建的節點設置存在觀察，而在斷開連接期 間創建節點，然後刪除。

④時序性和一致性

Watches是在client連接到Zookeeper服務端的本地維護，這可讓watches成為輕量的，可維護的和派發的。當一個client連接到新server，watch將會觸發任何session事件，斷開連接後不能接收到。當客戶端重連，先前註冊的watches將會被重新註冊並觸發。

關於watches，Zookeeper維護這些保證：

（1）Watches和其他事件、watches和異步恢復都是有序的。Zookeeper客戶端保證每件事都是有序派發

（2）客戶端在看到新數據之前先看到watch事件

（3）對應更新順序的watches事件順序由Zookeeper服務所見

掌握了Zookeeper的通知機制+Znode節點就基本掌握了Zookeeper，希望我的文章對你有一些幫助。