在介紹Dubbo的內部邏輯的時候提到很多次註冊中心的概念.實現註冊中心的有很多,主要是以下四個註冊中心分別是: Multicast註冊中心 Zookeeper註冊中心 Redis註冊中心 Simple註冊中心 這裡將對註冊中心的一個實現Zookeeper跟大家分享,因為Zookeeper是應用比較多 ...
在介紹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地址。
