Java Web系列文章彙總貼: Java Web知識總結匯總

分佈式系統的經典理論

CAP

C (Consistency 一致性)：對某個指定的客戶端來說，讀操作能返回最新的寫操作。
對於數據分佈在不同節點上的數據來說，如果在某個節點更新了數據，那麼在其他節點如果都能讀取到這個最新的數據，那麼就稱爲強一致，如果有某個節點沒有讀取到，那就是分佈式不一致。
A (Availability 可用性)：非故障的節點在合理的時間內返回合理的響應(不是錯誤和超時的響應)。可用性的兩個關鍵一個是合理的時間，一個是合理的響應。
合理的時間指的是請求不能無限被阻塞，應該在合理的時間給出返回。合理的響應指的是系統應該明確返回結果並且結果是正確的，這裏的正確指的是比如應該返回 50，而不是返回 40。
P (Partition Tolerance 分區容錯性)：當出現網絡分區後，系統能夠繼續工作。打個比方，這裏集羣有多臺機器，有臺機器網絡出現了問題，但是這個集羣仍然可以正常工作。

熟悉 CAP 的人都知道，三者不能共有，如果感興趣可以搜索 CAP 的證明，在分佈式系統中，網絡無法 100% 可靠，分區其實是一個必然現象。

BASE

BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫，是對 CAP 中 AP 的一個擴展。

基本可用：分佈式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。
軟狀態：允許系統中存在中間狀態，這個狀態不影響系統可用性，這裏指的是 CAP 中的不一致。
最終一致：最終一致是指經過一段時間後，所有節點數據都將會達到一致。

BASE 解決了 CAP 中理論沒有網絡延遲，在 BASE 中用軟狀態和最終一致，保證了延遲後的一致性。
BASE 和 ACID 是相反的，它完全不同於 ACID 的強一致性模型，而是通過犧牲強一致性來獲得可用性，並允許數據在一段時間內是不一致的，但最終達到一致狀態。

參考：
Zookeeper系列（1）–分佈式一致性理論，CAP，BASE理論

ZK簡介

ZooKeeper是一個開放源代碼的、高效、可靠的分佈式協調服務。設計目標是：將那些複雜且容易出錯的分佈式一致性服務封裝起來，構成一個高效可靠的原語集，並以一系列簡單易用的接口提供給用戶使用。

ZooKeeper的設計目標：

簡單的數據模型
可以構建集羣
順序訪問
高性能

ZK原理

拜占庭將軍問題（Byzantine Generals Problem）

Leslie Lamport在1982年提出的虛擬模型，用來解釋一致性問題。拜占庭作爲東羅馬帝國的首都，地域遼闊，在首都周邊有衆多將軍負責城防，將軍之間通過信使來傳遞消息，達成某些一致的決定。但由於將軍中存在叛徒，叛徒會想盡一切辦法干擾一致性的達成，甚至是達成叛徒想要的共識從而實現攻擊。
拜占庭問題，假設節點總數是N，叛徒將軍數爲F，則當 N 》= 3F+1 時，問題纔有解，共識才能達成，這就是Byzantine Fault Tolerant（BFT）算法。
基於以上分佈式理論，對一個分佈式系統進行架構設計的過程中，往往會在系統的可用性和數據一致性之間反覆權衡，於是產生了一系列的一致性協議，如2PC&3PC中涉及的一致性協議，Paxos一致性理論。

ZoopKeeper採用的一致性協議–ZAB(ZooKeeper Atomic Broadcast，原子消息廣播協議)協議

ZAB協議

ZAB協議的核心定義了對於那些改變ZooKeeper服務器數據狀態的事務請求的處理方式，即：
所有事務請求必須有一個全局唯一的服務器來協調處理，這樣的服務器被稱爲Leader服務器，而餘下的其他服務器則成爲Follower服務器。Leader服務器負責將一個客戶端事務請求轉換成一個事務Proposal(提議)，並將該Proposal分發給集羣中所有的Follower服務器。之後Leader服務器需要等待所有Follower服務器的反饋，一旦超過半數的Follower服務器進行了正確的反饋後，那麼Leader就會再次向所有的Follower服務器分發Commit消息，要求其將前一個Proposal進行提交。
另，ZooKeeper中還有一種機器角色：Observer。Observer機器不參與Leader選舉過程，也不參與寫操作的“過半寫成功”策略，因此Observer可以在不影響寫性能的情況下提升集羣的讀性能。
Zookeeper 的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式（選主-Leader選舉）和廣播模式（數據同步）。

Leader選舉過程（FastLeaderElection算法）

Leader選舉是保證分佈式數據一致性的關鍵所在。當Zookeeper集羣中的一臺服務器出現以下兩種情況之一時，需要進入Leader選舉。

服務器啓動時期的Leader選舉

若進行Leader選舉，則至少需要兩臺機器，這裏選取3臺機器組成的服務器集羣爲例。在集羣初始化階段，當有一臺服務器Server1啓動時，其單獨無法進行和完成Leader選舉，當第二臺服務器Server2啓動時，此時兩臺機器可以相互通信，每臺機器都試圖找到Leader，於是進入Leader選舉過程。選舉過程如下

(1) 每個Server發出一個投票。由於是初始情況，Server1和Server2都會將自己作爲Leader服務器來進行投票，每次投票會包含所推舉的服務器的myid和ZXID，使用(myid, ZXID)來表示，此時Server1的投票爲(1, 0)，Server2的投票爲(2, 0)，然後各自將這個投票發給集羣中其他機器。
(2) 接受來自各個服務器的投票。集羣的每個服務器收到投票後，首先判斷該投票的有效性，如檢查是否是本輪投票、是否來自LOOKING狀態的服務器。
(3) 處理投票。針對每一個投票，服務器都需要將別人的投票和自己的投票進行PK，PK規則如下
A）優先檢查ZXID。ZXID比較大的服務器優先作爲Leader。
B）如果ZXID相同，那麼就比較myid。myid較大的服務器作爲Leader服務器。
對於Server1而言，它的投票是(1, 0)，接收Server2的投票爲(2, 0)，首先會比較兩者的ZXID，均爲0，再比較myid，此時Server2的myid最大，於是更新自己的投票爲(2, 0)，然後重新投票，對於Server2而言，其無須更新自己的投票，只是再次向集羣中所有機器發出上一次投票信息即可。
(4) 統計投票。每次投票後，服務器都會統計投票信息，判斷是否已經有過半機器接受到相同的投票信息，對於Server1、Server2而言，都統計出集羣中已經有兩臺機器接受了(2, 0)的投票信息，此時便認爲已經選出了Leader。
(5) 改變服務器狀態。一旦確定了Leader，每個服務器就會更新自己的狀態，如果是Follower，那麼就變更爲FOLLOWING，如果是Leader，就變更爲LEADING。

服務器運行時期的Leader選舉

在Zookeeper運行期間，Leader與非Leader服務器各司其職，即便當有非Leader服務器宕機或新加入，此時也不會影響Leader，但是一旦Leader服務器掛了，那麼整個集羣將暫停對外服務，進入新一輪Leader選舉，其過程和啓動時期的Leader選舉過程基本一致。假設正在運行的有Server1、Server2、Server3三臺服務器，當前Leader是Server2，若某一時刻Leader掛了，此時便開始Leader選舉。選舉過程如下

(1)變更狀態。Leader掛後，餘下的非Observer服務器都會講自己的服務器狀態變更爲LOOKING，然後開始進入Leader選舉過程。
(2)每個Server會發出一個投票。在運行期間，每個服務器上的ZXID可能不同，此時假定Server1的ZXID爲123，Server3的ZXID爲122；在第一輪投票中，Server1和Server3都會投自己，產生投票(1, 123)，(3, 122)，然後各自將投票發送給集羣中所有機器。
(3)接收來自各個服務器的投票。與啓動時過程相同。
(4)處理投票。與啓動時過程相同，此時，Server1將會成爲Leader。
(5)統計投票。與啓動時過程相同。
(6)改變服務器的狀態。與啓動時過程相同。

上邊選出的只是準leader，要想變成leader還需完成數據同步。
更加詳細的解釋可參考《從Paxos到Zookeeper分佈式一致性原理與實踐》這本書。

數據同步

同步階段主要是利用 leader 前一階段獲得的最新提議歷史，同步集羣中所有的副本。只有當集羣過半機器都同步完成，準 leader 纔會成爲真正的 leader。follower 只會接收 zxid 比自己的 last Zxid 大的提議。
當完成Leader選舉後，進行故障恢復的第二步就是數據同步： Leader服務器會爲每一個Follower服務器準備一個隊列，並將那些沒有被各個Follower服務器同步的事務以Proposal的形式逐條發給各個Follower服務器，並在每一個Proposal後都緊跟一個commit消息，表示該事務已經被提交，檔follower服務器將所有尚未同步的事務proposal都從leader服務器同步過來併成功應用到本地後，leader服務器就會將該follower加入到真正可用的follower列表中。（新選舉週期，epoch已經更新了）
每個zookeeper 事務都有一個全局唯一的事務ID，ZXID。ZXID 高32 位是leader 週期epoch，低32 位是遞增計數器。從算法角度上看：

第一階段（準leader生成初始事務集合）

所有follower 向準leader 發送自己最後接收的事務的epoch；
準leader 選取最大的epoch，加1得到e1，將e1 發送給follower；（準leader已經是zxid最大的機器了，且已經完成epoch更新了，防止說個leader出現）
follower 收到準leader 發送的epoch 值之後，與自己的epoch 值作比較，若小於，則將自己的epoch 更新爲e1，並向準leader 發送反饋ACK信息（epoch 信息、歷史事務集合）；
準leader 接收到ACK 消息之後，會在所有歷史事務集合中選擇其中一個歷史事務集合作爲初始化事務集合，該事務集合滿足ZXID最大；

第二階段（正式同步）

準leader 將epoch 與初始化事務集合發送給集羣中過半的follower；每個follower 會分配到一個隊列，leader 會將那些沒有被各個follower 同步的事務以proposal 形式發送給各個follower，並在後面追加commit 消息，表示事務已被提交；follower 接收後，會執行初始化事務集合中的事務（執行過跳過，未執行執行），反饋給leader 表明自己已經處理（追上來了）leader 收到後過半反饋後，發送commit 消息；follower 接收到commit 消息後，提交事務；注意：在zk選舉中，通過投票已經確認leader服務器是最大的zxid的節點了，所以同步過程沒有那麼複雜。

ZAB協議與Paxos算法的異同

ZAB協議並不是 Paxos 算法的一個典型實現，在講解 ZAB和 Paxos之間的區別之前, 我們首先看下兩者的聯繫，

兩者都有一個類似於Leader進程的角色，由其負責協調多個Follower運行
Leader進程都會等待超過半數的Follower做出正確的反饋後，纔會將一個提案進行提交。
在ZAB協議中，每個Proposal都包含了一個epoch值，用來代表當前的Leader 週期，在Paxos算法中，同樣存在這樣的一個標識，只是名字變成了Ballot。
在Paxos算法中，一個新選舉產生的主進程會進行兩個階段的工作，第一階段被稱爲讀階段，在這個階段中，這個新的主進程會通過和所有其他進程進行通信的方式來收集上一個—個主進程提出的提案，並將它們提交.第二階段被稱爲寫階段，在這個階段，與前主進程開始提出自己的提案。
在Paxos算法設計的基礎上， ZAB協議額外添加了一個同步階段。在同步階段之前，ZAB協議也存在一個和Paxos算法中的讀階段I類似的過程，被稱爲發現（ Discovery)階段，在同步階段中，新的 Leader會確存在過半數的Follower已經提交了之前Leader週期中的所有事物的Proposal，在這一同步階段的引人，能夠有效地保證Leader在新的週期中提出事務Proposal之前，所有的進程都已經完成了對之前所有事物的Proposal的提交。
一旦完成同步階段後，那麼 ZAB就會執行和 Paxos算法類似的寫階段。

總的來汫， ZAB協議和 Paxos本質區別在於，兩者的設計目標不太一樣。 ZAB 協議主要用於構建一個高可用的分佈式數椐主備系統，例如ZooKeeper, 而Paxos算法則是用於構建一個分佈式的一致性狀態機系統，

參考：
Zookeeper系列（5）–ZAB協議，消息廣播，崩潰恢復，數據同步

ZK中的核心概念

1、集羣角色：Leader、Follower、Observer

2、會話(session)：指客戶端會話，客戶端與服務器之間的一個TCP長連接，通過這個連接進行心跳檢測和Watch事件通知
TCP長連接與短連接(參考【TCP長連接和短連接的區別】)：

TCP短連接：數據發送完成後就關閉連接，下次發送數據時重新建立連接，適用於連接頻率很低的情況（比如網頁訪問）
TCP長連接：數據發送完後，並不關閉連接，通過相互發送校驗包保持連接，再次發送數據時不用再重新建立連接，適用於連接頻率很高的情況

3、數據節點(Znode)：數據節點，持久節點(持久順序節點)和臨時節點(臨時順序節點)(實現分佈式鎖等的重要特性)兩類

4、版本：Znode版本、子節點版本、ACL版本(保證原子性)

Zookeeper會爲每個Znode維護一個叫作Stat的數據結構，結構如圖：存在三個版本信息：

version：znode數據的修改次數
cversion：znode子節點修改次數
aversion：znode的ACL修改次數

version是表示對數據節點數據內容的變更次數，強調的是變更次數，因此就算數據內容的值沒有發生變化，version的值也會遞增。採用CAS操作保證原子性。

5、Watcher：用戶在指定節點上註冊一些Watcher，事件觸發時，會通知到訂閱的客戶端

6、ACL(Access Control Lists)：權限控制，保證數據的安全

ZK的高可用：內存模型 + 數據快照 + ZXID事務日誌存儲

ZK內存模型

Zookeeper的數據模型是樹結構，在內存數據庫中，存儲了整棵樹的內容，包括所有的節點路徑、節點數據、ACL信息，Zookeeper會定時將這個數據存儲到磁盤上。

DataTree
DataTree是內存數據存儲的核心，是一個樹結構，代表了內存中一份完整的數據。DataTree不包含任何與網絡、客戶端連接及請求處理相關的業務邏輯，是一個獨立的組件。
DataNode
DataNode是數據存儲的最小單元，其內部除了保存了結點的數據內容、ACL列表、節點狀態之外，還記錄了父節點的引用和子節點列表兩個屬性，其也提供了對子節點列表進行操作的接口。
ZKDatabase
Zookeeper的內存數據庫，管理Zookeeper的所有會話、DataTree存儲和事務日誌。ZKDatabase會定時向磁盤dump快照數據，同時在Zookeeper啓動時，會通過磁盤的事務日誌和快照文件恢復成一個完整的內存數據庫。

DataTree是整個樹的核心，不與任何網絡、客戶端以及請求事務有關。DataTree利用CurrentHashMap<String,DataNode>的屬性nodes來存儲着整個樹的所有節點以及對應的路徑，對於臨時節點單獨放在一個CurrentHashMap中。DataNode是最小的存儲單元，保存着節點的數據，ACL，父節點和子節點列表。
對於目標節點的查找並不是使用樹的結構層層查找，而是在DataTree中的屬性nodes–CurrentHashMap<String,DataNode>根據路徑作爲key直接查找DataNode，提高了查找效率。

ZK數據與存儲

我們知道Zookeeper是將全量數據存儲在內存中，但他是怎樣進行容錯的呢？當節點崩潰後或重新初始化時，是怎麼會發到宕機之前的數據呢？這就需要Zookeeper的數據存儲實現。感覺大多數內存存儲的組件容錯機制都差不多，都是利用快照和事務日誌來保證節點宕機恢復工作。比如：zookeeper，HDFS的namenode，redis，都是採用快照+事務日誌來進行數據持久化,來實現底層數據的一致性。

事務日誌

在配置Zookeeper集羣時需要配置dataDir目錄，其用來存儲事務日誌文件。也可以爲事務日誌單獨分配一個文件存儲目錄:dataLogDir。若配置dataLogDir爲/home/admin/zkData/zk_log，那麼Zookeeper在運行過程中會在該目錄下建立一個名字爲version-2的子目錄，該目錄確定了當前Zookeeper使用的事務日誌格式版本號，當下次某個Zookeeper版本對事務日誌格式進行變更時，此目錄也會變更，即在version-2子目錄下會生成一系列文件大小一致(64MB)的文件。

事務日誌記錄了對Zookeeper的操作，命名爲log.ZXID,後綴是一個事務ID。並且是寫入該事務日誌文件第一條事務記錄的ZXID，使用ZXID作爲文件後綴，可以幫助我們迅速定位到某一個事務操作所在的事務日誌。同時，使用ZXID作爲事務日誌後綴的另一個優勢是：ZXID本身由兩部分組成，高32位代表當前leader週期（epoch）,低32位則是真正的操作序列號，因此，將ZXID作爲文件後綴，我們就可以清楚地看出當前運行時的zookeeper的leader週期。

事務日誌的寫入是採用了磁盤預分配的策略。因爲事務日誌的寫入性能直接決定看Zookeeper服務器對事務請求的響應，也就是說事務寫入可被看做是一個磁盤IO過程，所以爲了提高性能，避免磁盤尋址seek所帶來的性能下降，所以zk在創建事務日誌的時候就會進行文件空間“預分配”，即：在文件創建之初就想操作系統預分配一個很大的磁盤塊，默認是64M，而一旦已分配的文件空間不足4KB時，那麼將會再次進行預分配，再申請64M空間。

數據快照

數據快照是Zookeeper數據存儲中非常核心的運行機制，數據快照用來記錄Zookeeper服務器上某一時刻的全量內存數據內容，並將其寫入指定的磁盤文件中。也是使用ZXID來作爲文件後綴名，並沒有採用磁盤預分配的策略，因此數據快照文件在一定程度上反映了當前zookeeper的全量數據大小。

與事務文件類似，Zookeeper快照文件也可以指定特定磁盤目錄，通過dataDir屬性來配置。若指定dataDir爲/home/admin/zkData/zk_data，則在運行過程中會在該目錄下創建version-2的目錄，該目錄確定了當前Zookeeper使用的快照數據格式版本號。在Zookeeper運行時，會生成一系列文件。

針對客戶端的每一次事務操作，Zookeeper都會將他們記錄到事務日誌中，同時也會將數據變更應用到內存數據庫中，Zookeeper在進行若干次（snapCount）事務日誌記錄後，將內存數據庫的全量數據Dump到本地文件中，這就是數據快照。

過半隨機策略

每進行一次事務記錄後，Zookeeper都會檢測當前是否需要進行數據快照。理論上進行snapCount次事務操作就會開始數據快照，但是考慮到數據快照對於Zookeeper所在機器的整體性能的影響，需要避免Zookeeper集羣中所有機器在同一時刻進行數據快照。因此zk採用“過半隨機”的策略，來判斷是否需要進行數據快照。即：符合如下條件就可進行數據快照：
logCount > (snapCount / 2 + randRoll) randRoll位1~snapCount / 2之間的隨機數。這種策略避免了zk集羣的所有機器在同一時刻都進行數據快照，影響整體性能。

進行快照

開始快照時，首先關閉當前日誌文件（已經到了該快照的數了），重新創建一個新的日誌文件，創建單獨的異步線程來進行數據快照以避免影響Zookeeper主流程，從內存中獲取zookeeper的全量數據和校驗信息，並序列化寫入到本地磁盤文件中，以本次寫入的第一個事務ZXID作爲後綴。

數據恢復

在Zookeeper服務器啓動期間，首先會進行數據初始化工作，用於將存儲在磁盤上的數據文件加載到Zookeeper服務器內存中。
數據恢復時，會加載最近100個快照文件（如果沒有100個，就加載全部的快照文件）。之所以要加載100個，是因爲防止最近的那個快照文件不能通過校驗。在逐個解析過程中，如果正確性校驗通過之後，那麼通常就只會解析最新的那個快照文件，但是如果校驗和發現最先的那個快照文件不可用，那麼就會逐個進行解析，直到將這100個文件全部解析完。如果將所有的快照文件都解析後還是無法恢復出一個完整的“DataTree”和“sessionWithTimeouts”，則認爲無法從磁盤中加載數據，服務器啓動失敗。當基於快照文件構建了一個完整的DataTree實例和sessionWithTimeouts集合了，此時根據這個快照文件的文件名就可以解析出最新的ZXID，該ZXID代表了zookeeper開始進行數據快照的時刻，然後利用此ZXID定位到具體事務文件從哪一個開始，然後執行事務日誌對應的事務，恢復到最新的狀態，並得到最新的ZXID。

參考：
Zookeeper系列（4）–ZK概述，數據模型，節點特性，Watcher機制、ACL及數據存儲
 zookeeper的zab協議工作原理之崩潰恢復模式

ZK開源客戶端

ZkClient
Curator

Curator解決了很多ZooKeeper客戶端非常底層的細節開發工作，包括連接重連、反覆註冊Watcher和NodeExistsException等，通過ZooKeeper原生API，提供了一套易用性和可讀性更強的Fluent風格的客戶端API框架。除此之外，Curator還提供了還提供了ZooKeeper各種應用場景(Recipe，如共享鎖服務、Master選舉機制和分佈式計數器等)的抽象封裝。

ZK的典型應用場景

Zookeeper的兩大特性（節點特性和watcher機制）：

客戶端如果對Zookeeper的數據節點註冊Watcher監聽，那麼當該數據及誒單內容或是其子節點列表發生變更時，Zookeeper服務器就會向訂閱的客戶端發送變更通知。
對在Zookeeper上創建的臨時節點，一旦客戶端與服務器之間的會話失效，那麼臨時節點也會被自動刪除。
ZooKeeper是一個典型的發佈/訂閱模式的高可用的分佈式數據管理與協調框架，開發人員可以使用它來進行分佈式數據的發佈與訂閱。另一方面，通過對ZooKeeper中豐富的數據節點類型進行交叉使用，配合Watcher通知機制，利用這兩大特性，可以非常方便地構建一系列分佈式應用中都會涉及的核心功能，如
數據發佈/訂閱
負載均衡
命名服務
分佈式協調/通知
集羣管理
Master選舉
分佈式鎖
分佈式隊列

幾種應用場景的實現

負載均衡

基本原理是，每個應用的Server啓動時創建一個EPHEMERAL(臨時)節點，應用客戶端通過讀取節點列表獲得可用服務器列表，並訂閱節點事件，有Server宕機斷開時觸發事件，客戶端監測到後把該Server從可用列表中刪除

命名服務

基本原理：通過調用Zookeeper節點創建的API接口就可以創建一個順序節點，並且在API返回值中會返回這個節點的完整名字，利用此特性，可以生成全局ID，其步驟如下

1.客戶端根據任務類型，在指定類型的任務下通過調用接口創建一個順序節點，如"job-"。
2.創建完成後，會返回一個完整的節點名，如"job-00000001"。
3.客戶端拼接type類型和返回值後，就可以作爲全局唯一ID了，如"type2-job-00000001"。

Master選舉

基本原理，利用Zookeeper的一致性，能夠很好地保證在分佈式高併發情況下節點的創建一定能夠保證全局唯一性，即Zookeeper將會保證客戶端無法重複創建一個已經存在的數據節點（由其分佈式數據的一致性保證）。
首先創建/master_election/2016-11-12節點，客戶端集羣每天會定時往該節點下創建臨時節點，如/master_election/2016-11-12/binding，這個過程中，只有一個客戶端能夠成功創建，此時其變成master，其他節點都會在節點/master_election/2016-11-12上註冊一個子節點變更的Watcher，用於監控當前的Master機器是否存活，一旦發現當前Master掛了，其餘客戶端將會重新進行Master選舉

分佈式鎖

實現方案：

1、客戶端調用create接口常見類似於/shared_lock/[Hostname]-請求類型-序號的臨時順序節點。
2、客戶端調用getChildren接口獲取所有已經創建的子節點列表（不註冊任何Watcher）。
3、如果無法獲取共享鎖，就調用exist接口來對比自己小的節點註冊Watcher。對於讀請求：向比自己序號小的最後一個寫請求節點註冊Watcher監聽。對於寫請求：向比自己序號小的最後一個節點註冊Watcher監聽。
4、等待Watcher通知，繼續進入步驟2。
此方案改動主要在於：每個鎖競爭者，只需要關注/shared_lock節點下序號比自己小的那個節點是否存在即可。

分佈式隊列

① FIFO先入先出，先進入隊列的請求操作先完成後，纔會開始處理後面的請求。FIFO隊列就類似於全寫的共享模型，所有客戶端都會到/queue_fifo這個節點下創建一個臨時節點，如/queue_fifo/host1-00000001。

創建完節點後，按照如下步驟執行。

1、通過調用getChildren接口來獲取/queue_fifo節點的所有子節點，即獲取隊列中所有的元素。
2、確定自己的節點序號在所有子節點中的順序。
3、如果自己的序號不是最小，那麼需要等待，同時向比自己序號小的最後一個節點註冊Watcher監聽。
4、接收到Watcher通知後，重複步驟1。

② Barrier分佈式屏障，最終的合併計算需要基於很多並行計算的子結果來進行，開始時，/queue_barrier節點已經默認存在，並且將結點數據內容賦值爲數字n來代表Barrier值，之後，所有客戶端都會到/queue_barrier節點下創建一個臨時節點，例如/queue_barrier/host1。
創建完節點後，按照如下步驟執行。

1、通過調用getData接口獲取/queue_barrier節點的數據內容，如10。
2、通過調用getChildren接口獲取/queue_barrier節點下的所有子節點，同時註冊對子節點變更的Watcher監聽。
3、統計子節點的個數。
4、如果子節點個數還不足10個，那麼需要等待。
5、接受到Wacher通知後，重複步驟3

ZK與Eureka

ZooKeeper基於CP構建
Eureka基於AP構建

參考：
ZooKeeper是按照CP原則構建的,不適合做Service服務發現
 Eureka與ZooKeeper 的比較

ZK知識點總結

Zookeeper學習中的疑難問題總結，很受用
 Zookeeper系列二：分佈式架構詳解、分佈式技術詳解、分佈式事務

Java Web分佈式篇之ZooKeeper