1. 程式人生 > >2.3.ZooKeeper應用場景

2.3.ZooKeeper應用場景

主從模式 當前 idt .com 我們 系統 通過 將他 舉例

7、ZooKeeper應用舉例 

為了方便大家理解ZooKeeper,在此就給大家舉個例子,看看ZooKeeper是如何實現的他的服務的,我以ZooKeeper提供的基本服務分布式鎖為例。

7.1 分布式鎖應用場景

在分布式鎖服務中,有一種最典型應用場景,就是通過對集群進行Master選舉,來解決分布式系統中的單點故障。什麽是分布式系統中的單點故障:

通常分布式系統采用主從模式,就是一個主控機連接多個處理節點。主節點負責分發任務,從節點負責處理任務,當我們的主節點發生故障時,那麽

整個系統就都癱瘓了,那麽我們把這種故障叫作單點故障。如下圖7.1和7.2所示:

圖 7.1 主從模式分布式系統 圖7.2 單點故障

技術分享圖片 技術分享圖片

7.2 傳統解決方案

傳統方式是采用一個備用節點,這個備用節點定期給當前主節點發送ping包,主節點收到ping包以後向備用節點發送回復Ack,當備用節點收到回復的

時候就會認為當前主節點還活著,讓他繼續提供服務。如圖7.3所示:

圖 7.3 傳統解決方案

技術分享圖片

當主節點掛了,這時候備用節點收不到回復了,然後他就認為主節點掛了接替他成為主節點如下圖7.4所示:

圖 7.4傳統解決方案

技術分享圖片

但是這種方式就是有一個隱患,就是網絡問題,來看一網絡問題會造成什麽後果,如下圖7.5所示:

圖 7.5 網絡故障

技術分享圖片

也就是說我們的主節點的並沒有掛,只是在回復的時候網絡發生故障,這樣我們的備用節點同樣收不到回復,就會認為主節點掛了,然後備用節點

將他的Master實例啟動起來,這樣我們的分布式系統當中就有了兩個主節點也就是---雙Master,出現Master以後我們的從節點就會將它所做的事一

部分匯報給了主節點,一部分匯報給了從節點,這樣服務就全亂了。為了防止出現這種情況,我們引入了ZooKeeper,它雖然不能避免網絡故障,

但它能夠保證每時每刻只有一個Master。我麽來看一下ZooKeeper是如何實現的。

7.3 ZooKeeper解決方案

(1) Master啟動

在引入了Zookeeper以後我們啟動了兩個主節點,"主節點-A"和"主節點-B"他們啟動以後,都向ZooKeeper去註冊一個節點。我們假設"主節點-A"鎖

註冊地節點是"master-00001","主節點-B"註冊的節點是"master-00002",註冊完以後進行選舉,編號最小的節點將在選舉中獲勝獲得鎖成為主節點

,也就是我們的"主節點-A"將會獲得鎖成為主節點,然後"主節點-B"將被阻塞成為一個備用節點。那麽,通過這種方式就完成了對兩個Master進程的

調度。

圖7.6 ZooKeeper Master選舉

技術分享圖片

(2) Master故障

如果"主節點-A"掛了,這時候他所註冊的節點將被自動刪除,ZooKeeper會自動感知節點的變化,然後再次發出選舉,這時候"主節點-B"將在選舉中獲勝,

替代"主節點-A"成為主節點。

圖7.7 ZooKeeper Master選舉

技術分享圖片

(3) Master 恢復

圖7.8 ZooKeeper Master選舉

技術分享圖片

如果主節點恢復了,他會再次向ZooKeeper註冊一個節點,這時候他註冊的節點將會是"master-00003",ZooKeeper會感知節點的變化再次發動選舉,這

時候"主節點-B"在選舉中會再次獲勝繼續擔任"主節點","主節點-A"會擔任備用節點。

2.3.ZooKeeper應用場景