Dubbo之旅--註冊中心

在介紹Dubbo的內部邏輯的時候提到不少次註冊中心的概念.實現註冊中心的有不少,主要是如下四個註冊中心分別是:

 

Multicast註冊中心

Zookeeper註冊中心

Redis註冊中心

Simple註冊中心

 

      這裏將對註冊中心的一個實現Zookeeper跟你們分享,由於Zookeeper是應用比較多,也是咱們項目中實際用到的註冊中心.

      

       ZooKeeper 是一個爲分佈式應用所設計的分佈的、開源的協調服務。分佈式的應用能夠創建在同步、配置管理、分組和命名等服務的更高級別的實現的基礎之上。 ZooKeeper 意欲設計一個易於編程的環境，它的文件系統使用咱們所熟悉的目錄樹結構。 ZooKeeper 使用 Java 所編寫，可是支持 Java 和 C 兩種編程語言。

    協調服務是很是容易出錯的， 同時也很難恢復正常，例如，協調服務很容易處於競態以致於出現死鎖。 ZooKeeper 的目的是爲了減輕分佈式應用程序所承擔的協調任務。

 

     ZooKeeper命名空間

 

     提供的命名空間與標準的文件系統很是類似。一個名稱是由經過斜線分隔開的路徑名序列所組成的。ZooKeeper中的每個節點是都經過路徑來識別。獲取下載地址   最主流的Java後臺 SSM 框架 springmvc spring mybatis 項目

下圖是Zookeeper中節點的數據模型，這種樹形結構的命名空間操做方便且易於理解。

 

 

 

                                 圖:ZooKeeper層次命名空間

 

 

         接着上圖中,咱們須要瞭解一下ZooKeeper中的節點和臨時節點

 

         ZooKeeper的節點是經過像樹同樣的結構來進行維護的，而且每個節點經過路徑來標示以及訪問。除此以外，每個節點還擁有自身的一些信息，包括：數據、數據長度、建立時間、修改時間等等。

 

          從這樣一類既含有數據，又做爲路徑表標示的節點的特色中，能夠看出，ZooKeeper的節點既能夠被看作是一個文件，又能夠被看作是一個目錄，它同時具備兩者的特色。爲了簡單咱們能夠Znode來表示所討論的ZooKeeper節點。

 

         具體地說，Znode維護着數據、ACL（access controllist，訪問控制列表）、時間戳等交換版本號等數據結構，它經過對這些數據的管理來讓緩存生效而且令協調更新。每當Znode中的數據更新後它所維護的版本號將增長，這很是相似於數據庫中計數器時間戳的操做方式。

 

         另外Znode還具備原子性操做的特色：命名空間中，每個Znode的數據將被原子地讀寫。讀操做將讀取與Znode相關的全部數據，寫操做將替換掉全部的數據。除此以外，每個節點都有一個訪問控制列表，這個訪問控制列表規定了用戶操做的權限。

 

       ZooKeeper中一樣存在臨時節點。這些節點與session同時存在，當session生命週期結束，這些臨時節點也將被刪除。臨時節點在某些場合也發揮着很是重要的做用。

 

         瞭解了Zookeeper的命名空間和節點以後咱們須要跟上一篇文章中提到的內部邏輯聯繫起來.在上篇介紹到的內部流程中,拿到這裏看看Zookeeper是如何處理的,流程以下圖:

 

 

 

 

   1  當服務提供者啓動時,Zookeeper向/dubbo/com.foo.BarService/providers目錄下寫入本身的URL地址。

 

   2 當服務消費者啓動時,這時候有兩個動做:

訂閱/dubbo/com.foo.BarService/providers目錄下的提供者URL地址。

並向/dubbo/com.foo.BarService/consumers目錄下寫入本身的URL地址。

 

  3當監控中心啓動時,訂閱/dubbo/com.foo.BarService目錄下的全部提供者和消費者URL地址。

​