一、ZooKeeper 的實現

1.1 ZooKeeper處理單點故障

我們知道可以通過ZooKeeper對分布式系統進行Master選舉，來解決分布式系統的單點故障，如圖所示。

那么我們繼續分析一下，ZooKeeper通過Master選舉來幫助分布式系統解決單點故障， 保證該系統中每時每刻只有一個Master為分布式系統提供服務。也就是說分布式的單點問題交給了ZooKeeper來處理，不知道大家此時有沒有發現一 個問題——"故障轉移到了ZooKeeper身上"。大家看一下圖就會發現，如果我們的ZooKeeper只用一臺機器來提供服務，若這臺機器掛了，那么 該分布式系統就直接變成雙Master模式了，那么我們在分布式系統中引入ZooKeeper也就失去了意義。那么這也就意味著，ZooKeeper在其實現的過程中要做一些可用性和恢復性的保證。這樣才能讓我們放心的以ZooKeeper為起點來構建我們的分布式系統，來達到節省成本和減少bug的目的。

1.2 ZooKeeper運行模式

ZooKeeper服務有兩種不同的運行模式。一種是"獨立模式"(standalone mode)，即只有一個ZooKeeper服務器。這種模式較為簡單，比較適合于測試環境，甚至可以在單元測試中采用，但是不能保證高可用性和恢復性。在生產環境中的ZooKeeper通常以"復制模式"(replicated mode)運行于一個計算機集群上，這個計算機集群被稱為一個"集合體"(ensemble)。

?

ZooKeeper通過復制來實現高可用性，只要集合體中半數以上的機器處于可用狀態，它就能夠提供服務。例如，在一個有5個節點的集合體中，每個Follower節點的數據都是Leader節點數據的副本，也就是說我們的每個節點的數據視圖都是一樣的，這樣就可以有五個節點提供ZooKeeper服務。并且集合體中任意2臺機器出現故障，都可以保證服務繼續，因為剩下的3臺機器超過了半數。

注意，6個節點的集合體也只能夠容忍2臺機器出現故障，因為如果3臺機器出現故障，剩下的3臺機器沒有超過集合體的半數。出于這個原因，一個集合體通常包含奇數臺機器。

從概念上來說，ZooKeeper它所做的就是確保對Znode樹的每一個修改都會被復制到集合體中超過半數的 機器上。如果少于半數的機器出現故障，則最少有一臺機器會保存最新的狀態，那么這臺機器就是我們的Leader。其余的副本最終也會更新到這個狀態。如果 Leader掛了，由于其他機器保存了Leader的副本，那就可以從中選出一臺機器作為新的Leader繼續提供服務。

1.3 ZooKeeper的讀寫機制

(1) 概述

ZooKeeper的核心思想是，提供一個非鎖機制的Wait Free的用于分布式系統同步的核心服務。提供簡單的文件創建、讀寫操作接口，其系統核心本身對文件讀寫并不提供加鎖互斥的服務，但是提供基于版本比對的更新操作，客戶端可以基于此自己實現加鎖邏輯。如下圖1.3所示。

?

(2) ZK集群服務

?Zookeeper是一個由多個Server組成的集群，該集群有一個Leader，多個Follower。客戶端可以連接任意ZooKeeper服務節點來讀寫數據，如下圖1.4所示。

?

ZK集群中每個Server，都保存一份數據副本。Zookeeper使用簡單的同步策略，通過以下兩條基本保證來實現數據的一致性：

① 全局串行化所有的寫操作

② 保證同一客戶端的指令被FIFO執行（以及消息通知的FIFO）

所有的讀請求由Zk Server 本地響應，所有的更新請求將轉發給Leader，由Leader實施。

(3) ZK組件

ZK組件，如圖1.5所示。ZK組件除了請求處理器（Request Processor）以外，組成ZK服務的每一個Server會復制這些組件的副本。?

?

ReplicatedDatabase是一個內存數據庫，它包含了整個Data Tree。為了恢復，更新會被記錄到磁盤，并且寫在被應用到內存數據庫之前，先被序列化到磁盤。

每一個ZK Server，可服務于多個Client。Client可以連接到一臺Server，來提交請求。讀請求，由每臺Server數據庫的本地副本來進行服務。改變服務器的狀態的寫請求，需要通過一致性協議來處理。

作為一致性協議的一部分，來自Client的所有寫請求，都要被轉發到一個單獨的Server，稱作Leader。ZK集群中其他Server 稱作Follower，負責接收Leader發來的提議消息，并且對消息轉發達成一致。消息層處理leader失效，同步Followers和Leader。

ZooKeeper使用自定義的原子性消息協議。由于消息傳送層是原子性的，ZooKeeper能夠保證本地副本不產生分歧。當leader收到一個寫請求，它會計算出當寫操作完成后系統將會是什么狀態，接著將之轉變為一個捕獲狀態的事務。

(4) ZK性能

ZooKeeper被應用程序廣泛使用，并有數以千計 的客戶端同時的訪問它，所以我們需要高吞吐量。我們為ZooKeeper 設計的工作負載的讀寫比例是 2：1以上。然而我們發現，ZooKeeper的高寫入吞吐量，也允許它被用于一些寫占主導的工作負載。ZooKeeper通過每臺Server上的本地 ZK的狀態副本，來提供高讀取吞吐量。因此，容錯性和讀吞吐量是以添加到該服務的服務器數量為尺度。寫吞吐量并不以添加到該服務的機器數量為尺度。

例如，在它的誕生地Yahoo公司，對于寫占主導的工作負載來說，ZooKeeper的基準吞吐量已經超過每秒10000個操作；對于常規的以讀為主導的工作負載來說，吞吐量更是高出了好幾倍。

二、ZooKeeper的保證

經過上面的分析，我們知道要保證ZooKeeper服務的高可用性就需要采用分布式模式，來冗余數據寫多份，寫多份帶來一致性問題，一致性問題又會帶來性能問題，那么就此陷入了無解的死循環。那么在這，就涉及到了我們分布式領域的著名的CAP理論，在這就簡單的給大家介紹一下，關于CAP的詳細內容大家可以網上查閱。

2.1 CAP理論

(1) 理論概述

分布式領域中存在CAP理論：

①?C：Consistency，一致性，數據一致更新，所有數據變動都是同步的。

②?A：Availability，可用性，系統具有好的響應性能。

③?P：Partition tolerance，分區容錯性。以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇，也就是說無論任何消息丟失，系統都可用。

該理論已被證明：任何分布式系統只可同時滿足兩點，無法三者兼顧。 因此，將精力浪費在思考如何設計能滿足三者的完美系統上是愚鈍的，應該根據應用場景進行適當取舍。

(2)?一致性分類

一致性是指從系統外部讀取系統內部的數據時，在一定約束條件下相同，即數據變動在系統內部各節點應該是同步的。根據一致性的強弱程度不同，可以將一致性級別分為如下幾種：

① 強一致性（strong consistency）。任何時刻，任何用戶都能讀取到最近一次成功更新的數據。

② 單調一致性（monotonic consistency）。任何時刻，任何用戶一旦讀到某個數據在某次更新后的值，那么就不會再讀到比這個值更舊的值。也就是說，可獲取的數據順序必是單調遞增的。

③ 會話一致性（session consistency）。任何用戶在某次會話中，一旦讀到某個數據在某次更新后的值，那么在本次會話中就不會再讀到比這個值更舊的值。會話一致性是在單調一致性的基礎上進一步放松約束，只保證單個用戶單個會話內的單調性，在不同用戶或同一用戶不同會話間則沒有保障。

④?最終一致性（eventual consistency）。用戶只能讀到某次更新后的值，但系統保證數據將最終達到完全一致的狀態，只是所需時間不能保障。

⑤ 弱一致性（weak consistency）。用戶無法在確定時間內讀到最新更新的值。

2.2 ZooKeeper與CAP理論

我們知道ZooKeeper也是一種分布式系統，它在一致性上有人認為它提供的是一種強一致性的服務（通過sync操作），也有人認為是單調一致性（更新時的大多說概念），還有人為是最終一致性（順序一致性），反正各有各的道理這里就不在爭辯了。然后它在分區容錯性和可用性上做了一定折中，這和CAP理論是吻合的。ZooKeeper從以下幾點保證了數據的一致性

① 順序一致性

來自任意特定客戶端的更新都會按其發送順序被提交。也就是說，如果一個客戶端將Znode z的值更新為a，在之后的操作中，它又將z的值更新為b，則沒有客戶端能夠在看到z的值是b之后再看到值a（如果沒有其他對z的更新）。

② 原子性

每個更新要么成功，要么失敗。這意味著如果一個更新失敗，則不會有客戶端會看到這個更新的結果。

③ 單一系統映像

一 個客戶端無論連接到哪一臺服務器，它看到的都是同樣的系統視圖。這意味著，如果一個客戶端在同一個會話中連接到一臺新的服務器，它所看到的系統狀態不會比 在之前服務器上所看到的更老。當一臺服務器出現故障，導致它的一個客戶端需要嘗試連接集合體中其他的服務器時，所有滯后于故障服務器的服務器都不會接受該 連接請求，除非這些服務器趕上故障服務器。

④ 持久性

一個更新一旦成功，其結果就會持久存在并且不會被撤銷。這表明更新不會受到服務器故障的影響。

?

三、ZooKeeper原理

3.1 原理概述

Zookeeper的核心是原子廣播機制，這個機制保證了各個server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式和廣播模式。

(1) 恢復模式

當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server完成了和leader的狀態同步以后，恢復模式就結束了。狀態同步保證了leader和server具有相同的系統狀態。

(2) 廣播模式

一旦Leader已經和多數的Follower進行了狀態同步后，他就可以開始廣播消息了，即進入廣播狀態。這時候當一個Server加入ZooKeeper服務中，它會在恢復模式下啟動，發現Leader，并和Leader進行狀態同步。待到同步結束，它也參與消息廣播。ZooKeeper服務一直維持在Broadcast狀態，直到Leader崩潰了或者Leader失去了大部分的Followers支持。

Broadcast模式極其類似于分布式事務中的2pc（two-phrase commit?兩階段提交）：即Leader提起一個決議，由Followers進行投票，Leader對投票結果進行計算決定是否通過該決議，如果通過執行該決議（事務），否則什么也不做。

在廣播模式ZooKeeper Server會接受Client請求，所有的寫請求都被轉發給領導者，再由領導者將更新廣播給跟隨者。當半數以上的跟隨者已經將修改持久化之后，領導者才會提交這個更新，然后客戶端才會收到一個更新成功的響應。這個用來達成共識的協議被設計成具有原子性，因此每個修改要么成功要么失敗。

?

3.2 Zab協議詳解

3.2.1 廣播模式

廣播模式類似一個簡單的兩階段提交：Leader發起一個請求，收集選票，并且最終提交，圖3.3演示了我們協議的消息流程。我們可以簡化該兩階段提交協議，因為我們并沒有"aborts"的情況。followers要么確認Leader的Propose，要么丟棄該Leader的Propose。沒有"aborts"意味著，只要有指定數量的機器確認了該Propose，而不是等待所有機器的回應。

?

廣播協議在所有的通訊過程中使用TCP的FIFO信道，通過使用該信道，使保持有序性變得非常的容易。通過FIFO信道，消息被有序的deliver。只要收到的消息一被處理，其順序就會被保存下來。

Leader會廣播已經被deliver的Proposal消息。在發出一個Proposal消息前，Leader會分配給Proposal一個單調遞增的唯一id，稱之為zxid。因為Zab保證了因果有序， 所以遞交的消息也會按照zxid進行排序。廣播是把Proposal封裝到消息當中，并添加到指向Follower的輸出隊列中，通過FIFO信道發送到 Follower。當Follower收到一個Proposal時，會將其寫入到磁盤，可以的話進行批量寫入。一旦被寫入到磁盤媒介當 中，Follower就會發送一個ACK給Leader。 當Leader收到了指定數量的ACK時，Leader將廣播commit消息并在本地deliver該消息。當收到Leader發來commit消息 時，Follower也會遞交該消息。

需要注意的是， 該簡化的兩階段提交自身并不能解決Leader故障，所以我們 添加恢復模式來解決Leader故障。

3.2.2 恢復模式

(1) 恢復階段概述

　　正常工作時Zab協議會一直處于廣播模式，直到Leader故障或失去了指定數量的Followers。 為了保證進度，恢復過程中必須選舉出一個新Leader，并且最終讓所有的Server擁有一個正確的狀態。對于Leader選舉，需要一個能夠成功高幾 率的保證存活的算法。Leader選舉協議，不僅能夠讓一個Leader得知它是leader，并且有指定數量的Follower同意該決定。如果 Leader選舉階段發生錯誤，那么Servers將不會取得進展。最終會發生超時，重新進行Leader選舉。在我們的實現中，Leader選舉有兩種不同的實現方式。如果有指定數量的Server正常運行，快速選舉的完成只需要幾百毫秒。

(2)恢復階段的保證

　　該恢復過程的復雜部分是在一個給定的時間內，提議沖突的絕對數量。最大數量沖突提議是一個可配置的選項，但是默認是1000。為了使該協議能夠即使在Leader故障的情況下也能正常運作。我們需要做出兩條具體的保證：

①?我們絕不能遺忘已經被deliver的消息，若一條消息在一臺機器上被deliver，那么該消息必須將在每臺機器上deliver。

②?我們必須丟棄已經被skip的消息。

(3) 保證示例

第一條：

若一條消息在一臺機器上被deliver，那么該消息必須將在每臺機器上deliver，即使那臺機器故障了。例如，出現了這樣一種情況：Leader發送了commit消息，但在該commit消息到達其他任何機器之前，Leader發生了故障。也就是說，只有Leader自己收到了commit消息。如圖3.4中的C2。

?

圖3.4是"第一條保證"（deliver消息不能忘記）的一個示例。在該圖中Server1是一個Leader，我們用L1表示，Server2和Server3為Follower。首先Leader發起了兩個Proposal，P1和P2，并將P1、P2發送給了Server1和Server2。然后Leader對P1發起了Commit即C1，之后又發起了一個Proposal即P3，再后來又對P2發起了commit即C2，就在此時我們的Leader掛了。那么這時候，P3和C2這兩個消息只有Leader自己收到了。

因為Leader已經deliver了該C2消息，client能夠在消息中看到該事務的結果。所以該事務必須能夠在其他所有的Server中deliver，最終使得client看到了一個一致性的服務視圖。

第二條：

一個被skip的消息，必須仍然需要被skip。例如，發生了這樣一種情況：Leader發送了propose消息，但在該propose消息到達其他任何機器之前，Leader發生了故障。也就是說，只有Leader自己收到了propose消息。如圖3.4中的P3所示。

在圖3.4中沒有任何一個server能夠看到3號提議，所以在圖3.5中當server 1恢復時他需要在系統恢復時丟棄三號提議P3。

?

在圖3.5是"第二條保證"（skip消息必須被丟棄）的一個示例。Server1掛掉以后，Server3被選舉為Leader，我們用L2表示。L2中還有未被deliver的消息P1、P2，所以，L2在發出新提議P10000001、P10000002之前，L2先將P1、P2兩個消息deliver。因此，L2先發出了兩個commit消息C1、C2，之后L2才發出了新的提議P10000001和P10000002。

如果Server1 恢復之后再次成為了Leader，此時再次將P3在P10000001和P10000002之后deliver，那么將違背順序性的保障。

(4) 保證的實現

　　如果Leader選舉協議保證了新Leader在Quorum Server中具有最高的提議編號，即Zxid最高。那么新選舉出來的leader將具有所有已deliver的消息。新選舉出來的Leader，在提出一個新消息之前，首先要保證事務日志中的所有消息都由Quorum Follower已Propose并deliver。需要注意的是，我們可以讓新Leader成為一個用最高zxid來處理事務的server，來作為一個優化。這樣，作為新被選舉出來的Leader，就不必去從一組Followers中找出包含最高zxid的Followers和獲取丟失的事務。

① 第一條

所有的正確啟動的Servers，將會成為Leader或者跟隨一個Leader。Leader能夠確保它的Followers看到所有的提議，并deliver所有已經deliver的消息。通過將新連接上的Follower所沒有見過的所有PROPOSAL進行排隊，并之后對該Proposals的COMMIT消息進行排隊，直到最后一個COMMIT消息。在所有這樣的消息已經排好隊之后，Leader將會把Follower加入到廣播列表，以便今后的提議和確認。這一條是為了保證一致性，因為如果一條消息P已經在舊Leader-Server1中deliver了，即使它剛剛將消息P?deliver之后就掛了，但是當舊Leader-Server1重啟恢復之后，我們的Client就可以從該Server中看到該消息P?deliver的事務，所以為了保證每一個client都能看到一個一致性的視圖，我們需要將該消息在每個Server上deliver。

② 第二條

skip已經Propose，但不能deliver的消息，處理起來也比較簡單。在我們的實現中，Zxid是由64位數字組成的，低32位用作簡單計數器。高32位是一個epoch。每當新Leader接管它時，將獲取日志中Zxid最大的epoch，新Leader?Zxid的epoch位設置為epoch+1，counter位設置0。用epoch來標記領導關系的改變,并要求Quorum Servers?通過epoch來識別該leader，避免了多個Leader用同一個Zxid發布不同的提議。

這 個方案的一個優點就是，我們可以skip一個失敗的領導者的實例，從而加速并簡化了恢復過程。如果一臺宕機的Server重啟，并帶有未發布的 Proposal，那么先前的未發布的所有提議將永不會被deliver。并且它不能夠成為一個新leader，因為任何一種可能的 Quorum Servers ，都會有一個Server其Proposal 來自與一個新epoch因此它具有一個較高的zxid。當Server以Follower的身份連接，領導者檢查自身最后提交的提議，該提議的epoch 為Follower的最新提議的epoch（也就是圖3.5中新Leader-Server2中deliver的C2提議），并告訴Follower截斷 事務日志直到該epoch在新Leader中deliver的最后的Proposal即C2。在圖3.5中，當舊Leader-Server1連接到了新leader-Server2，leader將告訴他從事務日志中清除3號提議P3，具體點就是清除P2之后的所有提議，因為P2之后的所有提議只有舊Leader-Server1知道，其他Server不知道。

(5) Paxos與Zab

① Paxos一致性

Paxos的一致性不能達到ZooKeeper的要求，我們可以下面一個例子。我們假設ZK集群由三臺機器組成，Server1、Server2、Server3。Server1為Leader，他生成了 三條Proposal，P1、P2、P3。但是在發送完P1之后，Server1就掛了。如下圖3.6所示。

?

Server1掛掉之后，Server3被選舉成為Leader，因為在Server3里只有一條Proposal—P1。所以，Server3在P1的基礎之上又發出了一條新Proposal—P2＇，P2＇的Zxid為02。如下圖3.7所示。

Server2發送完P2＇之后，它也掛了。此時Server1已經重啟恢復，并再次成為了Leader。那么，Server1將發送還沒有被deliver的Proposal—P2和P3。由于Follower-Server2中P2＇的Zxid為02和Leader-Server1中P2的Zxid相等，所以P2會被拒絕。而P3，將會被Server2接受。如圖3.8所示。

?

我們分析一下Follower-Server2中的Proposal，由于P2'將P2的內容覆蓋了。所以導致，Server2中的Proposal-P3無法生效，因為他的父節點并不存在。

② Zab一致性

首先來分析一下，上面的示例中為什么不滿足ZooKeeper需求。ZooKeeper是一個樹形結構，很多操作都要先檢查才能確定能不能執行，比如，在圖3.8中Server2有三條Proposal。P1的事務是創建節點"/zk"，P2'是創建節點"/c"，而P3是創建節點"/a/b",由于"/a"還沒建，創建"a/b"就搞不定了。那么，我們就能從此看出Paxos的一致性達不到ZooKeeper一致性的要求。

為了達到ZooKeeper所需要的一致性，ZooKeeper采用了Zab協議。Zab做了如下幾條保證，來達到ZooKeeper要求的一致性。

(a) Zab要保證同一個leader的發起的事務要按順序被apply，同時還要保證只有先前的leader的所有事務都被apply之后，新選的leader才能在發起事務。

(b) 一些已經Skip的消息，需要仍然被Skip。

我想對于第一條保證大家都能理解，它主要是為了保證每 個Server的數據視圖的一致性。我重點解釋一下第二條，它是如何實現。為了能夠實現，Skip已經被skip的消息。我們在Zxid中引入了 epoch，如下圖所示。每當Leader發生變換時，epoch位就加1，counter位置0。

?

我們繼續使用上面的例子，看一下他是如何實現Zab的 第二條保證的。我們假設ZK集群由三臺機器組成，Server1、Server2、Server3。Server1為Leader，他生成了三條 Proposal，P1、P2、P3。但是在發送完P1之后，Server1就掛了。如下圖3.10所示。

?

Server1掛掉之后，Server3被選舉成為 Leader，因為在Server3里只有一條Proposal—P1。所以，Server3在P1的基礎之上又發出了一條新Proposal—P2＇， 由于Leader發生了變換，epoch要加1，所以epoch由原來的0變成了1，而counter要置0。那么，P2＇的Zxid為10。如下圖3.11所示。

?

?

?Server2發送完P2＇之后，它也掛了。此時Server1已經重啟恢復，并再次成為了Leader。那么，Server1將發送還沒有被deliver的Proposal—P2和P3。由于Server2中P2＇的Zxid為10，而Leader-Server1中P2和P3的Zxid分別為02和03，P2＇的epoch位高于P2和P3。所以此時Leader-Server1的P2和P3都會被拒絕,那么我們Zab的第二條保證也就實現了。如圖3.12所示。

?

轉載于:https://www.cnblogs.com/skying555/p/9729564.html

總結

以上是生活随笔為你收集整理的ZooKeeper学习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。