分散式架構有以下幾點普適性的共性需求： 1. 提供集群的集中化的配置管理功能，可以不重啟就讓新的配置參數生效，類似與配置中心 2. 簡單可靠的集群節點動態發現機制，便於動態發現服務，動態擴展節點 3. 簡單可靠的leader選舉機制 4. 提供分散式鎖 zookeeper的數據結構整體上可以看作一顆 ...
分散式架構有以下幾點普適性的共性需求：
1. 提供集群的集中化的配置管理功能，可以不重啟就讓新的配置參數生效，類似與配置中心
2. 簡單可靠的集群節點動態發現機制，便於動態發現服務，動態擴展節點
3. 簡單可靠的leader選舉機制
4. 提供分散式鎖
zookeeper的數據結構整體上可以看作一顆目錄樹，其中每個節點被稱作ZNode，每個Znode都可以通過其路徑（Path）唯一標識，如/services/helloworld。每個ZNode都可以綁定一個二進位存儲數據（Data），用來存儲少量數據，預設最大1MB。不建議在ZNode中存儲大量的數據，因為數據多份複製，會帶來寬頻壓力，降低性能。
ZNode有一個ACL訪問許可權列表，用來決定當前操作API 的用戶是否有操作此節點的許可權。ZNode還提供了實時通知的介面--Watch，應用可以選擇任意ZNode進行監聽，如果被監聽的ZNode或者其Child發生變化，則應用可以實時收到通知，這樣一來，很多場景和需求都能通過ZooKeeper來實現了。
此外，ZNode是有生命周期的，這取決於節點的類型，節點的類型分為以下幾類：
1. 持久節點：節點創建後就一直存在，直到有刪除操作來主動刪除該節點
2. 臨時節點：臨時節點的生命周期和創建該節點的客戶端會話綁定，即如果客戶端會話失效（客戶端宕機或下線），這個節點自動刪除
3. 時序節點：創建節點是可以設置這個屬性，ZooKeeper會自動為給定的節點加上一個數字尾碼，作為新的節點名。數字尾碼的範圍是整型的最大值
4. 臨時性時序節點：同時具備臨時節點與時序節點的特性，主要用於分散式鎖的實現
從上面的分析來看，持久節點主要用於保存持久化數據，如集群的配置信息，結合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機制實現）。
最後，服務消費者只有在初始化及服務變更時會依賴註冊中心，而在整個服務調用過程中與服務提供方直接通信，不依賴於任何第三方，包括註冊中心。
歡迎關註我的微信公眾號（Sunnick，請掃碼關註），隨時留言交流~
