ZooKeeper 的 Leader 選舉
1. 前言
我們在 Zookeeper 集群模式一節(jié)中,我們學(xué)習(xí)了為什么要使用 Zookeeper 的集群模式,是因為我們需要保證 Zookeeper 服務(wù)的高性能和高可用性。既然使用 Zookeeper 的集群模式,那么避免不了的問題就是 Zookeeper 如何進(jìn)行 Leader 的選舉以及和如何保證 Zookeeper 服務(wù)的數(shù)據(jù)一致性。那么本節(jié)我們就來講解 Zookeeper 服務(wù)是如何進(jìn)行 Leader 選舉的。
2. Zookeeper 的 Leader 選舉
Zookeeper 的 Leader 選舉發(fā)生在兩個階段:
- Zookeeper 服務(wù)初次啟動時的 Leader 選舉。
- Zookeeper 崩潰恢復(fù)時的 Leader 選舉。
首先我們來講解在 Zookeeper 服務(wù)啟動時的 Leader 選舉。
2.1 Zookeeper 服務(wù)啟動時的 Leader 選舉
在 Zookeeper 服務(wù)啟動階段,每個 Zookeeper 服務(wù)會根據(jù)配置文件選擇啟動模式。
在選擇集群模式的情況下,獲取配置文件中所有 Zookeeper 服務(wù)的地址,然后向其它 Zookeeper 服務(wù)發(fā)起通信檢查,確認(rèn) Zookeeper 服務(wù)間的通信狀態(tài)。然后在這些 Zookeeper 服務(wù)間尋找 Leader 節(jié)點,初次啟動時無 Leader 節(jié)點,此時就會進(jìn)入 Leader 選舉的狀態(tài)。
在選舉狀態(tài)中,所有 Zookeeper 服務(wù)的狀態(tài)都會變?yōu)?Looking 選舉狀態(tài),每臺 Zookeeper 服務(wù)都把自己當(dāng)作 Leader 候選者向其它 Zookeeper 服務(wù)發(fā)送自己的選票信息。我們這里以 3 個 Zookeeper 服務(wù)為例子:
選票信息包括 Zookeeper 的服務(wù)ID,也就是 myid 文件中的內(nèi)容,還有就是 Zookeeper 服務(wù)最新的事務(wù)ID,也就是 ZXID,當(dāng)然初次啟動的 Zookeeper 服務(wù)的事務(wù) ID 都是相同的 。發(fā)送選票信息的同時,也會接收到其它 Zookeeper 服務(wù)發(fā)送的選票信息。
Tips: ZXID:節(jié)點本地的事務(wù)編號,由64位的數(shù)字組成,包含紀(jì)元值( epoch )和計數(shù)兩部分。
正常情況下,在第一輪的選舉中,每個 Zookeeper 服務(wù)的選票信息都是自身的信息,所以不會產(chǎn)生 Leader,此時就會開啟第二輪選舉。
在第二輪選舉之前,Zookeeper 服務(wù)會把自己的選票信息和接收到的其它 Zookeeper 服務(wù)的選票信息一起做比較,產(chǎn)生新的選票信息,首先比較 ZXID,選取擁有較大的 ZXID 的選票信息作為自己新的選票,如果 ZXID 相同,則會比較服務(wù)ID,也就是 myid 的值,選取擁有較大的 myid 值的選票信息作為自己新的選票。
產(chǎn)生了新的選票之后,發(fā)起第二輪投票,此時 Zookeeper 服務(wù)器會統(tǒng)計所有服務(wù)器發(fā)出的選票,如果超過半數(shù)的 Zookeeper 服務(wù)的選票信息是相同的,那么該選票中的 myid 值相對應(yīng)的 Zookeeper 服務(wù)就當(dāng)選為 Leader 服務(wù),其狀態(tài)變?yōu)?Leading,其它 Zookeeper 服務(wù)的狀態(tài)由 Looking 狀態(tài)變?yōu)?Following,也就是 Follower 服務(wù)。如果選票的統(tǒng)計未達(dá)到半數(shù)以上,則更新各個節(jié)點的選票信息,重新開始新一輪的選舉,直到選舉出 Leader。
以上就是 Zookeeper 服務(wù)啟動時的 Leader 選舉的過程。接下來我們講解 Zookeeper 在崩潰恢復(fù)階段的 Leader 選舉。
2.2 Zookeeper 的 ZAB 協(xié)議
2.2.1 什么是 ZAB 協(xié)議
Zookeeper 使用 ZAB 協(xié)議來保證 Zookeeper 的數(shù)據(jù)一致性,ZAB 協(xié)議全稱 Zookeeper Atomic Broadcast ,原子消息廣播協(xié)議。
ZAB 協(xié)議的兩種工作模式:
- 崩潰恢復(fù)
- 消息廣播
ZAB 協(xié)議定義了三種節(jié)點狀態(tài):
- Looking:選舉狀態(tài);
- Following:從節(jié)點所處的狀態(tài);
- Leading:主節(jié)點所處的狀態(tài)。
那么 ZAB 協(xié)議的這兩種模式什么時候使用呢?三種節(jié)點的狀態(tài)又是如何變化的呢?
接下來,我們來詳細(xì)了解一下 ZAB 的崩潰恢復(fù)模式是如何工作的。
2.2.2 ZAB 的崩潰恢復(fù)模式
在 Zookeeper 集群服務(wù)的運行過程中,如果 Leader 節(jié)點發(fā)生故障,無法處理 Follower 節(jié)點提交的事務(wù)請求,根據(jù) ZAB 協(xié)議,此時的 Zookeeper 集群就會暫時停止對外提供服務(wù),進(jìn)入崩潰恢復(fù)。如果此時崩潰的 Leader 服務(wù)故障被排除,加入到 Zookeeper 集群中,它也會進(jìn)入 Looking 狀態(tài),參與選舉。
Zookeeper 的崩潰恢復(fù)分為 3 個階段:
-
Leader election
在 Leader 選舉階段,Zookeeper 服務(wù)都為 Looking 狀態(tài),每個 Zookeeper 服務(wù)都會用自身的 ZXID 和 myid 值形成選票,第一輪選舉和 Zookeeper 啟動時第一輪選舉的結(jié)果一樣,Zookeeper 服務(wù)的選票信息都是自身的信息,所以不會產(chǎn)生 Leader,無 Leader 產(chǎn)生 Zookeeper 服務(wù)就會更新自身的選票信息,進(jìn)入下一輪選舉,直到選舉出 Leader。這一階段選舉出來的 Leader 還不能直接作為真正的 Leader 去處理事務(wù)請求,它還需要再次確認(rèn)自身的數(shù)據(jù)是最新的,避免網(wǎng)絡(luò)等原因出現(xiàn)多個 Leader 的情況,接下來就進(jìn)入 Discovery 發(fā)現(xiàn)階段。
-
Discovery
在 Discovery 發(fā)現(xiàn)階段,上一階段產(chǎn)生的 Follower 服務(wù)會把自身 ZXID 中的 epoch 紀(jì)元值發(fā)送給 Leader 服務(wù),Leader 接收到所有 Follower 的 epoch 紀(jì)元值后,會選出其中最大的 epoch 紀(jì)元值,然后在這基礎(chǔ)上進(jìn)行加 1 ,作為最新的 epoch 紀(jì)元值,返回給所有的 Follower 。Follower 接收到 Leader 發(fā)送的最新 epoch 紀(jì)元值后,根據(jù)此 epoch 紀(jì)元值來更新自己的 ZXID ,然后再把更新后的 ZXID 、最新的歷史事務(wù)日志和 ACK 確認(rèn)信息返回到 Leader。
Leader 接收到 ACK 確認(rèn)信息后,把接收到最新的 ZXID 和 最新的歷史事務(wù)日志和自身作比較,把最新的更新到自身。
經(jīng)過這一階段就能確認(rèn) Leader 服務(wù)的數(shù)據(jù)是最新的了,然后就進(jìn)入下一階段,Synchronization 同步階段。
-
Synchronization
Synchronization 同步階段的主要作用是把 Leader 最新的數(shù)據(jù)和日志同步到 Follower 中,當(dāng)半數(shù)以上的 Follower 同步數(shù)據(jù)成功后,Leader 才能成為真正的 Leader ,就可以處理事務(wù)請求了。
經(jīng)過崩潰恢復(fù)的 3 個階段,真正的 Leader 選舉完成后,Zookeeper 就會進(jìn)入消息廣播模式,重新對外提供服務(wù)。
3. 總結(jié)
經(jīng)過本節(jié)的學(xué)習(xí),我們知道了 Zookeeper 在啟動時和崩潰恢復(fù)時的 Leader 選舉時如何完成的,也了解了 Zookeeper 崩潰恢復(fù)的 3 個階段。以下是本節(jié)內(nèi)容的總結(jié):
- Zookeeper 在啟動時的 Leader 選舉。
- Zookeeper 的 ZAB 協(xié)議。
- ZAB 協(xié)議的崩潰恢復(fù)過程。
- Zookeeper 崩潰恢復(fù)的 3 個階段。