ZooKeepe系列(1)--分佈式系統的基石

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

     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,請掃碼關注),隨時留言交流~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章