阿里P8架構(gòu)師談：Zookeeper的原理和架構(gòu)設(shè)計(jì)，以及應(yīng)用場(chǎng)景

隨著信息化水平的不斷提高，企業(yè)級(jí)應(yīng)用系統(tǒng)變得越來(lái)越龐大，性能隨之下降，用戶(hù)抱怨頻頻。拆分系統(tǒng)是目前我們可選擇的解決系統(tǒng)可伸縮性和性能問(wèn)題的唯一行之有效的方法。但是拆分系統(tǒng)同時(shí)也帶來(lái)了系統(tǒng)的復(fù)雜性——各子系統(tǒng)不是孤立存在的，它們彼此之間需要協(xié)作和交互（分布式系統(tǒng)）。各個(gè)子系統(tǒng)就好比動(dòng)物園里的動(dòng)物，為了使各個(gè)子系統(tǒng)能正常為用戶(hù)提供統(tǒng)一的服務(wù)，必須需要一種機(jī)制來(lái)進(jìn)行協(xié)調(diào)——這就是ZooKeeper（動(dòng)物園管理員）。下面詳解：


什么是 Zookeeper

Zookeeper 分布式服務(wù)框架是Apache Hadoop 的一個(gè)子項(xiàng)目，它主要是用來(lái)解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問(wèn)題，如：
統(tǒng)一命名服務(wù)；
狀態(tài)同步服務(wù);
集群管理;
分布式應(yīng)用配置項(xiàng)的管理等。

Zookeeper已經(jīng)成為Hadoop生態(tài)系統(tǒng)中的基礎(chǔ)組件。


Zookeeper的基本原理和架構(gòu)

1、Zookeeper的角色
領(lǐng)導(dǎo)者（leader）：負(fù)責(zé)進(jìn)行投票的發(fā)起和決議，更新系統(tǒng)狀態(tài)；
學(xué)習(xí)者（learner）：包括跟隨者（follower）和觀察者（observer），follower用于接受客戶(hù)端請(qǐng)求并想客戶(hù)端返回結(jié)果，在選主過(guò)程中參與投票；
Observer：可以接受客戶(hù)端連接，將寫(xiě)請(qǐng)求轉(zhuǎn)發(fā)給leader，但observer不參加投票過(guò)程，只同步leader的狀態(tài)，observer的目的是為了擴(kuò)展系統(tǒng)，提高讀取速度；
客戶(hù)端（client）：請(qǐng)求發(fā)起方。

? Zookeeper的核心是原子廣播，這個(gè)機(jī)制保證了各個(gè)Server之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（選主）和廣播模式（同步）。當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來(lái)，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。
? 為了保證事務(wù)的順序一致性，zookeeper采用了遞增的事務(wù)id號(hào)（zxid）來(lái)標(biāo)識(shí)事務(wù)。所有的提議（proposal）都在被提出的時(shí)候加上了zxid。實(shí)現(xiàn)中zxid是一個(gè)64位的數(shù)字，它高32位是epoch用來(lái)標(biāo)識(shí)leader關(guān)系是否改變，每次一個(gè)leader被選出來(lái)，它都會(huì)有一個(gè)新的epoch，標(biāo)識(shí)當(dāng)前屬于那個(gè)leader的統(tǒng)治時(shí)期。低32位用于遞增計(jì)數(shù)。
? 每個(gè)Server在工作過(guò)程中有三種狀態(tài)：
LOOKING：當(dāng)前Server不知道leader是誰(shuí)，正在搜尋；
LEADING：當(dāng)前Server即為選舉出來(lái)的leader；
FOLLOWING：leader已經(jīng)選舉出來(lái)，當(dāng)前Server與之同步。

2、Zookeeper 的讀寫(xiě)機(jī)制
Zookeeper是一個(gè)由多個(gè)server組成的集群；
一個(gè)leader，多個(gè)follower；
每個(gè)server保存一份數(shù)據(jù)副本；
全局?jǐn)?shù)據(jù)一致；
分布式讀寫(xiě)；
更新請(qǐng)求轉(zhuǎn)發(fā)，由leader實(shí)施。

3、Zookeeper 的保證
更新請(qǐng)求順序進(jìn)行，來(lái)自同一個(gè)client的更新請(qǐng)求按其發(fā)送順序依次執(zhí)行；
數(shù)據(jù)更新原子性，一次數(shù)據(jù)更新要么成功，要么失敗；
全局唯一數(shù)據(jù)視圖，client無(wú)論連接到哪個(gè)server，數(shù)據(jù)視圖都是一致的；
實(shí)時(shí)性，在一定事件范圍內(nèi)，client能讀到最新數(shù)據(jù)。

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

在Client向Follwer發(fā)出一個(gè)寫(xiě)的請(qǐng)求；
Follwer把請(qǐng)求發(fā)送給Leader；
Leader接收到以后開(kāi)始發(fā)起投票并通知Follwer進(jìn)行投票；
Follwer把投票結(jié)果發(fā)送給Leader；
Leader將結(jié)果匯總后如果需要寫(xiě)入，則開(kāi)始寫(xiě)入同時(shí)把寫(xiě)入操作通知給Leader，然后commit;
Follwer把請(qǐng)求結(jié)果返回給Client。

5、Zookeeper工作原理
Zookeeper的核心是原子廣播，這個(gè)機(jī)制保證了各個(gè)server之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是：恢復(fù)模式和廣播模式。當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來(lái)，且大多數(shù)server的完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。

6、數(shù)據(jù)一致性與paxos 算法
? 據(jù)說(shuō)Paxos算法的難理解與算法的知名度一樣令人敬仰，所以我們先看如何保持?jǐn)?shù)據(jù)的一致性，這里有個(gè)原則就是：
? 在一個(gè)分布式數(shù)據(jù)庫(kù)系統(tǒng)中，如果各節(jié)點(diǎn)的初始狀態(tài)一致，每個(gè)節(jié)點(diǎn)都執(zhí)行相同的操作序列，那么他們最后能得到一個(gè)一致的狀態(tài)。
? Paxos算法解決的什么問(wèn)題呢，解決的就是保證每個(gè)節(jié)點(diǎn)執(zhí)行相同的操作序列。好吧，這還不簡(jiǎn)單，master維護(hù)一個(gè)全局寫(xiě)隊(duì)列，所有寫(xiě)操作都必須 放入這個(gè)隊(duì)列編號(hào)，那么無(wú)論我們寫(xiě)多少個(gè)節(jié)點(diǎn)，只要寫(xiě)操作是按編號(hào)來(lái)的，就能保證一致性。沒(méi)錯(cuò)，就是這樣，可是如果master掛了呢。
? Paxos算法通過(guò)投票來(lái)對(duì)寫(xiě)操作進(jìn)行全局編號(hào)，同一時(shí)刻，只有一個(gè)寫(xiě)操作被批準(zhǔn)，同時(shí)并發(fā)的寫(xiě)操作要去爭(zhēng)取選票，只有獲得過(guò)半數(shù)選票的寫(xiě)操作才會(huì)被 批準(zhǔn)（所以永遠(yuǎn)只會(huì)有一個(gè)寫(xiě)操作得到批準(zhǔn)），其他的寫(xiě)操作競(jìng)爭(zhēng)失敗只好再發(fā)起一輪投票，就這樣，在日復(fù)一日年復(fù)一年的投票中，所有寫(xiě)操作都被嚴(yán)格編號(hào)排 序。編號(hào)嚴(yán)格遞增，當(dāng)一個(gè)節(jié)點(diǎn)接受了一個(gè)編號(hào)為100的寫(xiě)操作，之后又接受到編號(hào)為99的寫(xiě)操作（因?yàn)榫W(wǎng)絡(luò)延遲等很多不可預(yù)見(jiàn)原因），它馬上能意識(shí)到自己 數(shù)據(jù)不一致了，自動(dòng)停止對(duì)外服務(wù)并重啟同步過(guò)程。任何一個(gè)節(jié)點(diǎn)掛掉都不會(huì)影響整個(gè)集群的數(shù)據(jù)一致性（總2n+1臺(tái)，除非掛掉大于n臺(tái)）。
總結(jié)：Zookeeper 作為 Hadoop 項(xiàng)目中的一個(gè)子項(xiàng)目，是 Hadoop 集群管理的一個(gè)必不可少的模塊，它主要用來(lái)控制集群中的數(shù)據(jù)，如它管理 Hadoop 集群中的 NameNode，還有 Hbase 中 Master Election、Server 之間狀態(tài)同步等。

7、Observer
Zookeeper需保證高可用和強(qiáng)一致性；
為了支持更多的客戶(hù)端，需要增加更多Server；
Server增多，投票階段延遲增大，影響性能；
權(quán)衡伸縮性和高吞吐率，引入Observer；
Observer不參與投票；
Observers接受客戶(hù)端的連接，并將寫(xiě)請(qǐng)求轉(zhuǎn)發(fā)給leader節(jié)點(diǎn)；
加入更多Observer節(jié)點(diǎn)，提高伸縮性，同時(shí)不影響吞吐率。

8、 為什么zookeeper集群的數(shù)目，一般為奇數(shù)個(gè)？
Leader選舉算法采用了Paxos協(xié)議；
Paxos核心思想：當(dāng)多數(shù)Server寫(xiě)成功，則任務(wù)數(shù)據(jù)寫(xiě)成功如果有3個(gè)Server，則兩個(gè)寫(xiě)成功即可；如果有4或5個(gè)Server，則三個(gè)寫(xiě)成功即可；
Server數(shù)目一般為奇數(shù)（3、5、7）如果有3個(gè)Server，則最多允許1個(gè)Server掛掉；如果有4個(gè)Server，則同樣最多允許1個(gè)Server掛掉由此，我們看出3臺(tái)服務(wù)器和4臺(tái)服務(wù)器的的容災(zāi)能力是一樣的，所以為了節(jié)省服務(wù)器資源，一般我們采用奇數(shù)個(gè)數(shù)，作為服務(wù)器部署個(gè)數(shù)。

9、Zookeeper 的數(shù)據(jù)模型　
層次化的目錄結(jié)構(gòu)，命名符合常規(guī)文件系統(tǒng)規(guī)范；
每個(gè)節(jié)點(diǎn)在zookeeper中叫做znode,并且其有一個(gè)唯一的路徑標(biāo)識(shí)；
節(jié)點(diǎn)Znode可以包含數(shù)據(jù)和子節(jié)點(diǎn)，但是EPHEMERAL類(lèi)型的節(jié)點(diǎn)不能有子節(jié)點(diǎn)；
Znode中的數(shù)據(jù)可以有多個(gè)版本，比如某一個(gè)路徑下存有多個(gè)數(shù)據(jù)版本，那么查詢(xún)這個(gè)路徑下的數(shù)據(jù)就需要帶上版本；
客戶(hù)端應(yīng)用可以在節(jié)點(diǎn)上設(shè)置監(jiān)視器；
節(jié)點(diǎn)不支持部分讀寫(xiě)，而是一次性完整讀寫(xiě)。

10、Zookeeper 的節(jié)點(diǎn)
Znode有兩種類(lèi)型，短暫的（ephemeral）和持久的（persistent）；
Znode的類(lèi)型在創(chuàng)建時(shí)確定并且之后不能再修改；
短暫znode的客戶(hù)端會(huì)話(huà)結(jié)束時(shí)，zookeeper會(huì)將該短暫znode刪除，短暫znode不可以有子節(jié)點(diǎn)；
持久znode不依賴(lài)于客戶(hù)端會(huì)話(huà)，只有當(dāng)客戶(hù)端明確要?jiǎng)h除該持久znode時(shí)才會(huì)被刪除；
Znode有四種形式的目錄節(jié)點(diǎn)；
PERSISTENT（持久的）；
EPHEMERAL(暫時(shí)的)；
PERSISTENT_SEQUENTIAL（持久化順序編號(hào)目錄節(jié)點(diǎn)）；
EPHEMERAL_SEQUENTIAL（暫時(shí)化順序編號(hào)目錄節(jié)點(diǎn)）。

Zookeeper的應(yīng)用場(chǎng)景

1. 配置管理
這個(gè)好理解，分布式系統(tǒng)都有好多機(jī)器，比如我在搭建hadoop的HDFS的時(shí)候，需要在一個(gè)主機(jī)器上（Master節(jié)點(diǎn)）配置好HDFS需要的各種配置文件，然后通過(guò)scp命令把這些配置文件拷貝到其他節(jié)點(diǎn)上，這樣各個(gè)機(jī)器拿到的配置信息是一致的，才能成功運(yùn)行起來(lái)HDFS服務(wù)。
Zookeeper提供了這樣的一種服務(wù)：一種集中管理配置的方法，我們?cè)谶@個(gè)集中的地方修改了配置，所有對(duì)這個(gè)配置感興趣的都可以獲得變更。這樣就省去手動(dòng)拷貝配置了，還保證了可靠和一致性。

2. 名字服務(wù)
這個(gè)可以簡(jiǎn)單理解為一個(gè)電話(huà)薄，電話(huà)號(hào)碼不好記，但是人名好記，要打誰(shuí)的電話(huà)，直接查人名就好了。分布式環(huán)境下，經(jīng)常需要對(duì)應(yīng)用/服務(wù)進(jìn)行統(tǒng)一命名，便于識(shí)別不同服務(wù)；
類(lèi)似于域名與ip之間對(duì)應(yīng)關(guān)系，域名容易記?。?br/>通過(guò)名稱(chēng)來(lái)獲取資源或服務(wù)的地址，提供者等信息。

3. 分布式鎖
碰到分布二字貌似就難理解了，其實(shí)很簡(jiǎn)單。單機(jī)程序的各個(gè)進(jìn)程需要對(duì)互斥資源進(jìn)行訪(fǎng)問(wèn)時(shí)需要加鎖，那分布式程序分布在各個(gè)主機(jī)上的進(jìn)程對(duì)互斥資源進(jìn)行訪(fǎng)問(wèn)時(shí)也需要加鎖。很多分布式系統(tǒng)有多個(gè)可服務(wù)的窗口，但是在某個(gè)時(shí)刻只讓一個(gè)服務(wù)去干活，當(dāng)這臺(tái)服務(wù)出問(wèn)題的時(shí)候鎖釋放，立即fail over到另外的服務(wù)。這在很多分布式系統(tǒng)中都是這么做，這種設(shè)計(jì)有一個(gè)更好聽(tīng)的名字叫Leader Election(leader選舉)。舉個(gè)通俗點(diǎn)的例子，比如銀行取錢(qián)，有多個(gè)窗口，但是呢對(duì)你來(lái)說(shuō)，只能有一個(gè)窗口對(duì)你服務(wù)，如果正在對(duì)你服務(wù)的窗口的柜員突然有急事走了，那咋辦？找大堂經(jīng)理（zookeeper）!大堂經(jīng)理指定另外的一個(gè)窗口繼續(xù)為你服務(wù)！

4. 集群管理
在分布式的集群中，經(jīng)常會(huì)由于各種原因，比如硬件故障，軟件故障，網(wǎng)絡(luò)問(wèn)題，有些節(jié)點(diǎn)會(huì)進(jìn)進(jìn)出出。有新的節(jié)點(diǎn)加入進(jìn)來(lái)，也有老的節(jié)點(diǎn)退出集群。這個(gè)時(shí)候，集群中有些機(jī)器（比如Master節(jié)點(diǎn)）需要感知到這種變化，然后根據(jù)這種變化做出對(duì)應(yīng)的決策。我已經(jīng)知道HDFS中namenode是通過(guò)datanode的心跳機(jī)制來(lái)實(shí)現(xiàn)上述感知的，那么我們可以先假設(shè)Zookeeper其實(shí)也是實(shí)現(xiàn)了類(lèi)似心跳機(jī)制的功能吧！
更多高并發(fā)架構(gòu)系列連載，內(nèi)容包括：java高并發(fā)、SOA、分布式集群、多線(xiàn)程、Redis、數(shù)據(jù)庫(kù)分庫(kù)分表、負(fù)載均衡等。