zk腦裂

1、爲何zookeeper要部署基數臺服務器?
2、zookeeper腦裂(Split-Brain)問題
2.一、什麼是腦裂?
2.二、什麼緣由致使的?
2.二、zookeeper是如何解決的?
1、爲何zookeeper要部署基數臺服務器?
**所謂的zookeeper容錯是指,當宕掉幾個zookeeper服務器以後,剩下的個數必須大於宕掉的個數,也就是剩下的服務數必須大於n/2,zookeeper才能夠繼續使用,不管奇偶數均可以選舉leader。**5臺機器最多宕掉2臺,還能夠繼續使用,由於剩下3臺大於5/2。說爲何最好爲奇數個,是在以最大容錯服務器個數的條件下,會節省資源,好比,最大容錯爲2的狀況下,對應的zookeeper服務數,奇數爲5,而偶數爲6,也就是6個zookeeper服務的狀況下最多能宕掉2個服務,因此從節約資源的角度看,不必部署6(偶數)個zookeeper服務。安全

zookeeper有這樣一個特性:集羣中只要有過半的機器是正常工做的,那麼整個集羣對外就是可用的。也就是說若是有2個zookeeper,那麼只要有1個死了zookeeper就不能用了,由於1沒有過半,因此2個zookeeper的死亡容忍度爲0;同理,要是有3個zookeeper,一個死了,還剩下2個正常的,過半了,因此3個zookeeper的容忍度爲1;同理你多列舉幾個:2->0;3->1;4->1;5->2;6->2會發現一個規律,2n和2n-1的容忍度是同樣的,都是n-1,因此爲了更加高效,何須增長那一個沒必要要的zookeeper呢。服務器

根據以上能夠得出結論:出現資源節省的角度網絡

2、zookeeper腦裂(Split-Brain)問題
2.一、什麼是腦裂?
白話點說,就是好比當你的 cluster 裏面有兩個結點,它們都知道在這個 cluster 裏須要選舉出一個 master。那麼當它們兩之間的通訊徹底沒有問題的時候,就會達成共識,選出其中一個做爲 master。可是若是它們之間的通訊出了問題,那麼兩個結點都會以爲如今沒有 master,因此每一個都把本身選舉成 master。因而 cluster 裏面就會有兩個 master。分佈式

對於Zookeeper來講有一個很重要的問題,就是究竟是根據一個什麼樣的狀況來判斷一個節點死亡down掉了。 在分佈式系統中這些都是有監控者來判斷的,可是監控者也很難斷定其餘的節點的狀態,惟一一個可靠的途徑就是心跳,Zookeeper也是使用心跳來判斷客戶端是否仍然活着。ci

使用ZooKeeper來作master HA基本都是一樣的方式,每一個節點都嘗試註冊一個象徵master的臨時節點其餘沒有註冊成功的則成爲slaver,而且經過watch機制監控着master所建立的臨時節點,Zookeeper經過內部心跳機制來肯定master的狀態,一旦master出現意外Zookeeper能很快獲悉而且通知其餘的slaver,其餘slaver在以後做出相關反應。這樣就完成了一個切換。這種模式也是比較通用的模式,基本大部分都是這樣實現的,可是這裏面有個很嚴重的問題,若是注意不到會致使短暫的時間內系統出現腦裂,由於心跳出現超時多是master掛了,可是也多是master,zookeeper之間網絡出現了問題,也一樣可能致使。這種狀況就是假死,master並未死掉,可是與ZooKeeper之間的網絡出現問題致使Zookeeper認爲其掛掉了而後通知其餘節點進行切換,這樣slaver中就有一個成爲了master,可是本來的master並未死掉,這時候client也得到master切換的消息,可是仍然會有一些延時,zookeeper須要通信須要一個一個通知,這時候整個系統就很混亂可能有一部分client已經通知到了鏈接到新的master上去了,有的client仍然鏈接在老的master上若是同時有兩個client須要對master的同一個數據更新而且恰好這兩個client此刻分別鏈接在新老的master上,就會出現很嚴重問題。資源

總結:部署

假死:因爲心跳超時(網絡緣由致使的)認爲master死了,但其實master還存活着。
腦裂:因爲假死會發起新的master選舉,選舉出一個新的master,但舊的master網絡又通了,致使出現了兩個master ,有的客戶端鏈接到老的master 有的客戶端連接到新的master。
2.二、什麼緣由致使的?
主要緣由是Zookeeper集羣和Zookeeper client判斷超時並不能作到徹底同步,也就是說可能一前一後,若是是集羣先於client發現,那就會出現上面的狀況。同時,在發現並切換後通知各個客戶端也有前後快慢。通常出現這種狀況的概率很小,須要master與Zookeeper集羣網絡斷開可是與其餘集羣角色之間的網絡沒有問題,還要知足上面那些狀況,可是一旦出現就會引發很嚴重的後果,數據不一致。同步

2.二、zookeeper是如何解決的?
要解決Split-Brain的問題,通常有3種方式:it

Quorums(ˈkwôrəm 法定人數) ,好比3個節點的集羣,Quorums = 2, 也就是說集羣能夠容忍1個節點失效,這時候還能選舉出1個lead,集羣還可用。好比4個節點的集羣,它的Quorums = 3,Quorums要超過3,至關於集羣的容忍度仍是1,若是2個節點失效,那麼整個集羣仍是無效的
採用Redundant communications,冗餘通訊的方式,集羣中採用多種通訊方式,防止一種通訊方式失效致使集羣中的節點沒法通訊。
Fencing, 共享資源的方式,好比能看到共享資源就表示在集羣中,可以得到共享資源的鎖的就是Leader,看不到共享資源的,就不在集羣中。
ZooKeeper默認採用了Quorums這種方式,即只有集羣中超過半數節點投票才能選舉出Leader。這樣的方式能夠確保leader的惟一性,要麼選出惟一的一個leader,要麼選舉失敗。在ZooKeeper中Quorums有2個做用:io

集羣中最少的節點數用來選舉Leader保證集羣可用通知客戶端數據已經安全保存前集羣中最少數量的節點數已經保存了該數據。一旦這些節點保存了該數據,客戶端將被通知已經安全保存了,能夠繼續其餘任務。而集羣中剩餘的節點將會最終也保存了該數據假設某個leader假死,其他的followers選舉出了一個新的leader。這時,舊的leader復活而且仍然認爲本身是leader,這個時候它向其餘followers發出寫請求也是會被拒絕的。由於每當新leader產生時,會生成一個epoch,這個epoch是遞增的,followers若是確認了新的leader存在,知道其epoch,就會拒絕epoch小於現任leader epoch的全部請求。那有沒有follower不知道新的leader存在呢,有可能,但確定不是大多數,不然新leader沒法產生。Zookeeper的寫也遵循quorum機制,所以,得不到大多數支持的寫是無效的,舊leader即便各類認爲本身是leader,依然沒有什麼做用。

相關文章
相關標籤/搜索