目錄

正文

ZooKeeper中的各種角色

ZooKeeper與客戶端

　　每個(gè)Server在工作過程中有三種狀態(tài)：
　　　　LOOKING：當(dāng)前Server不知道leader是誰，正在搜尋
　　　　LEADING：當(dāng)前Server即為選舉出來的leader
　　　　FOLLOWING：leader已經(jīng)選舉出來，當(dāng)前Server與之同步

Zookeeper節(jié)點(diǎn)數(shù)據(jù)操作流程

注：　　　　

　　1.在Client向Follwer發(fā)出一個(gè)寫的請(qǐng)求

　　2.Follwer把請(qǐng)求發(fā)送給Leader

　　3.Leader接收到以后開始發(fā)起投票并通知Follwer進(jìn)行投票

　　4.Follwer把投票結(jié)果發(fā)送給Leader

　　5.Leader將結(jié)果匯總后如果需要寫入，則開始寫入同時(shí)把寫入操作通知給Leader，然后commit;

　　6.Follwer把請(qǐng)求結(jié)果返回給Client

 Follower主要有四個(gè)功能：

　　1. 向Leader發(fā)送請(qǐng)求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；

　　2 .接收Leader消息并進(jìn)行處理；

　　3 .接收Client的請(qǐng)求，如果為寫請(qǐng)求，發(fā)送給Leader進(jìn)行投票；

　　4 .返回Client結(jié)果。

Follower的消息循環(huán)處理如下幾種來自Leader的消息：

　　1 .PING消息： 心跳消息；

　　2 .PROPOSAL消息：Leader發(fā)起的提案，要求Follower投票；

　　3 .COMMIT消息：服務(wù)器端最新一次提案的信息；

　　4 .UPTODATE消息：表明同步完成；

　　5 .REVALIDATE消息：根據(jù)Leader的REVALIDATE結(jié)果，關(guān)閉待revalidate的session還是允許其接受消息；

　　6 .SYNC消息：返回SYNC結(jié)果到客戶端，這個(gè)消息最初由客戶端發(fā)起，用來強(qiáng)制得到最新的更新。

Paxos 算法概述（ZAB 協(xié)議） 

 　　Paxos 算法是萊斯利·蘭伯特（英語：Leslie Lamport）于 1990 年提出的一種基于消息傳遞且 具有高度容錯(cuò)特性的一致性算法。

　　分布式系統(tǒng)中的節(jié)點(diǎn)通信存在兩種模型：共享內(nèi)存（Shared memory）和消息傳遞（Messages passing）?；谙鬟f通信模型的分布式系統(tǒng)，不可避免的會(huì)發(fā)生以下錯(cuò)誤：進(jìn)程可能會(huì) 慢、被殺死或者重啟，消息可能會(huì)延遲、丟失、重復(fù)，在基礎(chǔ) Paxos 場(chǎng)景中，先不考慮可能 出現(xiàn)消息篡改即拜占庭錯(cuò)誤（Byzantine failure，即雖然有可能一個(gè)消息被傳遞了兩次，但是 絕對(duì)不會(huì)出現(xiàn)錯(cuò)誤的消息）的情況。Paxos 算法解決的問題是在一個(gè)可能發(fā)生上述異常的分 布式系統(tǒng)中如何就某個(gè)值達(dá)成一致，保證不論發(fā)生以上任何異常，都不會(huì)破壞決議一致性。

　　Paxos 算法使用一個(gè)希臘故事來描述，在 Paxos 中，存在三種角色，分別為

　　　　Proposer（提議者，用來發(fā)出提案 proposal）

　　　　Acceptor（接受者，可以接受或拒絕提案）

　　　　Learner（學(xué)習(xí)者，學(xué)習(xí)被選定的提案，當(dāng)提案被超過半數(shù)的 Acceptor 接受后為被批準(zhǔn)）

　　下面更精確的定義 Paxos 要解決的問題：

　　　　1、決議(value)只有在被 proposer 提出后才能被批準(zhǔn)

　　　　2、在一次 Paxos 算法的執(zhí)行實(shí)例中，只批準(zhǔn)(chose)一個(gè) value

　　　　3、learner 只能獲得被批準(zhǔn)(chosen)的 value

　　ZooKeeper 的選舉算法有兩種：一種是基于 Basic Paxos（Google Chubby 采用）實(shí)現(xiàn)的，另外 一種是基于 Fast Paxos（ZooKeeper 采用）算法實(shí)現(xiàn)的。系統(tǒng)默認(rèn)的選舉算法為 Fast Paxos。 并且 ZooKeeper 在 3.4.0 版本后只保留了 FastLeaderElection 算法。

　　ZooKeeper 的核心是原子廣播，這個(gè)機(jī)制保證了各個(gè) Server 之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié) 議叫做 ZAB 協(xié)議（Zookeeper Atomic BrodCast）。 ZAB 協(xié)議有兩種模式，它們分別是崩潰恢復(fù)模式（選主）和原子廣播模式（同步）。

　　1、當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后，ZAB 就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來，且大 多數(shù) Server 完成了和 leader 的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了 leader 和 follower 之間具有相同的系統(tǒng)狀態(tài)。

 　   2、當(dāng) ZooKeeper 集群選舉出 leader 同步完?duì)顟B(tài)退出恢復(fù)模式之后，便進(jìn)入了原子廣播模式。 所有的寫請(qǐng)求都被轉(zhuǎn)發(fā)給 leader，再由 leader 將更新 proposal 廣播給 follower

 　　為了保證事務(wù)的順序一致性，zookeeper 采用了遞增的事務(wù) id 號(hào)（zxid）來標(biāo)識(shí)事務(wù)。所有 的提議（proposal）都在被提出的時(shí)候加上了 zxid。實(shí)現(xiàn)中 zxid 是一個(gè) 64 位的數(shù)字，它高 32 位是 epoch 用來標(biāo)識(shí) leader 關(guān)系是否改變，每次一個(gè) leader 被選出來，它都會(huì)有一個(gè)新 的 epoch，標(biāo)識(shí)當(dāng)前屬于那個(gè) leader 的統(tǒng)治時(shí)期。低 32 位用于遞增計(jì)數(shù)。　　

 　　這里給大家介紹以下 Basic Paxos 流程：

1、選舉線程由當(dāng)前 Server 發(fā)起選舉的線程擔(dān)任，其主要功能是對(duì)投票結(jié)果進(jìn)行統(tǒng)計(jì)，并選 出推薦的 Server

2、選舉線程首先向所有 Server 發(fā)起一次詢問(包括自己)

3、選舉線程收到回復(fù)后，驗(yàn)證是否是自己發(fā)起的詢問(驗(yàn)證 zxid 是否一致)，然后獲取對(duì)方 的 serverid(myid)，并存儲(chǔ)到當(dāng)前詢問對(duì)象列表中，最后獲取對(duì)方提議的 leader 相關(guān)信息 (serverid,zxid)，并將這些信息存儲(chǔ)到當(dāng)次選舉的投票記錄表中

4、收到所有 Server 回復(fù)以后，就計(jì)算出 id 最大的那個(gè) Server，并將這個(gè) Server 相關(guān)信息設(shè) 置成下一次要投票的 Server

5、線程將當(dāng)前 id 最大的 Server 設(shè)置為當(dāng)前 Server 要推薦的 Leader，如果此時(shí)獲勝的 Server 獲得 n/2 + 1 的 Server 票數(shù)， 設(shè)置當(dāng)前推薦的 leader 為獲勝的 Server，將根據(jù)獲勝的 Server 相關(guān)信息設(shè)置自己的狀態(tài)，否則，繼續(xù)這個(gè)過程，直到 leader 被選舉出來。

 　　通過流程分析我們可以得出：要使 Leader 獲得多數(shù) Server 的支持，則 Server 總數(shù)必須是奇 數(shù) 2n+1，且存活的 Server 的數(shù)目不得少于 n+1。 每個(gè) Server 啟動(dòng)后都會(huì)重復(fù)以上流程。在恢復(fù)模式下，如果是剛從崩潰狀態(tài)恢復(fù)的或者剛 啟動(dòng)的 server 還會(huì)從磁盤快照中恢復(fù)數(shù)據(jù)和會(huì)話信息，zk 會(huì)記錄事務(wù)日志并定期進(jìn)行快照， 方便在恢復(fù)時(shí)進(jìn)行狀態(tài)恢復(fù)。 Fast Paxos 流程是在選舉過程中，某 Server 首先向所有 Server 提議自己要成為 leader，當(dāng)其 它 Server 收到提議以后，解決 epoch 和 zxid 的沖突，并接受對(duì)方的提議，然后向?qū)Ψ桨l(fā)送 接受提議完成的消息，重復(fù)這個(gè)流程，最后一定能選舉出 Leader

ZooKeeper 的選主機(jī)制

選擇機(jī)制中的概念

服務(wù)器ID

比如有三臺(tái)服務(wù)器，編號(hào)分別是1,2,3。

編號(hào)越大在選擇算法中的權(quán)重越大。

數(shù)據(jù)ID

服務(wù)器中存放的最大數(shù)據(jù)ID.

 值越大說明數(shù)據(jù)越新，在選舉算法中數(shù)據(jù)越新權(quán)重越大。

邏輯時(shí)鐘

或者叫投票的次數(shù)，同一輪投票過程中的邏輯時(shí)鐘值是相同的。每投完一次票這個(gè)數(shù)據(jù)就會(huì)增加，然后與接收到的其它服務(wù)器返回的投票信息中的數(shù)值相比，根據(jù)不同的值做出不同的判斷。

選舉狀態(tài)

• LOOKING，競(jìng)選狀態(tài)。
• FOLLOWING，隨從狀態(tài)，同步leader狀態(tài)，參與投票。
• OBSERVING，觀察狀態(tài),同步leader狀態(tài)，不參與投票。
• LEADING，領(lǐng)導(dǎo)者狀態(tài)。

選舉消息內(nèi)容

在投票完成后，需要將投票信息發(fā)送給集群中的所有服務(wù)器，它包含如下內(nèi)容。

• 服務(wù)器ID
• 數(shù)據(jù)ID
• 邏輯時(shí)鐘
• 選舉狀態(tài)

選舉流程圖

因?yàn)槊總€(gè)服務(wù)器都是獨(dú)立的，在啟動(dòng)時(shí)均從初始狀態(tài)開始參與選舉，下面是簡(jiǎn)易流程圖。

ZooKeeper 的全新集群選主

　　以一個(gè)簡(jiǎn)單的例子來說明整個(gè)選舉的過程：假設(shè)有五臺(tái)服務(wù)器組成的 zookeeper 集群，它們 的 serverid 從 1-5，同時(shí)它們都是最新啟動(dòng)的，也就是沒有歷史數(shù)據(jù)，在存放數(shù)據(jù)量這一點(diǎn) 上，都是一樣的。假設(shè)這些服務(wù)器依序啟動(dòng)，來看看會(huì)發(fā)生什么

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

　　2、服務(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)

 　   3、服務(wù)器 3 啟動(dòng)，根據(jù)前面的理論分析，服務(wù)器 3 成為服務(wù)器 1,2,3 中的老大，而與上面不 同的是，此時(shí)有三臺(tái)服務(wù)器(超過半數(shù))選舉了它，所以它成為了這次選舉的 leader

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

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

ZooKeeper 的非全新集群選主

　　那么，初始化的時(shí)候，是按照上述的說明進(jìn)行選舉的，但是當(dāng) zookeeper 運(yùn)行了一段時(shí)間之 后，有機(jī)器 down 掉，重新選舉時(shí)，選舉過程就相對(duì)復(fù)雜了。

　　需要加入數(shù)據(jù) version、serverid 和邏輯時(shí)鐘。

　　數(shù)據(jù) version：數(shù)據(jù)新的 version 就大，數(shù)據(jù)每次更新都會(huì)更新 version

　　server id：就是我們配置的 myid 中的值，每個(gè)機(jī)器一個(gè)

　　邏輯時(shí)鐘：這個(gè)值從 0 開始遞增，每次選舉對(duì)應(yīng)一個(gè)值，也就是說：如果在同一次選舉中， 那么這個(gè)值應(yīng)該是一致的；邏輯時(shí)鐘值越大，說明這一次選舉 leader 的進(jìn)程更新，也就是 每次選舉擁有一個(gè) zxid，投票結(jié)果只取 zxid 最新的

　　選舉的標(biāo)準(zhǔn)就變成：

　　　　1、邏輯時(shí)鐘小的選舉結(jié)果被忽略，重新投票

　　　　2、統(tǒng)一邏輯時(shí)鐘后，數(shù)據(jù) version 大的勝出

　　　　3、數(shù)據(jù) version 相同的情況下，server id 大的勝出

 根據(jù)這個(gè)規(guī)則選出 leader。