一、簡介

Zookeeper 是一個開源的分布式的，為分布式框架提供協(xié)調(diào)服務(wù)的 Apache 項目。

從設(shè)計模式角度來理解：Zookeeper 是一個基于觀察者模式設(shè)計的分布式服務(wù)管理框架，它負責(zé)存儲和管理大家都關(guān)心的數(shù)據(jù)，然后接受觀察者的注冊，一旦這些數(shù)據(jù)的狀態(tài)發(fā)生變化，Zookeeper 就將負責(zé)通知已經(jīng)注冊的那些觀察者做出相應(yīng)的反應(yīng)。即：Zookeeper = 文件系統(tǒng) + 通知機制

1.1 Zookeeper 主要特點

1. Zookeeper 是由一個領(lǐng)導(dǎo)者（Leader），多個跟隨者（Follower）組成的集群
2. 集群中只要有半數(shù)以上節(jié)點存活，Zookeeper 集群就能正常服務(wù)。所以Zookeeper適合安裝奇數(shù)臺服務(wù)器
3. 全局數(shù)據(jù)一致：每個 Server 保存一份相同的數(shù)據(jù)副本，Client 無論連接到哪個Server，數(shù)據(jù)都是一致的
4. 更新請求順序執(zhí)行：來自同一個 Client 的更新請求按其發(fā)送順序依次執(zhí)行
5. 數(shù)據(jù)更新原子性：一次數(shù)據(jù)更新要么成功，要么失敗
6. 實時性：在一定時間范圍內(nèi)，Client 能讀到最新數(shù)據(jù)

1.2 數(shù)據(jù)結(jié)構(gòu)

ZooKeeper 數(shù)據(jù)模型的結(jié)構(gòu)與 Unix 文件系統(tǒng)很類似，整體上可以看作是一棵樹，每個節(jié)點稱做一個 ZNode。每一個 ZNode 默認能夠存儲 1MB 的數(shù)據(jù)，每個 ZNode 都可以通過其路徑唯一標(biāo)識。

數(shù)據(jù)結(jié)構(gòu)

1.3 應(yīng)用場景

主要應(yīng)用場景包括：統(tǒng)一命名服務(wù)、統(tǒng)一配置管理、統(tǒng)一集群管理、服務(wù)器節(jié)點動態(tài)上下線、軟負載均衡、分布式鎖等。

二、ZK基礎(chǔ)

2.1 安裝部署

下載地址：官方網(wǎng)站
安裝部署：參考http://www.manongjc.com/detail/26-ivfmoclzffihdfz.html

Zookeeper 中的配置文件 zoo.cfg中參數(shù)含義解讀如下:

1. tickTime = 2000：通信心跳時間，Zookeeper 服務(wù)器與客戶端心跳時間，單位毫秒
2. initLimit = 10：Leader 和 Follower 初始連接時能容忍的最多心跳數(shù)（tickTime的數(shù)量）
3. syncLimit = 5：Leader 和 Follower 之間通信時間如果超過 syncLimit * tickTime，Leader認為 Follwer 死掉，從服務(wù)器列表中刪除 Follwer
4. dataDir：保存 Zookeeper 中的數(shù)據(jù)。注意：默認的 tmp 目錄，容易被 Linux 系統(tǒng)定期刪除，所以一般不用默認目錄
5. clientPort = 2181：客戶端連接端口，通常不做修改

2.2 主要api

2.3 節(jié)點類型

• 短暫/持久：客戶端和服務(wù)器端斷開連接后，創(chuàng)建的節(jié)點刪除/不刪除
• 有序號/無序號：創(chuàng)建節(jié)點時設(shè)置順序標(biāo)識，節(jié)點名稱后會附加一個值，順序號是一個單調(diào)遞增的計數(shù)器，由父節(jié)點維護。在分布式系統(tǒng)中，順序號可以被用于為所有的事件進行全局排序，這樣客戶端可以通 過順序號推斷事件的順序

三、原理

3.1 選舉機制

初次選舉

初次選舉

如上圖，5臺機器組成的集群初次選舉流程：

1. 服務(wù)器1啟動，發(fā)起一次選舉。服務(wù)器1投自己一票。此時服務(wù)器1票數(shù)一票，不夠半數(shù)以上(3票)，選舉無法完成，服務(wù)器1狀態(tài)保持為 LOOKING;
2. 服務(wù)器2啟動，再發(fā)起一次選舉。服務(wù)器1和2分別投自己一票并交換選票信息：此時服務(wù)器1發(fā)現(xiàn)服務(wù)器2的 myid 比自己目前投票推舉的服務(wù)器1大，更改選票為推舉服務(wù)器2。此時服務(wù)器1票數(shù)0票，服務(wù)器2票數(shù)2票，沒有半數(shù)以上結(jié)果，選舉無法完成，服務(wù)器1，2狀態(tài)保持 LOOKING
3. 服務(wù)器3啟動，發(fā)起一次選舉。此時服務(wù)器1和2都會更改選票為服務(wù)器3。此次投票結(jié)果：服務(wù)器1為0票，服務(wù)器2為0票，服務(wù)器3為3票。此時服
   務(wù)器3的票數(shù)已經(jīng)超過半數(shù)，服務(wù)器3當(dāng)選 Leader。服務(wù)器1，2更改狀態(tài)為 FOLLOWING，服務(wù)器3更改狀態(tài)為 LEADING;
4. 服務(wù)器4啟動，發(fā)起一次選舉。此時服務(wù)器1，2，3已經(jīng)不是 LOOKING 狀態(tài)，不會更改選票信息。交換選票信息結(jié)果：服務(wù)器3為3票，服務(wù)器4為1票。此時服務(wù)器4服從多數(shù)，更改選票信息為服務(wù)器3，并更改狀態(tài)為FOLLOWING
5. 服務(wù)器5啟動，同4一樣當(dāng)小弟

非初次選舉

非初次選舉選舉 Leader 規(guī)則:

1. EPOCH 大的直接勝出
2. EPOCH 相同，ZXID（事務(wù)id）大的勝出
3. ZXID 相同，SID（服務(wù)器id）大的勝出

依然如上圖，假設(shè)5臺服務(wù)器 SID 分別為1、2、3、4、5，ZXID 分別為8、8、8、7、7，并且此時 SID 為3的服務(wù)器是 Leader。某一時刻，3和5服務(wù)器出現(xiàn)故障，因此開始進行 Leader 選舉:

SID為1、2、4的機器投票情況（EPOCH，ZXID，SID）分別為 : (1，8，1)，（1，8，2），（1，7，4），因此服務(wù)器2當(dāng)選為新的 Leader。

3.2 監(jiān)聽器原理

監(jiān)聽器原理

1. 首先客戶端會創(chuàng)建一個 main() 線程
2. 在main線程中創(chuàng)建 Zookeeper 客戶端，這時就會創(chuàng)建兩個線程，一個負責(zé)網(wǎng)絡(luò)連接通信（connet），一個負責(zé)監(jiān)聽（listener）
3. 通過 connect 線程將注冊的監(jiān)聽事件發(fā)送給 Zookeeper
4. 在 Zookeeper 的注冊監(jiān)聽器列表中將注冊的監(jiān)聽事件添加到列表中
5. Zookeeper 監(jiān)聽到有數(shù)據(jù)或路徑變化，就會將這個消息發(fā)送給 listener 線程
6. listener 線程內(nèi)部調(diào)用了process() 方法

常見的監(jiān)聽方式

• 監(jiān)聽節(jié)點數(shù)據(jù)的變化：get path [watch]
• 監(jiān)聽子節(jié)點增減的變化：ls path [watch]

3.3 寫數(shù)據(jù)流程

寫入請求直接發(fā)送給 Leader 節(jié)點：

寫流程1

寫入請求發(fā)送給 Follower 節(jié)點，F(xiàn)ollower 會轉(zhuǎn)發(fā)給 Leader 節(jié)點處理：

寫流程2

四、相關(guān)理論

1. 拜占庭將軍問題
   拜占庭將軍問題是一個協(xié)議問題，拜占庭帝國軍隊的將軍們必須全體一致的決定是否攻擊某一支敵軍。問題是這些將軍在地理上是分隔開來的，并且將軍中存在叛徒。叛徒可以任意行動以達到以下目標(biāo)：欺騙某些將軍采取進攻行動；促成一個不是所有將軍都同意的決定，如當(dāng)將軍們不希望進攻時促成進攻行動；或者迷惑某些將軍，使他們無法做出決定。如果叛徒達到了這些目的之一，則任何攻擊行動的結(jié)果都是注定要失敗的，只有完全達成一致的努力才能獲得勝利。
2. Paxos算法
   一種基于消息傳遞且具有高度容錯特性的一致性算法，解決的問題就是如何快速正確的在一個分布式系統(tǒng)中對某個數(shù)據(jù)值達成一致，并且保證不論發(fā)生任何異常都不會破壞整個系統(tǒng)的一致性。
3. ZAB協(xié)議
   借鑒了 Paxos 算法，是特別為 Zookeeper 設(shè)計的支持崩潰恢復(fù)的原子廣播協(xié)議。包括兩種基本的模式：消息廣播、崩潰恢復(fù)。基于該協(xié)議，Zookeeper 設(shè)計為只有一臺客戶端（Leader）負責(zé)處理外部的寫事務(wù)請求，然后 Leader 客戶端將數(shù)據(jù)同步到其他 Follower 節(jié)點（即 Zookeeper 只有一個 Leader 可以發(fā)起提案）
4. CAP理論
   CAP理論是說，一個分布式系統(tǒng)不可能同時滿足以下三種：

• 一致性(Consistency)：在分布式環(huán)境中，一致性是指數(shù)據(jù)在多個副本之間是否能夠保持數(shù)據(jù)一致的特性。在一致性的需求下，當(dāng)一個系統(tǒng)在數(shù)據(jù)一致的狀態(tài)下執(zhí)行更新操作后，應(yīng)該保證系統(tǒng)的數(shù)據(jù)仍然處于一致的狀態(tài)
• 可用性(Available)：可用性是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài)，對于用戶的每一個操作請求總是能夠在有限的時間內(nèi)返回結(jié)果
• 分區(qū)容錯性(Partition Tolerance)：分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務(wù)，除非是整個網(wǎng)絡(luò)環(huán)境都發(fā)生了故障

這三個基本需求，最多只能同時滿足其中的兩項。因為P是必須的，因此往往選擇就在CP或者AP中。ZooKeeper保證的是CP：

• ZooKeeper不能保證每次服務(wù)請求的可用性。在極端環(huán)境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結(jié)果
• 進行Leader選舉時集群都是短暫不可用