前言

在分布式系統中，注冊中心充當著重要角色，是服務發現、客戶端負載均衡中不可缺少的一員。注冊中心除了能夠實現基本的功能外，它的穩定性、可用性和健壯性對整個分布式系統的流暢運行影響重大。dubbo作為國內一款主流的分布式系統，支持的注冊中心有zookeeper、nacos和redis等第三方中間件。

高并發分布式開發技術體系已然非常的龐大，前段時間一直在準備找工作，參加面試，通過面試的情況可以發現RPC、Dubbo、zookeeper、nacos、分布式、微服務等這些已經成為了找工作的最基礎的技能要求了。

之前有篇文章介紹到了如何使用nacos作為注冊中心：SpringCloud：搭建Nacos服務以及服務發現。其實不僅僅nacos可以作為注冊中心，zookeeper也可以作為注冊中心使用。但是Zookeeper其實不僅僅可以作為注冊中心。

對于Zookeeper，其官方文檔上的解釋是：它是一個分布式服務框架，是Apache Hadoop 的一個子項目，它主要是用來解決分布式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集群管理、分布式應用配置項的管理等。可以理解為zookeeper是文件系統+監聽通知機制。

今天這篇文章就一起來學習學習Zookeeper，我自己也是學習的過程！

什么是zookeeper

隨著系統應用的拓展和數據量的保證，我們的系統經常會遇到這些情況：

• 怎么保證一個服務器集群中的所有服務器保持共享的配置信息的一致性？
• 如果服務器集群中有一臺機器掛掉了，其他機器如何感知到這一變化并接管任務？
• 對于分布式系統，如何高效協同多臺服務對同一網絡文件進行寫操作并保持一致性？
• 如何做到不重啟集群而完成機器的添加？
• ........

為了解決上述的問題，就需要一個類似于線程協同機制的工具，讓各個服務進行協同工作。而zookeeper就是這樣的一類工具。

上面說到對于Zookeeper，其官方文檔上的解釋是：它是一個分布式服務框架，是Apache Hadoop 的一個子項目，它主要是用來解決分布式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集群管理、分布式應用配置項的管理等。

所以可以理解為zookeeper是一種可以用于分布式應用的高性能協調服務，它的數據是存于內存中的，并且持久化實現在日志中。而它的內存結構是類似于樹形結構，具有高吞吐低延遲的特點。zookeeper不僅僅可以幫助我們實現分布式統一配置中心，服務注冊，分布式鎖等，它們維護內存中的狀態圖像，以及持久性存儲中的事務日志和快照。只要大多數服務器可用，ZooKeeper服務就可用。客戶端連接到單個ZooKeeper服務器。客戶端維護TCP連接，通過該連接發送請求，獲取響應，獲取監視事件以及發送tick。如果與服務器的TCP連接中斷，則客戶端將連接到其他服務器。所以可以簡單地認為zookeeper=文件系統+監聽通知機制。

我們還可以這樣理解：zookeeper的中文意思就是動物園管理員（zoom+keeper）。動物園管理員的作用就是負責管理動物園里面的動物，讓它們井然有序。而zookeeper是apache下的開源項目，在apache下的很多開源項目其實都是以動物作為圖標的，比如Hadoop(大象)，Hive(蜜蜂)，Pig(小豬)、tomcat(貓)。

所以可以記憶成apache下的項目就是動物園，而zookeeper就是負責管理這些動物（開源項目）的動物管理員。

zookeeper的數據結構

zookeeper 會維護一個具有層次關系的數據結構，它非常類似于一個標準的文件系統：

上圖中的樹形結構中的每個節點(目錄項)，比如NameService 都被稱作為 znode(目錄節點)。zonde通過路徑引用，路徑必須是絕對的，因此他們必須由斜杠字符來開頭。除此以外，它們必須是唯一的，也就是說每一個路徑只有一個表示，因此這些路徑不能改變。在zookeeper中，路徑由Unicode字符串組成，并且有一些限制。字符串"/ZooKeeper"用以保存管理信息，比如關鍵配額信息。

znode同時具有文件和目錄兩種特點。既像文件一樣維護著數據、元信息、訪問控制列表）、時間戳等數據結構，又可以像目錄一樣可以作為路徑標識的一部分，能夠自由的增加、刪除znode。

每個znode都是由三部分組成:

• stat：此為狀態信息, 描述該znode的版本, 權限等信息
• data：與該znode關聯的數據
• children：該znode下的子節點

需要注意的是同一個節點下的子節點名稱不能相同，且命名是有規范的，它的路徑是沒有相對路徑的概念的，都是絕對路徑，任何開始都以"/"開始，最后就是，它存放數據的大小是有限制的。

zookeeper的節點類型

zookeeper中的節點有兩種，分別為臨時節點（Ephemeral Node）和永久節點(Persistent Node)。節點的類型在創建時即被確定，并且不能改變。

兩種節點的區別在于是否依賴于會話（Session）而生存。客戶端和ZooKeeper服務器的一次連接稱為一次會話。客戶端靠與服務器建立一個TCP的長連接來維持一個會話，客戶端在啟動的時候首先會與服務器建立一個TCP連接，通過這個連接客戶端能夠通過心跳檢測與服務器保持有效的會話，也能向ZooKeeper服務器發送請求并獲得響應。

（1）臨時節點：該節點的生命周期依賴于創建它們的會話。一旦會話結束，臨時節點將被自動刪除，當然也可以手動刪除。雖然每個臨時的Znode都會綁定到一個客戶端會話，但他們對所有的客戶端還是可見的。另外，zookeeper的臨時節點不允許擁有子節點。臨時節點又可以細分為：臨時目錄節點和臨時順序編號目錄節點。

• 臨時目錄節點（EPHEMERAL）：客戶端與zookeeper斷開連接后，該節點被刪除。
• 臨時順序編號目錄節點（EPHEMERAL_SEQUENTIAL）：客戶端與zookeeper斷開連接后，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號。

（2）永久節點：該節點的生命周期不依賴于會話，并且只有在客戶端執行刪除操作的時候，他們才能被刪除。臨時節點又可以細分為：持久目錄節點和持久順序編號目錄節點。

• 持久化目錄節點（PERSISTENT）：客戶端與zookeeper斷開連接后，該節點依舊存在。
• 持久化順序編號目錄節點（PERSISTENT_SEQUENTIAL）：客戶端與zookeeper斷開連接后，該節點依舊存在，只是zookeeper給該節點名稱進行順序編號。

上面的分類有個概念叫順序節點：在創建節點的時候，用戶可以請求在zooKeeper的路徑結尾添加一個遞增的計數。這個計數對于此節點的父節點來說是唯一的，當客戶端請求創建這個節點后，zookeeper會根據父節點的zxid狀態，為這個節點編寫一個全目錄唯一的編號，并且這個編號只會一直增長。這樣的節點稱為順序節點。

這上面又提到了一個概念叫zxid：對于改變zookeeper節點狀態的每一個操作都將使這個節點接收到一個Zxid格式的時間戳，并且這個時間戳全局有序。可以理解為每個改變對節點的操作都會產生一個唯一的事務id叫做Zxid。如果Zxid1的值小于Zxid2的值，那么就可以認為Zxid1所對應的事件發生在Zxid2所對應的事件之前。其實，zookeeper的每個節點都維護著兩個Zxid值，分別是：cZxid、mZxid。

• cZxid：指的是節點的創建時間所對應的Zxid格式時間戳。
• mZxid：指的是節點的修改時間所對應的Zxid格式時間戳。

實現中Zxid是一個64位的數字，它高32位是epoch（投票）用來標識Leader關系是否改變，每次一個Leader被選出來，它都會有一個新的epoch。而第32位就是個遞增計數。

zookeeper的特點

1、有序性

zookeeper提供了多種方式跟蹤時間，zookeeper給每個更新貼上一個數字（前面說的zxid），這個數字反映了所有zookeeper事務的順序，嚴格的順序意味著可以在客戶機上實現復雜的同步。除了上面說到的zxid，還有version、zoo.cfg中ticks配置。

version numbers（版本號）：版本號是用來記錄節點數據或者是節點的子節點列表或者是權限信息的修改次數。如果一個節點的version是1，那就代表說這個節點從創建以來被修改了一次。

每個節點維護著三個版本號，他們分別為：

• version：節點數據版本號。
• cversion：子節點版本號。
• aversion：節點所擁有的ACL版本號。

對節點的寫請求都會導致該節點的3種版本號增加，原理和樂觀鎖差不多。

ticks ：zoo.cfg文件中的配置。當使用多服務器zookeeper時，服務器使用一個“滴答”來定義事件的時間，如狀態上傳，會話超時等，它通過最小會話超時（默認是滴答時間x2）間接公開，如果客戶端請求超過這個時間，那客戶端就不再能連接上服務器端。

real time：zookeeper并不使用真實時間。

所以可以理解為zookeeper是一個協調者，使得一些交互連接有序進行！

速度快。

前面提到了zookeeper的數據加載在內存中，所以它具有高吞吐和低延遲的效果。并且以讀取為事務速度尤其快，而且操作的znode大小限制在1m。正是這些特點，使得zookeeper可以適用于大型的分布式系統。

2、可復制

zookeeper的數據是可復制，可備份的。zookeeper可以快速地搭建一個集群，內部自帶了這樣的一些工具與機制，我們只需要設置一些配置即可，保證服務可靠，所以不會成為單點故障。如下：

watcher機制

zookeeper允許用戶在指定節點上注冊一些Watcher，當數據節點發生變化的時候，zookeeper服務器會把這個變化的通知發送給感興趣的客戶端。這個是zookeeper的核心特性，zookeeper的很多功能都是基于這個特性實現的。

如果有兩個客戶端都在zookeeper集群中注冊了watcher（事件監聽器），那么當zookeeper中的節點數據發生變化的時候，zookeeper會把這一變化的通知發送給客戶端，當客戶端收到這個變化通知的時候，會觸發某些提前定義好的動作。一般來說，zookeeper會向客戶端發送且僅發送一條通知，如果一個watch同時注冊了多個接口（exists,getData）,如果此時刪除節點，雖然這個事件對exists和getData都有效，但是watch只會被調用一次。并且這些請求有可能存在延時，所以不能絕對可靠得到每個節點發生的每個更改。watch觸發后會立即刪除，要持續監聽變化的話就需要持續提供設置watch。并且客戶端先得到watch通知才可查看變化結果。

觸發watch事件的條件有4種，create，delete，change，child（子節點事件）。

所以可以總結zookeeper的特點如下：

1、原子性(Atomicity)，更新成功或失敗。沒有部分結果。

2、可靠性：數據的變更不會丟失，除非被客戶端覆蓋修改。

3、實時性：系統的客戶端當時讀取到的數據是最新的。

4、有序性：客戶端的操作都是按照順序生效的。

5、一致性：又叫單個系統映像，無論連接的是哪個服務器，客戶端看到的內容都是相同的。

總結

上述就是關于zookeeper的簡單介紹。自己也是一個學習的過程。總結了一些關于zookeeper的概念和相關知識點。