典型應(yīng)用場景

Apache HBase

HBase是一個(gè)通常與Hadoop一起使用的數(shù)據(jù)存儲(chǔ)倉庫。在HBase中，ZooKeeper用于選舉一個(gè)集群內(nèi)的主節(jié)點(diǎn)，以便跟蹤可用的服務(wù)器，并保存集群的元數(shù)據(jù)。

Apache Kafka

Kafka是一個(gè)基于發(fā)布-訂閱（pub-sub）模型的消息系統(tǒng)。其中ZooKeeper用于檢測崩潰，實(shí)現(xiàn)主題（topic）的發(fā)現(xiàn)，并保持主題的生產(chǎn)和消費(fèi)狀態(tài)。

Apache Solr

Solr是一個(gè)企業(yè)級的搜索平臺(tái)。Solr的分布式版本命名為SolrCloud，它使用ZooKeeper來存儲(chǔ)集群的元數(shù)據(jù)，并協(xié)作更新這些元數(shù)據(jù)。

具體使用場景總結(jié)如下

1、數(shù)據(jù)發(fā)布與訂閱

發(fā)布不訂閱模型，即所謂的配置中心，顧名思義就是發(fā)布者將數(shù)據(jù)發(fā)布到 ZK 節(jié)點(diǎn)上，供訂閱者動(dòng)態(tài)獲取數(shù)據(jù)，實(shí)現(xiàn)配置信息的集中式管理和動(dòng)態(tài)更新。例如全局的配置信息，服務(wù)式服務(wù)框架的服務(wù)地址列表等就非常適合使用。

• 應(yīng)用中用到的一些配置信息放到 ZK 上進(jìn)行集中管理。這類場景通常是這樣：應(yīng)用在啟動(dòng)的時(shí)候會(huì)主動(dòng)來獲取一次配置，同時(shí)，在節(jié)點(diǎn)上注冊
• 一個(gè) Watcher，這樣一來，以后每次配置有更新的時(shí)候，都會(huì)實(shí)時(shí)通知到訂閱的客戶端，從來達(dá)到獲取最新配置信息的目的。

• 分布式搜索服務(wù)中，索引的元信息和服務(wù)器集群機(jī)器的節(jié)點(diǎn)狀態(tài)存放在 ZK 的一些指定節(jié)點(diǎn)，供各個(gè)客戶端訂閱使用。
• 分布式日志收集系統(tǒng)。這個(gè)系統(tǒng)的核心工作是收集分布在不同機(jī)器的日志。收集器通常是按照應(yīng)用來分配收集任務(wù)單元，因此需要在 ZK 上創(chuàng)
• 建一個(gè)以應(yīng)用名作為 path 的節(jié)點(diǎn) P，并將這個(gè)應(yīng)用的所有機(jī)器 ip，以子節(jié)點(diǎn)的形式注冊到節(jié)點(diǎn) P 上，這樣一來就能夠?qū)崿F(xiàn)機(jī)器變動(dòng)的時(shí)候，能夠?qū)崟r(shí)通知到收集器調(diào)整任務(wù)分配。
• 系統(tǒng)中有些信息需要?jiǎng)討B(tài)獲取，并且還會(huì)存在人工手動(dòng)去修改這個(gè)信息的發(fā)問。通常是暴露出接口，例如 JMX 接口，來獲取一些運(yùn)行時(shí)的信息。

引入 ZK之后，就不用自己實(shí)現(xiàn)一套方案了，只要將這些信息存放到指定的 ZK 節(jié)點(diǎn)上即可。

注意：在上面提到的應(yīng)用場景中，有個(gè)默認(rèn)前提是：數(shù)據(jù)量很小，但是數(shù)據(jù)更新可能會(huì)比較快的場景。

2、負(fù)載均衡

這里說的負(fù)載均衡是指軟負(fù)載均衡。在分布式環(huán)境中，為了保證高可用性，通常同一個(gè)應(yīng)用或同一個(gè)服務(wù)的提供方都會(huì)部署多份，達(dá)到對等服務(wù)。

而消費(fèi)者就需要在這些對等的服務(wù)器中選擇一個(gè)來執(zhí)行相關(guān)的業(yè)務(wù)邏輯，其中比較典型的是消息中間件中的生產(chǎn)者，消費(fèi)者負(fù)載均衡。

消息中間件中發(fā)布者和訂閱者的負(fù)載均衡，linkedin 開源的 KafkaMQ 和阿里開源的 RocketMQ都是通過 zookeeper 來做到生產(chǎn)者、消費(fèi)者的負(fù)載均衡。這里以 RocketMQ為例如如下：

生產(chǎn)者負(fù)載均衡：

RocketMQ發(fā)送消息的時(shí)候，生產(chǎn)者在發(fā)送消息的時(shí)候必須選擇一臺(tái)broker上的一個(gè)分區(qū)來發(fā)送消息，因此RocketMQ在運(yùn)行過程中，會(huì)把所有broker和對應(yīng)的分區(qū)信息全部注冊到 ZK 指定節(jié)點(diǎn)上，默認(rèn)的策略是一個(gè)依次輪詢的過程，生產(chǎn)者在通過 ZK 獲取分區(qū)列表之后，會(huì)按照 brokerId 和partition 的順序排列組織成一個(gè)有序的分區(qū)列表，發(fā)送的時(shí)候按照從頭到尾循環(huán)往復(fù)的方式選擇一個(gè)分區(qū)來發(fā)送消息。

消費(fèi)負(fù)載均衡：

在消費(fèi)過程中，一個(gè)消費(fèi)者會(huì)消費(fèi)一個(gè)或多個(gè)分區(qū)中的消息，但是一個(gè)分區(qū)只會(huì)由一個(gè)消費(fèi)者來消費(fèi)。MetaQ 的消費(fèi)策略是：

1、每個(gè)分區(qū)針對同一個(gè) group 只掛載一個(gè)消費(fèi)者。

2、如果同一個(gè) group 的消費(fèi)者數(shù)目大于分區(qū)數(shù)目，則多出來的消費(fèi)者將不參不消費(fèi)。

3、如果同一個(gè) group 的消費(fèi)者數(shù)目小于分區(qū)數(shù)目，則有部分消費(fèi)者需要額外承擔(dān)消費(fèi)任務(wù)。

在某個(gè)消費(fèi)者故障或者重啟等情況下，其他消費(fèi)者會(huì)感知到這一變化（通過 zookeeper watcher 消費(fèi)者列表），然后重新進(jìn)行負(fù)載均衡，保證所有的分區(qū)都有消費(fèi)者進(jìn)行消費(fèi)。

3、命名服務(wù)(Naming Service)

命名服務(wù)也是分布式系統(tǒng)中比較常見的一類場景。在分布式系統(tǒng)中，通過使用命名服務(wù)，客戶端應(yīng)用能夠根據(jù)指定名字來獲取資源或服務(wù)的地址，提供者等信息。被命名的實(shí)體通常可以是集群中的機(jī)器，提供的服務(wù)地址，進(jìn)程對象等等，這些我們都可以統(tǒng)稱他們?yōu)槊郑∟ame）。

其中較為常見的就是一些分布式服務(wù)框架中的服務(wù)地址列表。通過調(diào)用 ZK 提供的創(chuàng)建節(jié)點(diǎn)的 API，能夠很容易創(chuàng)建一個(gè)全局唯一的 path，這個(gè) path 就可以作為一個(gè)名稱。

阿里開源的分布式服務(wù)框架 Dubbo 中使用 ZooKeeper 來作為其命名服務(wù)，維護(hù)全局的服務(wù)地址列表，點(diǎn)擊這里查看 Dubbo 開源項(xiàng)目。

在Dubbo 實(shí)現(xiàn)中：

服務(wù)提供者在啟動(dòng)的時(shí)候，向 ZK 上的指定節(jié)點(diǎn)/dubbo/${serviceName}/providers 目錄下寫入自己的 URL 地址，這個(gè)操作就完成了服務(wù)的發(fā)布。

服務(wù)消費(fèi)者啟動(dòng)的時(shí)候，訂閱/dubbo/${serviceName}/providers 目錄下的提供者 URL 地址， 并向/dubbo/${serviceName} /consumers目錄下寫入自己的 URL 地址。

注意，所有向 ZK 上注冊的地址都是臨時(shí)節(jié)點(diǎn)，這樣就能夠保證服務(wù)提供者和消費(fèi)者能夠自錄感應(yīng)資源的變化。

另外，Dubbo 還有針對服務(wù)粒度的監(jiān)控，方法是訂閱/dubbo/${serviceName}目錄下所有提供者和消費(fèi)者的信息。

4、分布式通知/協(xié)調(diào)

ZooKeeper 中特有 watcher 注冊不異步通知機(jī)制，能夠很好的實(shí)現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知不協(xié)調(diào)，實(shí)現(xiàn)對數(shù)據(jù)變更的實(shí)時(shí)處理。

使用方法通常是不同系統(tǒng)都對 ZK 上同一個(gè) znode 進(jìn)行注冊，監(jiān)聽 znode 的變化（包括 znode 本身內(nèi)容及子節(jié)點(diǎn)的），其中一個(gè)系統(tǒng) update 了 znode，那么另一個(gè)系統(tǒng)能夠收到通知，并作出相應(yīng)處理；

• 心跳檢測機(jī)制：檢測系統(tǒng)和被檢測系統(tǒng)之間并不直接關(guān)聯(lián)起來，而是通過 zk 上某個(gè)節(jié)點(diǎn)關(guān)聯(lián)，大大減少系統(tǒng)耦合。
• 系統(tǒng)調(diào)度模式：某系統(tǒng)有控制臺(tái)和推送系統(tǒng)兩部分組成，控制臺(tái)的職責(zé)是控制推送系統(tǒng)進(jìn)行相應(yīng)的推送工作。管理人員在控制臺(tái)作的一些操作，實(shí)際上是修改了 ZK 上某些節(jié)點(diǎn)的狀態(tài)，而 ZK 就把這些變化通知給他們注冊 Watcher 的客戶端，即推送系統(tǒng)，于是，作出相應(yīng)的推送任務(wù)。
• 工作匯報(bào)模式：一些類似于任務(wù)分發(fā)系統(tǒng)，子任務(wù)啟動(dòng)后，到 zk 來注冊一個(gè)臨時(shí)節(jié)點(diǎn)，并且定時(shí)將自己的進(jìn)度進(jìn)行匯報(bào)（將進(jìn)度寫回這個(gè)臨時(shí)節(jié)點(diǎn)），這樣任務(wù)管理者就能夠?qū)崟r(shí)知道任務(wù)進(jìn)度。

總之，使用 zookeeper 來進(jìn)行分布式通知和協(xié)調(diào)能夠大大降低系統(tǒng)之間的耦合

5、集群管理與 Master 選舉

1）、集群機(jī)器監(jiān)控

這通常用于那種對集群中機(jī)器狀態(tài)，機(jī)器在線率有較高要求的場景，能夠快速對集群中機(jī)器變化作出響應(yīng)。這樣的場景中，往往有一個(gè)監(jiān)控系統(tǒng)，實(shí)時(shí)檢測集群機(jī)器是否存活。過去的做法通常是：監(jiān)控系統(tǒng)通過某種手段（比如 ping）定時(shí)檢測每個(gè)機(jī)器，或者每個(gè)機(jī)器自己定時(shí)向監(jiān)控系統(tǒng)匯報(bào)“我還活著”。 這種做法可行，但是存在兩個(gè)比較明顯的問題：

1. 集群中機(jī)器有變動(dòng)的時(shí)候，牽連修改的東西比較多。

2. 有一定的延時(shí)。

利用 ZooKeeper 有兩個(gè)特性，就可以實(shí)時(shí)另一種集群機(jī)器存活性監(jiān)控系統(tǒng)：

1. 客戶端在節(jié)點(diǎn) x 上注冊一個(gè) Watcher，那么如果 x 的子節(jié)點(diǎn)變化了，會(huì)通知該客戶端。
2. 創(chuàng)建臨時(shí)（ephemeral）類型的節(jié)點(diǎn)，一旦客戶端和服務(wù)器的會(huì)話結(jié)束或過期，那么該節(jié)點(diǎn)就會(huì)消失。

例如，監(jiān)控系統(tǒng)在 /clusterServers 節(jié)點(diǎn)上注冊一個(gè) Watcher，以后每動(dòng)態(tài)加機(jī)器，那么就往 /clusterServers 下創(chuàng)建一個(gè)臨時(shí)（ephemeral）類型的節(jié)點(diǎn)：/clusterServers/{hostname}.

這樣，監(jiān)控系統(tǒng)就能夠?qū)崟r(shí)知道機(jī)器的增減情況，至于后續(xù)處理就是監(jiān)控系統(tǒng)的業(yè)務(wù)了。

Master 選舉則是 zookeeper 中最為經(jīng)典的應(yīng)用場景了。

在分布式環(huán)境中，相同的業(yè)務(wù)應(yīng)用分布在不同的機(jī)器上，有些業(yè)務(wù)邏輯（例如一些耗時(shí)的計(jì)算，網(wǎng)絡(luò) I/O 處理），往往只需要讓整個(gè)集群中的某一臺(tái)機(jī)器進(jìn)行執(zhí)行，其余機(jī)器可以共享這個(gè)結(jié)果，這樣可以大大減少重復(fù)勞動(dòng)，提高性能，于是這個(gè) master 選丼便是這種場景下的碰到的主要問題。

利用 ZooKeeper 的強(qiáng)一致性，能夠保證在分布式高并發(fā)情況下節(jié)點(diǎn)創(chuàng)建的全局唯一性，即：同時(shí)有多個(gè)客戶端請求創(chuàng)建 /currentMaster 節(jié)點(diǎn)，最終一定只有一個(gè)客戶端請求能夠創(chuàng)建成功。利用這個(gè)特性，就能很輕易的在分布式環(huán)境中進(jìn)行集群選取了。

另外，這種場景演化一下，就是動(dòng)態(tài) Master 選舉。這就要用到 EPHEMERAL_SEQUENTIAL 類型節(jié)點(diǎn)的特性了。

上文中提到，所有客戶端創(chuàng)建請求，最終只有一個(gè)能夠創(chuàng)建成功。在這里稍微變化下，就是允許所有請求都能夠創(chuàng)建成功，但是得有個(gè)創(chuàng)建順序，

于是所有的請求最終在 ZK 上創(chuàng)建結(jié)果的一種可能情況是這樣：

/currentMaster/{sessionId}-1 , /currentMaster/{sessionId}-2 , /currentMaster/{sessionId}-3 ….. 每次選取序列號最小的那個(gè)機(jī)器作為Master，如果這個(gè)機(jī)器掛了，由于他創(chuàng)建的節(jié)點(diǎn)會(huì)馬上消失，那么之后最小的那個(gè)機(jī)器就是 Master 了。

• 在搜索系統(tǒng)中，如果集群中每個(gè)機(jī)器都生成一份全量索引，不僅耗時(shí)，而且不能保證彼此之間索引數(shù)據(jù)一致。因此讓集群中的 Master 來進(jìn)行全量索引的生成，然后同步到集群中其它機(jī)器。另外，Master 選舉的容災(zāi)措施是，可以隨時(shí)迚行手動(dòng)指定 master，就是說應(yīng)用在 zk 在無法獲取 master 信息時(shí)，可以通過比如 http 方式，向一個(gè)地方獲取 master。

• 在 Hbase 中，也是使用 ZooKeeper 來實(shí)現(xiàn)動(dòng)態(tài) HMaster 的選舉。在 Hbase 實(shí)現(xiàn)中，會(huì)在 ZK 上存儲(chǔ)一些 ROOT 表的地址和 HMaster 的地址，HRegionServer 也會(huì)把自己以臨時(shí)節(jié)點(diǎn)（Ephemeral）的方式注冊到 Zookeeper 中，使得 HMaster 可以隨時(shí)感知到各個(gè) HRegionServer的存活狀態(tài)，同時(shí)，一旦 HMaster 出現(xiàn)問題，會(huì)重新選舉出一個(gè) HMaster 來運(yùn)行，從而避免了 HMaster 的單點(diǎn)問題

6、分布式鎖

分布式鎖，這個(gè)主要得益于 ZooKeeper 為我們保證了數(shù)據(jù)的強(qiáng)一致性。鎖服務(wù)可以分為兩類，一個(gè)是保持獨(dú)占，另一個(gè)是控制時(shí)序。

• 所謂保持獨(dú)占，就是所有試圖來獲取這個(gè)鎖的客戶端，最終只有一個(gè)可以成功獲得這把鎖。通常的做法是把 zk 上的一個(gè) znode 看作是一把鎖，通過 create znode 的方式來實(shí)現(xiàn)。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點(diǎn)，最終成功創(chuàng)建的那個(gè)客戶端也即擁有了這把鎖。
• 控制時(shí)序，就是所有視圖來獲取這個(gè)鎖的客戶端，最終都是會(huì)被安排執(zhí)行，只是有個(gè)全局時(shí)序了。做法和上面基本類似，只是這里/distribute_lock 已經(jīng)預(yù)先存在，客戶端在它 下 面 創(chuàng) 建 臨 時(shí) 有 序 節(jié) 點(diǎn) （ 這 個(gè) 可 以 通 過 節(jié) 點(diǎn) 的 屬 性 控 制 ：CreateMode.EPHEMERAL_SEQUENTIAL 來指定）。

Zk 的父節(jié)點(diǎn)（/distribute_lock）維持一份 sequence,保證子節(jié)點(diǎn)創(chuàng)建的時(shí)序性，從而也形成了每個(gè)客戶端的全局時(shí)序。

7、分布式隊(duì)列

隊(duì)列方面，簡單地講有兩種

第一種是常規(guī)的先進(jìn)先出隊(duì)列，另一種是要等到隊(duì)列成員聚齊之后的才統(tǒng)一按序執(zhí)行。對于第一種先進(jìn)先出隊(duì)列，和分布式鎖服務(wù)中的控制時(shí)序場景基本原理一致，這里不再贅述。

第二種隊(duì)列其實(shí)是在 FIFO 隊(duì)列的基礎(chǔ)上作了一個(gè)增強(qiáng)。通常可以在 /queue 這個(gè) znode 下預(yù)先建立一個(gè)/queue/num 節(jié)點(diǎn)，并且賦值為 n（或者直接給/queue 賦值 n），表示隊(duì)列大小，之后每次有隊(duì)列成員加入后，就判斷下是否已經(jīng)到達(dá)隊(duì)列大小，決定是否可以開始執(zhí)行了。這種用法的典型場景是，分布式環(huán)境中，一個(gè)大任務(wù) Task A，需要在很多子任務(wù)完成（或條件就緒）情況下才能進(jìn)行。這個(gè)時(shí)候，凡是其中一個(gè)子任務(wù)完成（就緒），那么就去 /taskList 下建立自己的臨時(shí)時(shí)序節(jié)點(diǎn)（CreateMode.EPHEMERAL_SEQUENTIAL），當(dāng) /taskList 發(fā)現(xiàn)自己下面的子節(jié)點(diǎn)滿足指定個(gè)數(shù)，就可以進(jìn)行下一步按序進(jìn)行處理了。