本文內容參考網路，侵刪

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：
> www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解常見的分散式技術、以及一些較為常見的分散式系統概念，同時也需要進一步瞭解zookeeper、分散式事務、分散式鎖、負載均衡等技術，以便讓你更完整地瞭解分散式技術的具體實戰方法，為真正應用分散式技術做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

## ZAB協議

1.  ZAB協議是專門為zookeeper實現分散式協調功能而設計。zookeeper主要是根據ZAB協議是實現分散式系統資料一致性。
2.  zookeeper根據ZAB協議建立了主備模型完成zookeeper叢集中資料的同步。這裡所說的主備系統架構模型是指，在zookeeper叢集中，只有一臺leader負責處理外部客戶端的事物請求(或寫操作)，然後leader伺服器將客戶端的寫運算元據同步到所有的follower節點中。 
    ![這裡寫圖片描述](https://img-blog.csdn.net/20170825170158491?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvanVuY2hlbmJiMDQzMA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
3.  ZAB的協議核心是在整個zookeeper叢集中只有一個節點即Leader將客戶端的寫操作轉化為事物(或提議proposal)。Leader節點再資料寫完之後，將向所有的follower節點傳送資料廣播請求(或資料複製)，等待所有的follower節點反饋。在ZAB協議中，只要超過半數follower節點反饋OK，Leader節點就會向所有的follower伺服器傳送commit訊息。即將leader節點上的資料同步到follower節點之上。 
    ![這裡寫圖片描述](https://img-blog.csdn.net/20170825173220443?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvanVuY2hlbmJiMDQzMA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
4.  ZAB協議中主要有兩種模式，第一是訊息廣播模式；第二是崩潰恢復模式

## 訊息廣播模式

1.  在zookeeper叢集中資料副本的傳遞策略就是採用訊息廣播模式。zookeeper中資料副本的同步方式與二階段提交相似但是卻又不同。二階段提交的要求協調者必須等到所有的參與者全部反饋ACK確認訊息後，再傳送commit訊息。要求所有的參與者要麼全部成功要麼全部失敗。二階段提交會產生嚴重阻塞問題。
2.  ZAB協議中Leader等待follower的ACK反饋是指”只要半數以上的follower成功反饋即可，不需要收到全部follower反饋”
3.  圖中展示了訊息廣播的具體流程圖 
    ![這裡寫圖片描述](https://img-blog.csdn.net/20170830143129971?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvanVuY2hlbmJiMDQzMA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
4.  zookeeper中訊息廣播的具體步驟如下： 
    4.1\. 客戶端發起一個寫操作請求 
    4.2\. Leader伺服器將客戶端的request請求轉化為事物proposql提案，同時為每個proposal分配一個全域性唯一的ID，即ZXID。 
    4.3\. leader伺服器與每個follower之間都有一個佇列，leader將訊息傳送到該佇列 
    4.4\. follower機器從佇列中取出訊息處理完(寫入本地事物日誌中)畢後，向leader伺服器傳送ACK確認。 
    4.5\. leader伺服器收到半數以上的follower的ACK後，即認為可以傳送commit 
    4.6\. leader向所有的follower伺服器傳送commit訊息。
5.  zookeeper採用ZAB協議的核心就是隻要有一臺伺服器提交了proposal，就要確保所有的伺服器最終都能正確提交proposal。這也是CAP/BASE最終實現一致性的一個體現。
6.  leader伺服器與每個follower之間都有一個單獨的佇列進行收發訊息，使用佇列訊息可以做到非同步解耦。leader和follower之間只要往佇列中傳送了訊息即可。如果使用同步方式容易引起阻塞。效能上要下降很多。

## 崩潰恢復

1.  zookeeper叢集中為保證任何所有程式能夠有序的順序執行，只能是leader伺服器接受寫請求，即使是follower伺服器接受到客戶端的請求，也會轉發到leader伺服器進行處理。
2.  如果leader伺服器發生崩潰，則zab協議要求zookeeper叢集進行崩潰恢復和leader伺服器選舉。
3.  ZAB協議崩潰恢復要求滿足如下2個要求： 
    3.1. 確保已經被leader提交的proposal必須最終被所有的follower伺服器提交。 
    3.2. 確保丟棄已經被leader出的但是沒有被提交的proposal。
4.  根據上述要求，新選舉出來的leader不能包含未提交的proposal，即新選舉的leader必須都是已經提交了的proposal的follower伺服器節點。同時，新選舉的leader節點中含有最高的ZXID。這樣做的好處就是可以避免了leader伺服器檢查proposal的提交和丟棄工作。
5.  leader伺服器發生崩潰時分為如下場景： 
    5.1\. leader在提出proposal時未提交之前崩潰，則經過崩潰恢復之後，新選舉的leader一定不能是剛才的leader。因為這個leader存在未提交的proposal。 
    5.2 leader在傳送commit訊息之後，崩潰。即訊息已經傳送到佇列中。經過崩潰恢復之後，參與選舉的follower伺服器(剛才崩潰的leader有可能已經恢復執行，也屬於follower節點範疇)中有的節點已經是消費了佇列中所有的commit訊息。即該follower節點將會被選舉為最新的leader。剩下動作就是資料同步過程。

### 資料同步

1.  在zookeeper叢集中新的leader選舉成功之後，leader會將自身的提交的最大proposal的事物ZXID傳送給其他的follower節點。follower節點會根據leader的訊息進行回退或者是資料同步操作。最終目的要保證叢集中所有節點的資料副本保持一致。
2.  資料同步完之後，zookeeper叢集如何保證新選舉的leader分配的ZXID是全域性唯一呢？這個就要從ZXID的設計談起。 
    2.1 ZXID是一個長度64位的數字，其中低32位是按照數字遞增，即每次客戶端發起一個proposal,低32位的數字簡單加1。高32位是leader週期的epoch編號，至於這個編號如何產生(我也沒有搞明白)，每當選舉出一個新的leader時，新的leader就從本地事物日誌中取出ZXID,然後解析出高32位的epoch編號，進行加1，再將低32位的全部設定為0。這樣就保證了每次新選舉的leader後，保證了ZXID的唯一性而且是保證遞增的。 
    ![這裡寫圖片描述](https://img-blog.csdn.net/20170830173303656?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvanVuY2hlbmJiMDQzMA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)

## ZAB協議原理

1.  ZAB協議要求每個leader都要經歷三個階段，即發現，同步，廣播。
2.  發現：即要求zookeeper叢集必須選擇出一個leader程式，同時leader會維護一個follower可用列表。將來客戶端可以這follower中的節點進行通訊。
3.  同步：leader要負責將本身的資料與follower完成同步，做到多副本儲存。這樣也是體現了CAP中高可用和分割槽容錯。follower將佇列中未處理完的請求消費完成後，寫入本地事物日誌中。
4.  廣播：leader可以接受客戶端新的proposal請求，將新的proposal請求廣播給所有的follower。

## Zookeeper設計目標

1.  zookeeper作為當今最流行的分散式系統應用協調框架，採用zab協議的最大目標就是建立一個高可用可擴充套件的分散式資料主備系統。即在任何時刻只要leader發生當機，都能保證分散式系統資料的可靠性和最終一致性。
2.  深刻理解ZAB協議，才能更好的理解zookeeper對於分散式系統建設的重要性。以及為什麼採用zookeeper就能保證分散式系統中資料最終一致性，服務的高可用性。

Zab與Paxos
Zab的作者認為Zab與paxos並不相同，只所以沒有采用Paxos是因為Paxos保證不了全序順序：
Because multiple leaders can propose a value for a given instance two problems arise.
First, proposals can conflict. Paxos uses ballots to detect and resolve conflicting proposals.
Second, it is not enough to know that a given instance number has been committed, processes must also be able to fi gure out which value has been committed.
Paxos演算法的確是不關心請求之間的邏輯順序，而只考慮資料之間的全序，但很少有人直接使用paxos演算法，都會經過一定的簡化、最佳化。

Paxos演算法最佳化
Paxos演算法在出現競爭的情況下，其收斂速度很慢，甚至可能出現活鎖的情況，例如當有三個及三個以上的proposer在傳送prepare請求後，很難有一個proposer收到半數以上的回覆而不斷地執行第一階段的協議。因此，為了避免競爭，加快收斂的速度，在演算法中引入了一個Leader這個角色，在正常情況下同時應該最多隻能有一個參與者扮演Leader角色，而其它的參與者則扮演Acceptor的角色。
在這種最佳化演算法中，只有Leader可以提出議案，從而避免了競爭使得演算法能夠快速地收斂而趨於一致；而為了保證Leader的健壯性，又引入了Leader選舉，再考慮到同步的階段，漸漸的你會發現對Paxos演算法的簡化和最佳化已經和上面介紹的ZAB協議很相似了。

總結
Google的粗粒度鎖服務Chubby的設計開發者Burrows曾經說過：“所有一致性協議本質上要麼是Paxos要麼是其變體”。這句話還是有一定道理的，ZAB本質上就是Paxos的一種簡化形式。

# ZAB與FastLeaderElection選主演算法流程詳解

這篇主要分析leader的選主機制，zookeeper提供了三種方式：

*   LeaderElection
*   AuthFastLeaderElection
*   FastLeaderElection

預設的演算法是FastLeaderElection，所以這篇主要分析它的選舉機制。

## 選擇機制中的概念

### 伺服器ID

比如有三臺伺服器，編號分別是1,2,3。

> 編號越大在選擇演算法中的權重越大。

### 資料ID

伺服器中存放的最大資料ID.

> 值越大說明資料越新，在選舉演算法中資料越新權重越大。

### 邏輯時鐘

或者叫投票的次數，同一輪投票過程中的邏輯時鐘值是相同的。每投完一次票這個資料就會增加，然後與接收到的其它伺服器返回的投票資訊中的數值相比，根據不同的值做出不同的判斷。

### 選舉狀態

*   LOOKING，競選狀態。
*   FOLLOWING，隨從狀態，同步leader狀態，參與投票。
*   OBSERVING，觀察狀態,同步leader狀態，不參與投票。
*   LEADING，領導者狀態。

## 選舉訊息內容

在投票完成後，需要將投票資訊傳送給叢集中的所有伺服器，它包含如下內容。

*   伺服器ID
*   資料ID
*   邏輯時鐘
*   選舉狀態

## 選舉流程圖

因為每個伺服器都是獨立的，在啟動時均從初始狀態開始參與選舉，下面是簡易流程圖。

![](https://images2015.cnblogs.com/blog/17071/201702/17071-20170220211539679-433574967.jpg)

下面詳細解釋一下這個流程：

首先給出幾個名詞定義：

（1）Serverid：在配置server時，給定的伺服器的標示id。

（2）Zxid:伺服器在執行時產生的資料id，zxid越大，表示資料越新。

（3）Epoch：選舉的輪數，即邏輯時鐘。隨著選舉的輪數++

（4）Server狀態：LOOKING,FOLLOWING,OBSERVING,LEADING

步驟：

一、  Server剛啟動（當機恢復或者剛啟動）準備加入叢集，此時讀取自身的zxid等資訊。

二、  所有Server加入叢集時都會推薦自己為leader，然後將（leader id 、 zixd 、 epoch）作為廣播資訊，廣播到叢集中所有的伺服器(Server)。然後等待叢集中的伺服器返回資訊。

三、  收到叢集中其他伺服器返回的資訊，此時要分為兩類：該伺服器處於looking狀態，或者其他狀態。

（1）    伺服器處於looking狀態

首先判斷邏輯時鐘 Epoch:

a)     如果接收到Epoch大於自己目前的邏輯時鐘（說明自己所儲存的邏輯時鐘落伍了）。更新本機邏輯時鐘Epoch，同時 Clear其他服務傳送來的選舉資料（這些資料已經OUT了）。然後判斷是否需要更新當前自己的選舉情況（一開始選擇的leader id 是自己）

判斷規則rules judging：儲存的zxid最大值和leader Serverid來進行判斷的。先看資料zxid,資料zxid大者勝出;其次再判斷leaderServerid, leader Serverid大者勝出；然後再將自身最新的選舉結果(也就是上面提到的三種資料（leader Serverid，Zxid，Epoch）廣播給其他server)

b)     如果接收到的Epoch小於目前的邏輯時鐘。說明對方處於一個比較OUT的選舉輪數，這時只需要將自己的 （leader Serverid，Zxid，Epoch）傳送給他即可。

c)     如果接收到的Epoch等於目前的邏輯時鐘。再根據a)中的判斷規則，將自身的最新選舉結果廣播給其他 server。

同時Server還要處理2種情況：

a)    如果Server接收到了其他所有伺服器的選舉資訊，那麼則根據這些選舉資訊確定自己的狀態（Following,Leading），結束Looking，退出選舉。

b)   即使沒有收到所有伺服器的選舉資訊，也可以判斷一下根據以上過程之後最新的選舉leader是不是得到了超過半數以上伺服器的支援，如果是則嘗試接受最新資料，倘若沒有最新的資料到來，說明大家都已經預設了這個結果,同樣也設定角色退出選舉過程。

（2）    伺服器處於其他狀態（Following, Leading）

a)     如果邏輯時鐘Epoch相同,將該資料儲存到recvset,如果所接收伺服器宣稱自己是leader,那麼將判斷是不是有半數以上的伺服器選舉它,如果是則設定選舉狀態退出選舉過程

b)     否則這是一條與當前邏輯時鐘不符合的訊息，那麼說明在另一個選舉過程中已經有了選舉結果，於是將該選舉結果加入到outofelection集合中，再根據outofelection來判斷是否可以結束選舉,如果可以也是儲存邏輯時鐘，設定選舉狀態，退出選舉過程。

以上就是FAST選舉過程。

Zookeeper具體的啟動日誌如下圖所示：

![](https://blog.csdn.net/cnh294141800/article/details/52959028)![](https://blog.csdn.net/cnh294141800/article/details/52959028)![](https://img-blog.csdn.net/20161028191618720?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)

以上就是我自己配置的Zookeeper選主日誌，從一開始LOOKING,然後new election, my id = 1, proposedzxid=0x0  也就是選自己為Leader,之後廣播選舉並重復之前Fast選主演算法，最終確定Leader。

## 原始碼分析

### QuorumPeer

主要看這個類，只有LOOKING狀態才會去執行選舉演算法。每個伺服器在啟動時都會選擇自己做為領導，然後將投票資訊傳送出去，迴圈一直到選舉出領導為止。

<pre>public void run() {
        //.......

try {
            while (running) {
                switch (getPeerState()) {
                case LOOKING:
                    if (Boolean.getBoolean("readonlymode.enabled")) {
                        //...
                        try {
                           //投票給自己...
                            setCurrentVote(makeLEStrategy().lookForLeader());
                        } catch (Exception e) {
                            //...
                        } finally {
                            //...
                        }
                    } else {
                        try {
                           //...
                            setCurrentVote(makeLEStrategy().lookForLeader());
                        } catch (Exception e) {
                            //...
                        }                        
                    }
                    break;
                case OBSERVING:
                    //...
                    break;
                case FOLLOWING:
                    //...
                    break;
                case LEADING:
                    //...
                    break;
                }

}
        } finally {
            //...
        }
    }</pre>

### FastLeaderElection

它是zookeeper預設提供的選舉演算法，核心方法如下：具體的可以與本文上面的流程圖對照。

<pre>public Vote lookForLeader() throws InterruptedException {
        //...
        try {
            HashMap<long vote=""> recvset = new HashMap<long vote="">();

HashMap<long vote=""> outofelection = new HashMap<long vote="">();

int notTimeout = finalizeWait;

synchronized(this){
                //給自己投票
                logicalclock.incrementAndGet();
                updateProposal(getInitId(), getInitLastLoggedZxid(), getPeerEpoch());
            }

//將投票資訊傳送給叢集中的每個伺服器
            sendNotifications();

//迴圈，如果是競選狀態一直到選舉出結果

while ((self.getPeerState() == ServerState.LOOKING) &&
                    (!stop)){

Notification n = recvqueue.poll(notTimeout,
                        TimeUnit.MILLISECONDS);

//沒有收到投票資訊
                if(n == null){
                    if(manager.haveDelivered()){
                        sendNotifications();
                    } else {
                        manager.connectAll();
                    }

//...
                } 
                //收到投票資訊
                else if (self.getCurrentAndNextConfigVoters().contains(n.sid)) {

switch (n.state) {
                    case LOOKING:

// 判斷投票是否過時，如果過時就清除之前已經接收到的資訊 
                        if (n.electionEpoch > logicalclock.get()) {
                            logicalclock.set(n.electionEpoch);
                            recvset.clear();
                            //更新投票資訊
                            if(totalOrderPredicate(n.leader, n.zxid, n.peerEpoch,
                                    getInitId(), getInitLastLoggedZxid(), getPeerEpoch())) {
                                updateProposal(n.leader, n.zxid, n.peerEpoch);
                            } else {
                                updateProposal(getInitId(),
                                        getInitLastLoggedZxid(),
                                        getPeerEpoch());
                            }
                            //傳送投票資訊
                            sendNotifications();
                        } else if (n.electionEpoch < logicalclock.get()) {
                            //忽略
                            break;
                        } else if (totalOrderPredicate(n.leader, n.zxid, n.peerEpoch,
                                proposedLeader, proposedZxid, proposedEpoch)) {
                            //更新投票資訊
                            updateProposal(n.leader, n.zxid, n.peerEpoch);
                            sendNotifications();
                        }

recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));
                        //判斷是否投票結束
                        if (termPredicate(recvset,
                                new Vote(proposedLeader, proposedZxid,
                                        logicalclock.get(), proposedEpoch))) {

// Verify if there is any change in the proposed leader
                            while((n = recvqueue.poll(finalizeWait,
                                    TimeUnit.MILLISECONDS)) != null){
                                if(totalOrderPredicate(n.leader, n.zxid, n.peerEpoch,
                                        proposedLeader, proposedZxid, proposedEpoch)){
                                    recvqueue.put(n);
                                    break;
                                }
                            }

if (n == null) {
                                self.setPeerState((proposedLeader == self.getId()) ?
                                        ServerState.LEADING: learningState());

Vote endVote = new Vote(proposedLeader,
                                        proposedZxid, proposedEpoch);
                                leaveInstance(endVote);
                                return endVote;
                            }
                        }
                        break;
                    case OBSERVING:
                        //忽略
                        break;
                    case FOLLOWING:
                    case LEADING:
                        //如果是同一輪投票
                        if(n.electionEpoch == logicalclock.get()){
                            recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));
                            //判斷是否投票結束
                            if(termPredicate(recvset, new Vote(n.leader,
                                            n.zxid, n.electionEpoch, n.peerEpoch, n.state))
                                            && checkLeader(outofelection, n.leader, n.electionEpoch)) {
                                self.setPeerState((n.leader == self.getId()) ?
                                        ServerState.LEADING: learningState());

Vote endVote = new Vote(n.leader, n.zxid, n.peerEpoch);
                                leaveInstance(endVote);
                                return endVote;
                            }
                        }

//記錄投票已經完成
                        outofelection.put(n.sid, new Vote(n.leader, 
                                IGNOREVALUE, IGNOREVALUE, n.peerEpoch, n.state));
                        if (termPredicate(outofelection, new Vote(n.leader,
                                IGNOREVALUE, IGNOREVALUE, n.peerEpoch, n.state))
                                && checkLeader(outofelection, n.leader, IGNOREVALUE)) {
                            synchronized(this){
                                logicalclock.set(n.electionEpoch);
                                self.setPeerState((n.leader == self.getId()) ?
                                        ServerState.LEADING: learningState());
                            }
                            Vote endVote = new Vote(n.leader, n.zxid, n.peerEpoch);
                            leaveInstance(endVote);
                            return endVote;
                        }
                        break;
                    default:
                        //忽略
                        break;
                    }
                } else {
                    LOG.warn("Ignoring notification from non-cluster member " + n.sid);
                }
            }
            return null;
        } finally {
            //...
        }
    }</long></long></long></long></pre>

### 判斷是否已經勝出

預設是採用投票數大於半數則勝出的邏輯。

## 選舉流程簡述

目前有5臺伺服器，每臺伺服器均沒有資料，它們的編號分別是1,2,3,4,5,按編號依次啟動，它們的選擇舉過程如下：

*   伺服器1啟動，給自己投票，然後發投票資訊，由於其它機器還沒有啟動所以它收不到反饋資訊，伺服器1的狀態一直屬於Looking。
*   伺服器2啟動，給自己投票，同時與之前啟動的伺服器1交換結果，由於伺服器2的編號大所以伺服器2勝出，但此時投票數沒有大於半數，所以兩個伺服器的狀態依然是LOOKING。
*   伺服器3啟動，給自己投票，同時與之前啟動的伺服器1,2交換資訊，由於伺服器3的編號最大所以伺服器3勝出，此時投票數正好大於半數，所以伺服器3成為領導者，伺服器1,2成為小弟。
*   伺服器4啟動，給自己投票，同時與之前啟動的伺服器1,2,3交換資訊，儘管伺服器4的編號大，但之前伺服器3已經勝出，所以伺服器4只能成為小弟。
*   伺服器5啟動，後面的邏輯同伺服器4成為小弟。

## [](http://www.jasongj.com/zookeeper/fastleaderelection/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#%E5%87%A0%E7%A7%8D%E9%A2%86%E5%AF%BC%E9%80%89%E4%B8%BE%E5%9C%BA%E6%99%AF "幾種領導選舉場景")幾種領導選舉場景

### [](http://www.jasongj.com/zookeeper/fastleaderelection/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#%E9%9B%86%E7%BE%A4%E5%90%AF%E5%8A%A8%E9%A2%86%E5%AF%BC%E9%80%89%E4%B8%BE "叢集啟動領導選舉")叢集啟動領導選舉

**_初始投票給自己_**
叢集剛啟動時，所有伺服器的logicClock都為1，zxid都為0。

各伺服器初始化後，都投票給自己，並將自己的一票存入自己的票箱，如下圖所示。

[![Cluster start election step 1](http://www.jasongj.com/img/zookeeper/1_architecture/start_election_1.png)](http://www.jasongj.com/img/zookeeper/1_architecture/start_election_1.png)

在上圖中，(1, 1, 0)第一位數代表投出該選票的伺服器的logicClock，第二位數代表被推薦的伺服器的myid，第三位代表被推薦的伺服器的最大的zxid。由於該步驟中所有選票都投給自己，所以第二位的myid即是自己的myid，第三位的zxid即是自己的zxid。

此時各自的票箱中只有自己投給自己的一票。

**_更新選票_**
伺服器收到外部投票後，進行選票PK，相應更新自己的選票並廣播出去，並將合適的選票存入自己的票箱，如下圖所示。

[![Cluster start election step 2](http://www.jasongj.com/img/zookeeper/1_architecture/start_election_2.png)](http://www.jasongj.com/img/zookeeper/1_architecture/start_election_2.png)

伺服器1收到伺服器2的選票（1, 2, 0）和伺服器3的選票（1, 3, 0）後，由於所有的logicClock都相等，所有的zxid都相等，因此根據myid判斷應該將自己的選票按照伺服器3的選票更新為（1, 3, 0），並將自己的票箱全部清空，再將伺服器3的選票與自己的選票存入自己的票箱，接著將自己更新後的選票廣播出去。此時伺服器1票箱內的選票為(1, 3)，(3, 3)。

同理，伺服器2收到伺服器3的選票後也將自己的選票更新為（1, 3, 0）並存入票箱然後廣播。此時伺服器2票箱內的選票為(2, 3)，(3, ,3)。

伺服器3根據上述規則，無須更新選票，自身的票箱內選票仍為（3, 3）。

伺服器1與伺服器2更新後的選票廣播出去後，由於三個伺服器最新選票都相同，最後三者的票箱內都包含三張投給伺服器3的選票。

**_根據選票確定角色_**
根據上述選票，三個伺服器一致認為此時伺服器3應該是Leader。因此伺服器1和2都進入FOLLOWING狀態，而伺服器3進入LEADING狀態。之後Leader發起並維護與Follower間的心跳。

[![Cluster start election step 3](http://www.jasongj.com/img/zookeeper/1_architecture/start_election_3.png)](http://www.jasongj.com/img/zookeeper/1_architecture/start_election_3.png)

### [](http://www.jasongj.com/zookeeper/fastleaderelection/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#Follower%E9%87%8D%E5%90%AF "Follower重啟")Follower重啟

**_Follower重啟投票給自己_**
Follower重啟，或者發生網路分割槽後找不到Leader，會進入LOOKING狀態併發起新的一輪投票。

[![Follower restart election step 1](http://www.jasongj.com/img/zookeeper/1_architecture/follower_restart_election_1.png)](http://www.jasongj.com/img/zookeeper/1_architecture/follower_restart_election_1.png)

**_發現已有Leader後成為Follower_**
伺服器3收到伺服器1的投票後，將自己的狀態LEADING以及選票返回給伺服器1。伺服器2收到伺服器1的投票後，將自己的狀態FOLLOWING及選票返回給伺服器1。此時伺服器1知道伺服器3是Leader，並且透過伺服器2與伺服器3的選票可以確定伺服器3確實得到了超過半數的選票。因此伺服器1進入FOLLOWING狀態。

[![Follower restart election step 2](http://www.jasongj.com/img/zookeeper/1_architecture/follower_restart_election_2.png)](http://www.jasongj.com/img/zookeeper/1_architecture/follower_restart_election_2.png)

### [](http://www.jasongj.com/zookeeper/fastleaderelection/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#Leader%E9%87%8D%E5%90%AF "Leader重啟")Leader重啟

**_Follower發起新投票_**
Leader（伺服器3）當機後，Follower（伺服器1和2）發現Leader不工作了，因此進入LOOKING狀態併發起新的一輪投票，並且都將票投給自己。

[![Leader restart election step 1](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_1.png)](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_1.png)

**_廣播更新選票_**
伺服器1和2根據外部投票確定是否要更新自身的選票。這裡有兩種情況

*   伺服器1和2的zxid相同。例如在伺服器3當機前伺服器1與2完全與之同步。此時選票的更新主要取決於myid的大小
*   伺服器1和2的zxid不同。在舊Leader當機之前，其所主導的寫操作，只需過半伺服器確認即可，而不需所有伺服器確認。換句話說，伺服器1和2可能一個與舊Leader同步（即zxid與之相同）另一個不同步（即zxid比之小）。此時選票的更新主要取決於誰的zxid較大

在上圖中，伺服器1的zxid為11，而伺服器2的zxid為10，因此伺服器2將自身選票更新為（3, 1, 11），如下圖所示。

[![Leader restart election step 2](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_2.png)](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_2.png)

**_選出新Leader_**
經過上一步選票更新後，伺服器1與伺服器2均將選票投給伺服器1，因此伺服器2成為Follower，而伺服器1成為新的Leader並維護與伺服器2的心跳。

[![Leader restart election step 3](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_3.png)](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_3.png)

**_舊Leader恢復後發起選舉_**
舊的Leader恢復後，進入LOOKING狀態併發起新一輪領導選舉，並將選票投給自己。此時伺服器1會將自己的LEADING狀態及選票（3, 1, 11）返回給伺服器3，而伺服器2將自己的FOLLOWING狀態及選票（3, 1, 11）返回給伺服器3。如下圖所示。

[![Leader restart election step 4](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_4.png)](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_4.png)

**_舊Leader成為Follower_**
伺服器3瞭解到Leader為伺服器1，且根據選票瞭解到伺服器1確實得到過半伺服器的選票，因此自己進入FOLLOWING狀態。

[![Leader restart election step 5](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_5.png)](http://www.jasongj.com/img/zookeeper/1_architecture/leader_restart_election_5.png)

# [](http://www.jasongj.com/zookeeper/fastleaderelection/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#%E4%B8%80%E8%87%B4%E6%80%A7%E4%BF%9D%E8%AF%81 "一致性保證")一致性保證

ZAB協議保證了在Leader選舉的過程中，已經被Commit的資料不會丟失，未被Commit的資料對客戶端不可見。

## [](http://www.jasongj.com/zookeeper/fastleaderelection/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#Commit%E8%BF%87%E7%9A%84%E6%95%B0%E6%8D%AE%E4%B8%8D%E4%B8%A2%E5%A4%B1 "Commit過的資料不丟失")Commit過的資料不丟失

**_Failover前狀態_**
為更好演示Leader Failover過程，本例中使用5個Zookeeper伺服器。A作為Leader，共收到P1、P2、P3三條訊息，並且Commit了1和2，且總體順序為P1、P2、C1、P3、C2。根據順序性原則，其它Follower收到的訊息的順序肯定與之相同。其中B與A完全同步，C收到P1、P2、C1，D收到P1、P2，E收到P1，如下圖所示。

[![Leader Failover step 1](http://www.jasongj.com/img/zookeeper/1_architecture/recovery_1.png)](http://www.jasongj.com/img/zookeeper/1_architecture/recovery_1.png)

這裡要注意

*   由於A沒有C3，意味著收到P3的伺服器的總個數不會超過一半，也即包含A在內最多隻有兩臺伺服器收到P3。在這裡A和B收到P3，其它伺服器均未收到P3
*   由於A已寫入C1、C2，說明它已經Commit了P1、P2，因此整個叢集有超過一半的伺服器，即最少三個伺服器收到P1、P2。在這裡所有伺服器都收到了P1，除E外其它伺服器也都收到了P2

**_選出新Leader_**
舊Leader也即A當機後，其它伺服器根據上述FastLeaderElection演算法選出B作為新的Leader。C、D和E成為Follower且以B為Leader後，會主動將自己最大的zxid傳送給B，B會將Follower的zxid與自身zxid間的所有被Commit過的訊息同步給Follower，如下圖所示。

[![Leader Failover step 2](http://www.jasongj.com/img/zookeeper/1_architecture/recovery_2.png)](http://www.jasongj.com/img/zookeeper/1_architecture/recovery_2.png)

在上圖中

*   P1和P2都被A Commit，因此B會透過同步保證P1、P2、C1與C2都存在於C、D和E中
*   P3由於未被A Commit，同時倖存的所有伺服器中P3未存在於大多資料伺服器中，因此它不會被同步到其它Follower

**_通知Follower可對外服務_**
同步完資料後，B會向D、C和E傳送NEWLEADER命令並等待大多數伺服器的ACK（下圖中D和E已返回ACK，加上B自身，已經佔叢集的大多數），然後向所有伺服器廣播UPTODATE命令。收到該命令後的伺服器即可對外提供服務。

[![Leader Failover step 3](http://www.jasongj.com/img/zookeeper/1_architecture/recovery_3.png)](http://www.jasongj.com/img/zookeeper/1_architecture/recovery_3.png)

## [](http://www.jasongj.com/zookeeper/fastleaderelection/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#%E6%9C%AACommit%E8%BF%87%E7%9A%84%E6%B6%88%E6%81%AF%E5%AF%B9%E5%AE%A2%E6%88%B7%E7%AB%AF%E4%B8%8D%E5%8F%AF%E8%A7%81 "未Commit過的訊息對客戶端不可見")未Commit過的訊息對客戶端不可見

在上例中，P3未被A Commit過，同時因為沒有過半的伺服器收到P3，因此B也未Commit P3（如果有過半伺服器收到P3，即使A未Commit P3，B會主動Commit P3，即C3），所以它不會將P3廣播出去。

具體做法是，B在成為Leader後，先判斷自身未Commit的訊息（本例中即P3）是否存在於大多數伺服器中從而決定是否要將其Commit。然後B可得出自身所包含的被Commit過的訊息中的最小zxid（記為min_zxid）與最大zxid（記為max_zxid）。C、D和E向B傳送自身Commit過的最大訊息zxid（記為max_zxid）以及未被Commit過的所有訊息（記為zxid_set）。B根據這些資訊作出如下操作

*   如果Follower的max_zxid與Leader的max_zxid相等，說明該Follower與Leader完全同步，無須同步任何資料
*   如果Follower的max_zxid在Leader的(min_zxid，max_zxid)範圍內，Leader會透過TRUNC命令通知Follower將其zxid_set中大於Follower的max_zxid（如果有）的所有訊息全部刪除

上述操作保證了未被Commit過的訊息不會被Commit從而對外不可見。

上述例子中Follower上並不存在未被Commit的訊息。但可考慮這種情況，如果將上述例子中的伺服器數量從五增加到七，伺服器F包含P1、P2、C1、P3，伺服器G包含P1、P2。此時伺服器F、A和B都包含P3，但是因為票數未過半，因此B作為Leader不會Commit P3，而會透過TRUNC命令通知F刪除P3。如下圖所示。

[![Leader Failover step 4](http://www.jasongj.com/img/zookeeper/1_architecture/recovery_4.png)](http://www.jasongj.com/img/zookeeper/1_architecture/recovery_4.png)

# [](http://www.jasongj.com/zookeeper/fastleaderelection/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#%E6%80%BB%E7%BB%93 "總結")總結

*   由於使用主從複製模式，所有的寫操作都要由Leader主導完成，而讀操作可透過任意節點完成，因此Zookeeper讀效能遠好於寫效能，更適合讀多寫少的場景
*   雖然使用主從複製模式，同一時間只有一個Leader，但是Failover機制保證了叢集不存在單點失敗（SPOF）的問題
*   ZAB協議保證了Failover過程中的資料一致性
*   伺服器收到資料後先寫本地檔案再進行處理，保證了資料的永續性

搞懂分散式技術4：ZAB協議概述與選主流程詳解

相關文章