ZooKeeper系列（1）--分佈式系統的基石

分佈式架構有如下幾點普適性的共性需求：

• 提供集羣的集中化的配置管理功能，能夠不重啓就讓新的配置參數生效，相似與配置中心

• 簡單可靠的集羣節點動態發現機制，便於動態發現服務，動態擴展節點

• 簡單可靠的leader選舉機制

• 提供分佈式鎖

zookeeper的數據結構總體上能夠看做一顆目錄樹，其中每一個節點被稱做ZNode，每一個Znode均可以經過其路徑（Path）惟一標識，如/services/helloworld。每一個ZNode均可以綁定一個二進制存儲數據（Data），用來存儲少許數據，默認最大1MB。不建議在ZNode中存儲大量的數據，由於數據多份複製，會帶來寬帶壓力，下降性能。

ZNode有一個ACL訪問權限列表，用來決定當前操做API 的用戶是否有操做此節點的權限。ZNode還提供了實時通知的接口--Watch，應用能夠選擇任意ZNode進行監聽，若是被監聽的ZNode或者其Child發生變化，則應用能夠實時收到通知，這樣一來，不少場景和需求都能經過ZooKeeper來實現了。

此外，ZNode是有生命週期的，這取決於節點的類型，節點的類型分爲如下幾類：

• 持久節點： 節點建立後就一直存在，直到有刪除操做來主動刪除該節點

• 臨時節點： 臨時節點的生命週期和建立該節點的客戶端會話綁定，即若是客戶端會話失效（客戶端宕機或下線），這個節點自動刪除

• 時序節點： 建立節點是能夠設置這個屬性，ZooKeeper會自動爲給定的節點加上一個數字後綴，做爲新的節點名。數字後綴的範圍是整型的最大值

• 臨時性時序節點： 同時具有臨時節點與時序節點的特性，主要用於分佈式鎖的實現

從上面的分析來看，持久節點主要用於保存持久化數據，如集羣的配置信息，結合Watch特性，實現配置的實時生效。

臨時節點能夠實現複雜的動態服務發現和服務路由功能。一般的作法是，分佈式集羣不一樣服務器上的服務註冊到同一個ZooKeeper上，並在某個指定的路徑下建立各自對應的臨時節點，如/serviceA/node1, /serviceA/node2，客戶端則監聽/service目錄。當有新的節點加入集羣時，ZooKeeper會把變化實時通知到全部客戶端，客戶端就能夠及時更新本身的服務路由轉發表，實現全自動透明的服務發現和服務路由功能。

時序類型的節點，在建立時，每一個節點名都會被追加一個遞增的序號，相似於數據庫自增主鍵，每一個ZNode都有惟一序號，並且不會衝突。以此能夠實現簡單的Master（Leader）選舉機制。即把一組service實例都註冊爲臨時性時序節點ZNode，每次選取Master時，選取序號最小的爲Master，而當Master宕機時，相應的ZNode會消失，新的服務器列表會推送至客戶端，繼續選舉下一任Master，這樣就作到了動態選舉Master。

ZooKeeper主要用於如下場景：

1. 實現配置管理（配置中心）

2. 服務註冊中心

3. 集羣通訊與控制子系統

做爲服務註冊中心時：

首先服務提供者將自身的服務信息註冊到註冊中心。一般註冊信息包含以下內容：

1. 服務的類型

2. 隸屬於哪一個系統

3. 服務的IP/端口

4. 服務的請求URL

5. 服務的權重

其次註冊中心要將全部服務信息存儲，同時負責將註冊信息的更新推送到全部的消費者（經過Watch機制實現）。

最後，服務消費者只有在初始化及服務變動時會依賴註冊中心，而在整個服務調用過程當中與服務提供方直接通訊，不依賴於任何第三方，包括註冊中心。

**歡迎關注個人微信公衆號：程序員順仔