深入淺出ZooKeeper（二） 基于Zookeeper的分布式鎖與領(lǐng)導(dǎo)選舉

作者：郭俊 2018-01-25 19:01:47

開發(fā)

開發(fā)工具

分布式 基于 Zookeeper 的領(lǐng)導(dǎo)選舉或者分布式鎖的實(shí)現(xiàn)均基于 Zookeeper 節(jié)點(diǎn)的特性及通知機(jī)制。充分利用這些特性，還可以開發(fā)出適用于其它場景的分布式應(yīng)用。

綏化網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)公司,綏化網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為綏化成百上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)公司要多少錢，請找那個(gè)售后服務(wù)好的綏化做網(wǎng)站的公司定做！

一、Zookeeper特點(diǎn)

1. Zookeeper節(jié)點(diǎn)類型

如上文《Zookeeper架構(gòu)及FastLeaderElection機(jī)制》所述，Zookeeper 提供了一個(gè)類似于 Linux 文件系統(tǒng)的樹形結(jié)構(gòu)。該樹形結(jié)構(gòu)中每個(gè)節(jié)點(diǎn)被稱為 znode ，可按如下兩個(gè)維度分類：

(1) Persist vs. Ephemeral

• Persist節(jié)點(diǎn)，一旦被創(chuàng)建，便不會(huì)意外丟失，即使服務(wù)器全部重啟也依然存在。每個(gè) Persist 節(jié)點(diǎn)即可包含數(shù)據(jù)，也可包含子節(jié)點(diǎn)
• Ephemeral節(jié)點(diǎn)，在創(chuàng)建它的客戶端與服務(wù)器間的 Session 結(jié)束時(shí)自動(dòng)被刪除。服務(wù)器重啟會(huì)導(dǎo)致 Session 結(jié)束，因此 Ephemeral 類型的 znode 此時(shí)也會(huì)自動(dòng)刪除

(2) Sequence vs. Non-sequence

• Non-sequence節(jié)點(diǎn)，多個(gè)客戶端同時(shí)創(chuàng)建同一 Non-sequence 節(jié)點(diǎn)時(shí)，只有一個(gè)可創(chuàng)建成功，其它勻失敗。并且創(chuàng)建出的節(jié)點(diǎn)名稱與創(chuàng)建時(shí)指定的節(jié)點(diǎn)名完全一樣
• Sequence節(jié)點(diǎn)，創(chuàng)建出的節(jié)點(diǎn)名在指定的名稱之后帶有10位10進(jìn)制數(shù)的序號(hào)。多個(gè)客戶端創(chuàng)建同一名稱的節(jié)點(diǎn)時(shí)，都能創(chuàng)建成功，只是序號(hào)不同

2. Zookeeper語義保證

Zookeeper 簡單高效，同時(shí)提供如下語義保證，從而使得我們可以利用這些特性提供復(fù)雜的服務(wù)。

• 順序性　客戶端發(fā)起的更新會(huì)按發(fā)送順序被應(yīng)用到 Zookeeper 上
• 原子性 更新操作要么成功要么失敗，不會(huì)出現(xiàn)中間狀態(tài)
• 單一系統(tǒng)鏡像　一個(gè)客戶端無論連接到哪一個(gè)服務(wù)器都能看到完全一樣的系統(tǒng)鏡像(即完全一樣的樹形結(jié)構(gòu))。注：根據(jù)上文《Zookeeper架構(gòu)及FastLeaderElection機(jī)制》介紹的 ZAB 協(xié)議，寫操作并不保證更新被所有的 Follower 立即確認(rèn)，因此通過部分 Follower 讀取數(shù)據(jù)并不能保證讀到最新的數(shù)據(jù)，而部分 Follwer 及 Leader 可讀到最新數(shù)據(jù)。如果一定要保證單一系統(tǒng)鏡像，可在讀操作前使用 sync 方法。
• 可靠性　一個(gè)更新操作一旦被接受即不會(huì)意外丟失，除非被其它更新操作覆蓋
• 最終一致性　寫操作最終(而非立即)會(huì)對客戶端可見

3. Zookeeper Watch機(jī)制

所有對 Zookeeper 的讀操作，都可附帶一個(gè) Watch 。一旦相應(yīng)的數(shù)據(jù)有變化，該 Watch 即被觸發(fā)。Watch 有如下特點(diǎn)

• 主動(dòng)推送　Watch被觸發(fā)時(shí)，由 Zookeeper 服務(wù)器主動(dòng)將更新推送給客戶端，而不需要客戶端輪詢。
• 一次性　數(shù)據(jù)變化時(shí)，Watch 只會(huì)被觸發(fā)一次。如果客戶端想得到后續(xù)更新的通知，必須要在 Watch 被觸發(fā)后重新注冊一個(gè) Watch。
• 可見性　如果一個(gè)客戶端在讀請求中附帶 Watch，Watch 被觸發(fā)的同時(shí)再次讀取數(shù)據(jù)，客戶端在得到 Watch 消息之前肯定不可能看到更新后的數(shù)據(jù)。換句話說，更新通知先于更新結(jié)果。
• 順序性　如果多個(gè)更新觸發(fā)了多個(gè) Watch ，那 Watch 被觸發(fā)的順序與更新順序一致。

二、分布式鎖與領(lǐng)導(dǎo)選舉關(guān)鍵點(diǎn)

1. 最多一個(gè)獲取鎖 / 成為Leader

對于分布式鎖(這里特指排它鎖)而言，任意時(shí)刻，最多只有一個(gè)進(jìn)程(對于單進(jìn)程內(nèi)的鎖而言是單線程)可以獲得鎖。

對于領(lǐng)導(dǎo)選舉而言，任意時(shí)間，最多只有一個(gè)成功當(dāng)選為Leader。否則即出現(xiàn)腦裂(Split brain)

2. 鎖重入 / 確認(rèn)自己是Leader

對于分布式鎖，需要保證獲得鎖的進(jìn)程在釋放鎖之前可再次獲得鎖，即鎖的可重入性。

對于領(lǐng)導(dǎo)選舉，Leader需要能夠確認(rèn)自己已經(jīng)獲得領(lǐng)導(dǎo)權(quán)，即確認(rèn)自己是Leader。

3. 釋放鎖 / 放棄領(lǐng)導(dǎo)權(quán)

鎖的獲得者應(yīng)該能夠正確釋放已經(jīng)獲得的鎖，并且當(dāng)獲得鎖的進(jìn)程宕機(jī)時(shí)，鎖應(yīng)該自動(dòng)釋放，從而使得其它競爭方可以獲得該鎖，從而避免出現(xiàn)死鎖的狀態(tài)。

領(lǐng)導(dǎo)應(yīng)該可以主動(dòng)放棄領(lǐng)導(dǎo)權(quán)，并且當(dāng)領(lǐng)導(dǎo)所在進(jìn)程宕機(jī)時(shí)，領(lǐng)導(dǎo)權(quán)應(yīng)該自動(dòng)釋放，從而使得其它參與者可重新競爭領(lǐng)導(dǎo)而避免進(jìn)入無主狀態(tài)。

4. 感知鎖釋放 / 領(lǐng)導(dǎo)權(quán)的放棄

當(dāng)獲得鎖的一方釋放鎖時(shí)，其它對于鎖的競爭方需要能夠感知到鎖的釋放，并再次嘗試獲取鎖。

原來的Leader放棄領(lǐng)導(dǎo)權(quán)時(shí)，其它參與方應(yīng)該能夠感知該事件，并重新發(fā)起選舉流程。

5. 非公平領(lǐng)導(dǎo)選舉

從上面幾個(gè)方面可見，分布式鎖與領(lǐng)導(dǎo)選舉的技術(shù)要點(diǎn)非常相似，實(shí)際上其實(shí)現(xiàn)機(jī)制也相近。本章就以領(lǐng)導(dǎo)選舉為例來說明二者的實(shí)現(xiàn)原理，分布式鎖的實(shí)現(xiàn)原理也幾乎一致。

6. 選主過程

假設(shè)有三個(gè)Zookeeper的客戶端，如下圖所示，同時(shí)競爭Leader。這三個(gè)客戶端同時(shí)向Zookeeper集群注冊Ephemeral且Non-sequence類型的節(jié)點(diǎn)，路徑都為/zkroot/leader(工程實(shí)踐中，路徑名可自定義)。

如上圖所示，由于是Non-sequence節(jié)點(diǎn)，這三個(gè)客戶端只會(huì)有一個(gè)創(chuàng)建成功，其它節(jié)點(diǎn)均創(chuàng)建失敗。此時(shí)，創(chuàng)建成功的客戶端(即上圖中的Client 1)即成功競選為 Leader 。其它客戶端(即上圖中的Client 2和Client 3)此時(shí)勻?yàn)?Follower。

7. 放棄領(lǐng)導(dǎo)權(quán)

如果 Leader 打算主動(dòng)放棄領(lǐng)導(dǎo)權(quán)，直接刪除/zkroot/leader節(jié)點(diǎn)即可。

如果 Leader 進(jìn)程意外宕機(jī)，其與 Zookeeper 間的 Session 也結(jié)束，該節(jié)點(diǎn)由于是Ephemeral類型的節(jié)點(diǎn)，因此也會(huì)自動(dòng)被刪除。

此時(shí)/zkroot/leader節(jié)點(diǎn)不復(fù)存在，對于其它參與競選的客戶端而言，之前的 Leader 已經(jīng)放棄了領(lǐng)導(dǎo)權(quán)。

8. 感知領(lǐng)導(dǎo)權(quán)的放棄

由上圖可見，創(chuàng)建節(jié)點(diǎn)失敗的節(jié)點(diǎn)，除了成為 Follower 以外，還會(huì)向/zkroot/leader注冊一個(gè) Watch ，一旦 Leader 放棄領(lǐng)導(dǎo)權(quán)，也即該節(jié)點(diǎn)被刪除，所有的 Follower 會(huì)收到通知。

9. 重新選舉

感知到舊 Leader 放棄領(lǐng)導(dǎo)權(quán)后，所有的 Follower 可以再次發(fā)起新一輪的領(lǐng)導(dǎo)選舉，如下圖所示。

從上圖中可見

• 新一輪的領(lǐng)導(dǎo)選舉方法與最初的領(lǐng)導(dǎo)選舉方法完全一樣，都是發(fā)起節(jié)點(diǎn)創(chuàng)建請求，創(chuàng)建成功即為 Leader，否則為 Follower ，且 Follower 會(huì) Watch 該節(jié)點(diǎn)
• 新一輪的選舉結(jié)果，無法預(yù)測，與它們在第一輪選舉中的順序無關(guān)。這也是該方案被稱為非公平模式的原因

10. 非公平模式總結(jié)

• 非公平模式實(shí)現(xiàn)簡單，每一輪選舉方法都完全一樣
• 競爭參與方不多的情況下，效率高。每個(gè) Follower 通過 Watch 感知到節(jié)點(diǎn)被刪除的時(shí)間不完全一樣，只要有一個(gè) Follower 得到通知即發(fā)起競選，即可保證當(dāng)時(shí)有新的 Leader 被選出
• 給Zookeeper 集群造成的負(fù)載大，因此擴(kuò)展性差。如果有上萬個(gè)客戶端都參與競選，意味著同時(shí)會(huì)有上萬個(gè)寫請求發(fā)送給 Zookeper。如《Zookeeper架構(gòu)》一文所述，Zookeeper 存在單點(diǎn)寫的問題，寫性能不高。同時(shí)一旦 Leader 放棄領(lǐng)導(dǎo)權(quán)，Zookeeper 需要同時(shí)通知上萬個(gè) Follower，負(fù)載較大。

三、公平領(lǐng)導(dǎo)選舉

1. 選主過程

如下圖所示，公平領(lǐng)導(dǎo)選舉中，各客戶端均創(chuàng)建/zkroot/leader節(jié)點(diǎn)，且其類型為Ephemeral與Sequence。

由于是Sequence類型節(jié)點(diǎn)，故上圖中三個(gè)客戶端均創(chuàng)建成功，只是序號(hào)不一樣。此時(shí)，每個(gè)客戶端都會(huì)判斷自己創(chuàng)建成功的節(jié)點(diǎn)的序號(hào)是不是當(dāng)前最小的。如果是，則該客戶端為 Leader，否則即為 Follower。

在上圖中，Client 1創(chuàng)建的節(jié)點(diǎn)序號(hào)為 1 ，Client 2創(chuàng)建的節(jié)點(diǎn)序號(hào)為 2，Client 3創(chuàng)建的節(jié)點(diǎn)序號(hào)為3。由于最小序號(hào)為 1 ，且該節(jié)點(diǎn)由Client 1創(chuàng)建，故Client 1為 Leader 。

2. 放棄領(lǐng)導(dǎo)權(quán)

Leader 如果主動(dòng)放棄領(lǐng)導(dǎo)權(quán)，直接刪除其創(chuàng)建的節(jié)點(diǎn)即可。

如果 Leader 所在進(jìn)程意外宕機(jī)，其與 Zookeeper 間的 Session 結(jié)束，由于其創(chuàng)建的節(jié)點(diǎn)為Ephemeral類型，故該節(jié)點(diǎn)自動(dòng)被刪除。

3. 感知領(lǐng)導(dǎo)權(quán)的放棄

與非公平模式不同，每個(gè) Follower 并非都 Watch 由 Leader 創(chuàng)建出來的節(jié)點(diǎn)，而是 Watch 序號(hào)剛好比自己序號(hào)小的節(jié)點(diǎn)。

在上圖中，總共有 1、2、3 共三個(gè)節(jié)點(diǎn)，因此Client 2 Watch /zkroot/leader1，Client 3 Watch /zkroot/leader2。(注：序號(hào)應(yīng)該是10位數(shù)字，而非一位數(shù)字，這里為了方便，以一位數(shù)字代替)

一旦 Leader 宕機(jī)，/zkroot/leader1被刪除，Client 2可得到通知。此時(shí)Client 3由于 Watch 的是/zkroot/leader2，故不會(huì)得到通知。

4. 重新選舉

Client 2得到/zkroot/leader1被刪除的通知后，不會(huì)立即成為新的 Leader 。而是先判斷自己的序號(hào) 2 是不是當(dāng)前最小的序號(hào)。在該場景下，其序號(hào)確為最小。因此Client 2成為新的 Leader 。

這里要注意，如果在Client 1放棄領(lǐng)導(dǎo)權(quán)之前，Client 2就宕機(jī)了，Client 3會(huì)收到通知。此時(shí)Client 3不會(huì)立即成為Leader，而是要先判斷自己的序號(hào) 3 是否為當(dāng)前最小序號(hào)。很顯然，由于Client 1創(chuàng)建的/zkroot/leader1還在，因此Client 3不會(huì)成為新的 Leader ，并向Client 2序號(hào) 2 前面的序號(hào)，也即 1 創(chuàng)建 Watch。該過程如下圖所示。

5. 公平模式總結(jié)

• 實(shí)現(xiàn)相對復(fù)雜
• 擴(kuò)展性好，每個(gè)客戶端都只 Watch 一個(gè)節(jié)點(diǎn)且每次節(jié)點(diǎn)被刪除只須通知一個(gè)客戶端
• 舊 Leader 放棄領(lǐng)導(dǎo)權(quán)時(shí)，其它客戶端根據(jù)競選的先后順序(也即節(jié)點(diǎn)序號(hào))成為新 Leader，這也是公平模式的由來
• 延遲相對非公平模式要高，因?yàn)樗仨毜却囟ü?jié)點(diǎn)得到通知才能選出新的 Leader

四、總結(jié)

基于 Zookeeper 的領(lǐng)導(dǎo)選舉或者分布式鎖的實(shí)現(xiàn)均基于 Zookeeper 節(jié)點(diǎn)的特性及通知機(jī)制。充分利用這些特性，還可以開發(fā)出適用于其它場景的分布式應(yīng)用。

【本文為51CTO專欄作者“郭俊”的原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文

當(dāng)前題目：深入淺出Zookeeper（二） 基于Zookeeper的分布式鎖與領(lǐng)導(dǎo)選舉
文章來源：http://uogjgqi.cn/article/djpsops.html