ZK介紹

ZK = zookeeper 

ZK是微服務(wù)解決方案中擁有服務(wù)注冊(cè)發(fā)現(xiàn)最為核心的環(huán)境，是微服務(wù)的基石。作為服務(wù)注冊(cè)發(fā)現(xiàn)模塊，并不是只有ZK一種產(chǎn)品，目前得到行業(yè)認(rèn)可的還有：Eureka、Consul。

[[284109]]

這里我們只聊ZK，這個(gè)工具本身很小zip包就幾兆，安裝非常傻瓜，能夠支持集群部署。

背景

在集群環(huán)境下ZK的leader&follower的概念，已經(jīng)節(jié)點(diǎn)異常ZK面臨的問題以及如何解決。ZK本身是java語言開發(fā)，也開源到Github上但官方文檔對(duì)內(nèi)部介紹的很少，零散的博客很多，有些寫的很不錯(cuò)。

提問：

• zookeeper選舉算法中的過半票數(shù)才提供正常服務(wù)，這是什么邏輯?

ZK集群單節(jié)點(diǎn)狀態(tài)(每個(gè)節(jié)點(diǎn)有且只有一個(gè)狀態(tài))，ZK的定位一定需要一個(gè)leader節(jié)點(diǎn)處于lading狀態(tài)。

• looking：尋找leader狀態(tài)，當(dāng)前集群沒有l(wèi)eader，進(jìn)入leader選舉流程。
• following：跟隨者狀態(tài)，接受leading節(jié)點(diǎn)同步和指揮。
• leading：領(lǐng)導(dǎo)者狀態(tài)。
• observing：觀察者狀態(tài)，表名當(dāng)前服務(wù)器是observer。

ZK投票處理策略

投票信息包含 ：所選舉leader的Serverid，Zxid，SelectionEpoch

• Epoch判斷，自身logicEpoch與SelectionEpoch判斷：大于、小于、等于。
• 優(yōu)先檢查ZXID。ZXID比較大的服務(wù)器優(yōu)先作為Leader。
• 如果ZXID相同，那么就比較myid。myid較大的服務(wù)器作為Leader服務(wù)器。

過半選舉算法

ZK中有三種選舉算法，分別是LeaderElection,FastLeaderElection,AuthLeaderElection，F(xiàn)astLeaderElection和AuthLeaderElection是類似的選舉算法，唯一區(qū)別是后者加入了認(rèn)證信息， FastLeaderElection比LeaderElection更高效，后續(xù)的版本只保留FastLeaderElection。

理解：

在集群環(huán)境下多個(gè)節(jié)點(diǎn)啟動(dòng)，ZK首先需要在多個(gè)節(jié)點(diǎn)中選出一個(gè)節(jié)點(diǎn)作為leader并處于Leading狀態(tài)，這樣就面臨一個(gè)選舉問題，同時(shí)選舉規(guī)則是什么樣的。“過半選舉算法”：投票選舉中獲得票數(shù)過半的節(jié)點(diǎn)勝出，即狀態(tài)從looking變?yōu)閘eading，效率更高。

以5臺(tái)服務(wù)器講解思路：

服務(wù)器1啟動(dòng),此時(shí)只有它一臺(tái)服務(wù)器啟動(dòng)了,它發(fā)出去的Vote沒有任何響應(yīng),所以它的選舉狀態(tài)一直是LOOKING狀態(tài);

服務(wù)器2啟動(dòng),它與最開始啟動(dòng)的服務(wù)器1進(jìn)行通信,互相交換自己的選舉結(jié)果,由于兩者都沒有歷史數(shù)據(jù),所以id值較大的服務(wù)器2勝出,但是由于沒有達(dá)到超過半數(shù)以上的服務(wù)器都同意選舉它(這個(gè)例子中的半數(shù)以上是3),所以服務(wù)器1,2還是繼續(xù)保持LOOKING狀態(tài).

服務(wù)器3啟動(dòng),根據(jù)前面的理論，分析有三臺(tái)服務(wù)器選舉了它,服務(wù)器3成為服務(wù)器1,2,3中的老大,所以它成為了這次選舉的leader.

服務(wù)器4啟動(dòng),根據(jù)前面的分析，理論上服務(wù)器4應(yīng)該是服務(wù)器1,2,3,4中最大的,但是由于前面已經(jīng)有半數(shù)以上的服務(wù)器選舉了服務(wù)器3,所以它只能接收當(dāng)小弟的命了.

服務(wù)器5啟動(dòng),同4一樣,當(dāng)小弟.

假設(shè)5臺(tái)中掛了2臺(tái)(3、4)，其中l(wèi)eader也掛掉：

leader和follower間有檢查心跳，需要同步數(shù)據(jù) Leader節(jié)點(diǎn)掛了，整個(gè)Zookeeper集群將暫停對(duì)外服務(wù)，進(jìn)入新一輪Leader選舉

1)服務(wù)器1、2、5發(fā)現(xiàn)與leader失聯(lián)，狀態(tài)轉(zhuǎn)為looking，開始新的投票 2)服務(wù)器1、2、5分別開始投票并廣播投票信息，自身Epoch自增; 3) 服務(wù)器1、2、5分別處理投票，判斷出leader分別廣播 4)根據(jù)投票處理邏輯會(huì)選出一臺(tái)(2票過半) 5)各自服務(wù)器重新變更為leader、follower狀態(tài) 6)重新提供服務(wù)

腦裂問題

腦裂問題出現(xiàn)在集群中l(wèi)eader死掉，follower選出了新leader而原leader又復(fù)活了的情況下，因?yàn)閆K的過半機(jī)制是允許損失一定數(shù)量的機(jī)器而扔能正常提供給服務(wù)，當(dāng)leader死亡判斷不一致時(shí)就會(huì)出現(xiàn)多個(gè)leader。

方案：

ZK的過半機(jī)制一定程度上也減少了腦裂情況的出現(xiàn)，起碼不會(huì)出現(xiàn)三個(gè)leader同時(shí)。ZK中的Epoch機(jī)制(時(shí)鐘)每次選舉都是遞增+1，當(dāng)通信時(shí)需要判斷epoch是否一致，小于自己的則拋棄，大于自己則重置自己，等于則選舉;

歸納

在日常的ZK運(yùn)維時(shí)需要注意以上場(chǎng)景在極端情況下出現(xiàn)問題，特別是腦裂的出現(xiàn)，可以采用：

過半選舉策略下部署原則：

1. 服務(wù)器群部署要單數(shù)，如：3、5、7、...，單數(shù)是最容易選出leader的配置量。
2. ZK允許節(jié)點(diǎn)最大損失數(shù)，原則就是“保證過半選舉正常”，多了就是浪費(fèi)。

詳細(xì)的算法邏輯是很復(fù)雜要考慮很多情況，其中有個(gè)Epoch的概念(自增長)，分為：LogicEpoch和ElectionEpoch，每次投票都有判斷每個(gè)投票周期是否一致等等。