ZooKeeper核心原理及應用場景

爲何會有ZooKeeper 服務器

咱們知道要寫一個分佈式應用是很是困難的,主要緣由就是局部故障。一個消息經過網絡在兩個節點之間傳遞時,網絡若是發生故障,發送方並不知道接收方是否接收到了這個消息。有多是收到消息之後發生了網絡故障,也有多是沒有收到消息,又或者可能接收方的進程死了。發送方惟一的確認方法就是再次鏈接發送消息,並向他進行詢問。這就是局部故障:根本不知道操做是否失敗。所以,大部分分佈式應用須要一個主控、協調控制器來管理物理分佈的子進程。因此大部分應用須要開發私有的協調程序,協調程序的反覆編寫浪費時間,這個時候就須要一個通用的、伸縮性好的協調器。就是由於這樣的場景,ZooKeeper應運而生,ZooKeeper的設計目的,就是爲了減輕分佈式應用程序所承擔的協調任務。 網絡

ZooKeeper經常使用的應用場景 架構

01 / 分佈式協調併發

分佈式協調簡單說就是有人對ZooKeeper中的數據作了監聽,若是修改了ZooKeeper中被監聽的數據,ZooKeeper反過來會告訴給發起監聽的人數據的變動。好比在Kafka的設計中,Kafka的一個節點在ZooKeeper中建立了一個數據,Kafka的策略是誰建立了這個數據誰就是Kafka集羣的主節點,其他的節點都會去監聽這個數據。若是主節點宕機了,這ZooKeeper對應的數據就會發生變動,既而監聽這個數據的其他節點就會感知到主節點宕機了,而後從新進行選舉。分佈式

02 / 元數據管理ide

不少分佈式的程序須要集中式的管理本身的元數據,這個時候ZooKeeper就是一個很好的選擇。好比Kafka,Storm等分佈式的工具就會把集羣裏核心的元數據存放在ZooKeeper中。高併發

03 / 高可用工具

不少分佈式的項目都是主從式的架構,正常狀況下集羣裏有一個是主節點,其他的都是從節點。可是若是隻有一個主節點的話,程序就會有單點故障問題,那麼這個時候就須要部署多個主節點實現高可用了,利用ZooKeeper從多個主節點中選出一個做爲master,其他的做爲StandBy。好比鼎鼎大名的HDFS就是靠ZooKeeper實現的高可用。性能

04 / 分佈式鎖學習

在企業裏面不少的項目須要分佈式鎖,咱們可使用ZooKeeper搞分佈式鎖,不過這兒你們要注意一點,ZooKeeper確實是能夠搞分佈式鎖的,可是ZooKeeper不支持過高的併發,也就是說若是是高併發的狀況下,分佈式鎖用ZooKeeper可能也不太適合,若是在高併發的狀況下建議你們使用Redis去搞分佈式鎖,可是併發不過高的狀況下用ZooKeeper搞分佈式鎖是比較方便的,也有不少人確實是這麼使用的。

ZooKeeper核心原理

01 / ZooKeeper集羣架構

ZooKeeper核心原理及應用場景

在ZooKeeper集羣當中,集羣中的服務器角色分爲leader和learner,learner又分爲observer和follower,具體功能以下:

0x0一、leader(領導者)

爲客戶端提供讀和寫的功能,負責投票的發起和決議,集羣裏面只有leader才能接受寫的服務。

0x0二、follower(跟隨者)

爲客戶端提供讀服務,若是是寫的服務則轉發給leader。在選舉過程當中進行投票。

0x0三、observer(觀察者)

爲客戶端提供讀服務,若是是寫服務就轉發個leader。不參與leader的選舉投票。也不參與寫的過半原則機制。在不影響寫的前提下,提升集羣讀的性能,此角色於zookeeper3.3系列新增的角色。

0x0四、client(客戶端)

鏈接zookeeper集羣的使用者,請求的發起者,獨立於zookeeper集羣的角色。

02 / ZooKeeper讀寫機制

在ZooKeeper的選舉中,若是過半的節點都選一個節點爲leader的話,那麼這個節點就會是leader節點,也就是由於這個緣由,ZooKeeper集羣,只要有過半的節點是存活的,那麼這個ZooKeeper就能夠正常的提供服務。好比有5個ZooKeeper節點,其中有2個節點宕機了,這個時候還有3個節點存活,存活個數超過半數,此時集羣仍是正常提供服務,因此ZooKeeper集羣本生是沒有高可用問題的。又由於存活的判斷依據是超過半數,因此咱們通常搭建ZooKeeper集羣的時候,都使用奇數臺,這樣會比較節約機器,好比咱們安裝一個6臺的ZooKeeper集羣,若是宕機了3臺就會致使集羣不可用,由於這個時候存活的節點數沒有超過半數了,因此6臺和5臺的效果是同樣的,咱們用5臺比較合適。

對應一個ZooKeeper集羣,咱們可能有多個客戶端,客戶端能任意鏈接其中一臺ZooKeeper節點,可是全部的客戶端都只能往leader節點上面去寫數據,全部的客戶端能從全部的節點上面讀取數據。若是有客戶端鏈接的是follower節點,而後往follower上發送了寫數據的請求,這個時候follower就會把這個寫請求轉發給leader節點處理。leader接受到寫請求就會往其餘節點(包括本身)同步數據,若是過半的節點接受到消息後發送回來ack消息,那麼leader節點就對這條消息進行commit,commit後該消息就對用戶可見了。由於須要過半的節點發送ack後,leader纔對消息進行commit,這個時候會有一個問題,若是集羣越大,那麼等待過半節點發送回來ack消息這個過程就須要越久,也就是說節點越多雖然會增長集羣的讀性能,可是會影響到集羣的寫性能,因此咱們通常建議ZooKeeper的集羣規模在3到5個節點左右。爲了解決這個問題,後來的ZooKeeper中增長了一個observer 的角色,這個節點不參與投票,只是負責同步數據。好比咱們leader寫數據須要過半的節點發送ack響應,這個observer節點是不參與過半的數量統計的。它只是負責從leader同步數據,而後提供給客戶端讀取,因此引入這個角色目的就是爲了增長集羣讀的性能,而後不影響集羣的寫性能。用戶搭建集羣的時候能夠本身設置該角色。

03 / Zookeeper 特色

0x0一、一致性

client客戶端不管鏈接到集羣中的哪一個節點,讀到的數據都是同樣的

0x0二、實時性

ZooKeeper保證客戶端在必定的時間間隔內得到結果,包括成功和失敗,可是因爲網絡延遲緣由,ZooKeeper不能保證兩臺客戶端同時獲得剛更新的消息。若是都須要最新的消息須要調用sync()接口。

0x0三、原子性

leader在同步數據的時候,同步過程保證事務性,要麼都成功,要麼都失敗。

0x0四、順序性

一臺服務器上若是消息a在消息b前發佈,那麼全部的server上的消息a都是在消息b前發佈的。

04 / Zookeeper數據一致性保證

剛剛咱們看到了ZooKeeper有多個特色,可是我相信多個特色中,你們最好奇都就是Zookeeper是如何保證數據一致性的。ZooKeeper保證數據一致性用的是ZAB協議。經過這個協議來進行ZooKeeper集羣間的數據同步,保證數據的一致性。

0x0一、兩階段提交+過半寫機制

ZooKeeper核心原理及應用場景

ZooKeeper寫數據的機制是客戶端把寫請求發送到leader節點上(若是發送的是follower節點,follower節點會把寫請求轉發到leader節點),leader節點會把數據經過proposal請求發送到全部節點(包括本身),全部到節點接受到數據之後都會寫到本身到本地磁盤上面,寫好了之後會發送一個ack請求給leader,leader只要接受到過半的節點發送ack響應回來,就會發送commit消息給各個節點,各個節點就會把消息放入到內存中(放內存是爲了保證高性能),該消息就會用戶可見了。那麼這個時候,若是ZooKeeper要想保證數據一致性,就須要考慮以下兩個狀況,狀況一:leader執行commit了,還沒來得及給follower發送commit的時候,leader宕機了,這個時候如何保證消息一致性?狀況二:客戶端把消息寫到leader了,可是leader還沒發送proposal消息給其餘節點,這個時候leader宕機了,leader宕機後恢復的時候此消息又該如何處理?

0x0二、ZAB的崩潰恢復機制

針對狀況一,當leader宕機之後,ZooKeeper會選舉出來新的leader,新的leader啓動之後要到磁盤上面去檢查是否存在沒有commit的消息,若是存在,就繼續檢查看其餘follower有沒有對這條消息進行了commit,若是有過半節點對這條消息進行了ack,可是沒有commit,那麼新對leader要完成commit的操做。

0x0三、ZAB恢復中刪除數據機制

針對狀況二,客戶端把消息寫到leader了,可是leader還沒發送portal消息給其餘節點,這個時候leader宕機了,這個時候對於用戶來講,這條消息是寫失敗的。假設過了一段時間之後leader節點又恢復了,不過這個時候角色就變爲了follower了,它在檢查本身磁盤的時候會發現本身有一條消息沒有進行commit,此時就會檢測消息的編號,消息是有編號的,由高32位和低32位組成,高32位是用來體現是否發生過leader切換的,低32位就是展現消息的順序的。這個時候當前的節點就會根據高32位知道目前leader已經切換過了,因此就把當前的消息刪除,而後重新的leader同步數據,這樣保證了數據一致性。

最後

各位同窗,ZooKeeper是咱們學習架構的過程中,很是很是重要的一個知識點,咱們今天只是從其中一些角度去分析的ZooKeeper,咱們後面會有不少文章從不一樣角度深刻全面的剖析ZooKeeper,幫助你們掌握ZooKeeper,歡迎你們持續關注。

領取更多免費技術資料及視頻
ZooKeeper核心原理及應用場景

相關文章
相關標籤/搜索