zookeeper是一個高可用的分佈式數據管理與協調框架,基於對ZAB算法的實現,該框架可以很好地保證分佈式環境中數據的一致性。算法
數據發佈/訂閱系統,即配置中心。發佈者將數據發佈到zk上,功訂閱者進行數據訂閱,進而達到動態獲取數據的目的,實現配置信息的集中式管理和數據的動態更新。
發佈/訂閱系統通常有兩種設計模式:推push和拉pull。zk採用推拉結合的方式:客戶端向服務端註冊本身須要關注的節點,一旦該節點的數據發生變動,那麼服務端就會向相應的客戶端發送Watcher事件通知,客戶端收到這個通知以後,須要主動到服務端獲取最新的數據。設計模式
使用場景服務器
適合進行配置管理的信息通常具備如下特色:網絡
使用方式併發
將須要集中管理的配置信息寫到zk的數據節點上,稱爲配置節點負載均衡
集羣中的每臺機器在啓動初始化階段,從zk的配置節點上讀取配置信息,同時在該節點上註冊一個頁遊數據變動的Watcher,一旦節點數據發生變化,全部訂閱的客戶端可以獲取到變動通知框架
系統運行過程當中,若是配置發生變化,客戶端會接收到變動通知後,就能夠從新獲取最新的數據。異步
典型場景:動態DNS服務分佈式
分佈式系統中,被命名的實體一般能夠是集羣中的機器、提供的服務地址或遠程對象。其中較爲常見的就是一些分佈式服務框架中的服務列表。經過使用命名服務,客戶端應用可以經過指定名字來獲取資源的實體、服務地址和提供者的信息等。
zk提供的命名服務功能,可以幫助應用系統經過一個資源引用的方式實現對資源的定位和使用。廣義上命名服務的資源定位不是真正意義的實體資源,在分佈式環境中,上層應用陰影須要一個全局惟一的名字,例如,使用zk實現一套分佈式全局惟一ID的分配也屬於命名服務。ide
zk使用watcher註冊與異步通知機制,可以很好地實現分佈式環境中不一樣的機器,甚至是不一樣系統之間的協調與通知。
使用場景
機器間的心跳檢測是指在分佈式環境中,不一樣機器之間須要檢測到彼此是否在正常運行。傳統的方法是在機器之間創建長鏈接,經過TCP鏈接固有的心跳監測機制實現上層機器的心跳檢測。基於zk的臨時節點特性,可讓不一樣的機器都在zk的一個指定節點下建立臨時子節點,不一樣機器能夠監聽臨時節點來判斷對應的客戶端機器是否存活。經過這種方式,檢測系統和被檢測系統不須要直接關聯,大大減小系統耦合。
集羣管理,包括集羣監控與集羣控制。
傳統的分佈式系統中,經過在集羣中每臺機器上部署一個agent,由agent主動想指定的監控中心繫統上報本身所在的機器狀態。
zk中,使用watcher監聽和臨時節點的特性實現集羣管理。
使用示例
Master選舉,即在集羣的全部機器中選舉出一臺做爲Master。 利用zk的強一致性,即zk將會保證客戶端沒法重複建立一個已經存在的數據節點,來保證高併發下節點的建立能保證全局惟一性。
Master動態選舉的過程大體以下:客戶端集羣在zk上指定節點下建立臨時節點,在這個過程當中,只有一個客戶端能建立成功,那麼這個客戶端所在的機器就成爲了頁遊裏的http://www.sangpi.com/Master。同時,其餘沒有在zk上建立成功的客戶端會註冊一個子節點變動的watcher,用於監控當前master是否存活,一旦發現master掛了,那麼其他的客戶端從新進行master選舉。
http://www.sangpi.com/
利用zk的臨時節點實現,過程與master選舉相似
利用zk的臨時順序節點實現。每臺機器在指定節點下建立臨時順序節點,並指定節點類型是讀仍是寫,並對節點建立子節點變動的watcher。同時判斷本身在子節點中的序號大小,以及比本身小的節點的類型,例如若是本身想申請讀鎖,若是比本身小的節點都是讀,則獲取鎖。
上面共享鎖的實現原理是,只要子節點發生變動,全部機器都要收到變動通知並獲取全部子節點列表。當集羣中節點個數不少時,會致使發送大量的watcher通知,對zk服務器形成巨大的性能影響和網絡衝擊,更嚴重的是,當若是同一時間有多個節點發生變化,zk服務器會在短期內向其他客戶端發送大量的時間通知——這就是所謂的羊羣效應。
改進後的共享鎖是每一個臨時節點不對全部的子節點註冊watcher,而是隻對比本身序號小的最後一個節點註冊watcher監聽。
分佈式隊列,簡單地講氛圍兩大類,一類是常規的先進先出隊列,另外一種是等到隊列元素集聚後才統一安排執行的Barrier模型。
實現原理與全寫的共享鎖相似,使用臨時順序節點實現,每一個節點監聽比本身序號小的最後一個節點。
利用臨時節點實現。好比當子節點個數達到10後再繼續往下執行,過程大概是:將指定節點的數據內容賦值爲10,客戶端在指定節點下建立臨時節點,而後客戶端讀取指定節點的數據內容,並對子節點列表註冊watcher。