1. ZooKeeper 概述

ZooKeeper 是一個(gè)開源的高可用的分布式數(shù)據(jù)管理與系統(tǒng)協(xié)調(diào)框架，基于對 Paxos 算法的實(shí)現(xiàn)，保證了分布式環(huán)境中數(shù)據(jù)的強(qiáng)一致性。

1.1 ZooKeeper 典型應(yīng)用場景

1.1.1 配置中心（數(shù)據(jù)發(fā)布與訂閱）

發(fā)布與訂閱模型：發(fā)布者發(fā)布數(shù)據(jù)到 ZK 節(jié)點(diǎn)上，供訂閱者動(dòng)態(tài)獲取數(shù)據(jù)。

在數(shù)據(jù)量很少，但是數(shù)據(jù)更新快的場景下：

• 配置信息放到 ZK節(jié)點(diǎn)上集中管理。應(yīng)用啟動(dòng)時(shí)，主動(dòng)獲取一次，同時(shí)在節(jié)點(diǎn)上注冊一個(gè) Watcher，這樣每次配置更新時(shí)，都會(huì)實(shí)時(shí)通知到訂閱的客戶端獲取。
• 分布式搜索服務(wù)中，索引的元信息 & 服務(wù)器集群機(jī)器的節(jié)點(diǎn)狀態(tài)存放在 ZK 節(jié)點(diǎn)上。
• 分布式日志收集系統(tǒng)。zk 上創(chuàng)建一個(gè)以應(yīng)用名命名的節(jié)點(diǎn)P，這個(gè)應(yīng)用的所有機(jī)器 ip，作為子節(jié)點(diǎn)注冊到節(jié)點(diǎn) P 上，這樣能夠實(shí)時(shí)通知收集器調(diào)整任務(wù)分配。
• 系統(tǒng)中信息的動(dòng)態(tài)獲取，且存在人工手動(dòng)修改信息的可能。通常是暴露出接口。

1.1.2 負(fù)載均衡（軟負(fù)載均衡）

消息中間件中的發(fā)布者和訂閱者的負(fù)載均衡，linkedin 開源的 KafkaMQ 和 阿里開源的 MetaQ 都是通過 ZooKeeper 來做到生產(chǎn)者 & 消費(fèi)者的負(fù)載均衡：

1. 生產(chǎn)者負(fù)載均衡：MetaQ 運(yùn)行時(shí)，會(huì)把所有 broker 和對應(yīng)的分區(qū)信息全部注冊到 ZK 節(jié)點(diǎn)上，然后生產(chǎn)者通過 ZK 獲取分區(qū)列表之后，會(huì)依次輪詢的策略來選擇一個(gè)分區(qū)來發(fā)送消息。
2. 消費(fèi)者負(fù)載均衡：一個(gè)消費(fèi)者可以消費(fèi)（查看）一個(gè)或多個(gè)分區(qū)中的消息，但是一個(gè)分區(qū)的消息只會(huì)由一個(gè)消費(fèi)者來消費(fèi)。

MetaQ 的消費(fèi)策略是：

• 每個(gè)分區(qū)針對同一個(gè)組只掛載一個(gè)消費(fèi)者
• 如果同一個(gè)組的消費(fèi)者數(shù)目大于分區(qū)數(shù)目，則多余的消費(fèi)者不參與消費(fèi)
• 如果同一個(gè)組的消費(fèi)者數(shù)目小于分區(qū)數(shù)目，則由部分消費(fèi)者需要額外承擔(dān)消費(fèi)任務(wù)

當(dāng)某個(gè)消費(fèi)者故障或重啟時(shí)，其他消費(fèi)者會(huì)感知到（通過 watch 消費(fèi)者列表），然后重新進(jìn)行負(fù)載均衡，保證所有分區(qū)都有消費(fèi)者進(jìn)行消費(fèi)。

1.1.3 命名服務(wù)

在分布式系統(tǒng)中，通過使用命名服務(wù)，客戶端應(yīng)用通過指定名字來獲取資源、服務(wù)的地址等信息。較為常見的：分布式服務(wù)框架中的服務(wù)地址列表。

阿里巴巴集團(tuán)開源的分布式服務(wù)框架 Dubbo 中使用 ZooKeeper 來作為其命名服務(wù)，維護(hù)全局的服務(wù)地址列表。在 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 目錄下寫入自己的消費(fèi)者 URL 地址。

以上注冊的地址都是臨時(shí)節(jié)點(diǎn)，保證服務(wù)提供者和消費(fèi)者能夠自動(dòng)感應(yīng)資源的變化。

1.1.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è)節(jié)點(diǎn)進(jìn)行注冊，監(jiān)聽節(jié)點(diǎn)的變化（包括節(jié)點(diǎn)本身內(nèi)容及子節(jié)點(diǎn)的），其中一個(gè)系統(tǒng)更新了節(jié)點(diǎn)，那么另一個(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)修改了 ZK 上某些節(jié)點(diǎn)的狀態(tài)，而 ZK 就會(huì)把這些變化通知給他們注冊 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)（寫入節(jié)點(diǎn)），這樣任務(wù)管理者能夠實(shí)時(shí)監(jiān)控任務(wù)進(jìn)度。

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

1.1.5 集群管理與 Master 選舉

集群機(jī)器監(jiān)控：通常用于對集群中機(jī)器狀態(tài)、機(jī)器在線率有較高要求的場景，能夠快速對集群中機(jī)器變化作出響應(yīng)。

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

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

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

在分布式環(huán)境中，有些耗時(shí)的操作，往往只需讓整個(gè)集群中的某一臺(tái)機(jī)器進(jìn)行執(zhí)行，其余的機(jī)器可以共享這個(gè)結(jié)果。那么誰去執(zhí)行呢？于是就要靠 Master 選舉了。

首先利用 ZooKeeper 的強(qiáng)一致性，保證分布式高并發(fā)情況下節(jié)點(diǎn)創(chuàng)建的全局唯一性。即：同時(shí)有多個(gè)客戶端請求創(chuàng)建 /currentMaster 節(jié)點(diǎn)，但最終一定只有一個(gè)客戶端請求能夠創(chuàng)建成功。

其次，如果需要動(dòng)態(tài) Master 選舉，那就要用到 EPHEMERAL_SEQUENTIAL 類型節(jié)點(diǎn)。此時(shí)，允許所有的請求都能夠創(chuàng)建成功，但是有創(chuàng)建順序，于是每次選取序列號(hào)最小的那個(gè)機(jī)器作為 Master，如果 Master 機(jī)器掛了，那么之后最小的機(jī)器繼續(xù)當(dāng) Master。

• 在搜索系統(tǒng)中，讓集群中的 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 的選舉。

1.1.6 分布式鎖

鎖服務(wù)可以分為兩類：保持獨(dú)占、控制時(shí)序。

• 保持獨(dú)占：所有試圖獲取這個(gè)鎖的客戶端中，只有一個(gè)可以成功獲得這把鎖。做法：把 ZK 上的一個(gè) znode 看做一把鎖，所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點(diǎn)，最終成功創(chuàng)建的客戶端擁有這把鎖。
• 控制時(shí)序：所有試圖獲取這個(gè)鎖的客戶端中，都會(huì)按照一個(gè)全局時(shí)序執(zhí)行。做法跟上面的基本類似， /distribute_lock 已經(jīng)預(yù)先存在，客戶端在它下面創(chuàng)建臨時(shí)有序節(jié)點(diǎn)。ZK 的父節(jié)點(diǎn)（/distribute_lock） 維持一份 sequence ，保證子節(jié)點(diǎn)創(chuàng)建的時(shí)序性，從而形成了每個(gè)客戶端的全局時(shí)序。

1.1.7 分布式隊(duì)列

隊(duì)列方面分兩種：先進(jìn)先出隊(duì)列、等到隊(duì)列成員聚齊之后才統(tǒng)一按序執(zhí)行。

第一種：FIFO 隊(duì)列，與分布式鎖服務(wù)中你給的控制時(shí)序場景原理基本一致。

第二種：FIFO 隊(duì)列的增強(qiáng)版。做法：在 /queue 這個(gè)節(jié)點(diǎn)下，預(yù)先建立一個(gè) /queue/num 節(jié)點(diǎn)，并且賦值為 n ，表示隊(duì)列的大小，當(dāng)隊(duì)列成員數(shù)到達(dá)隊(duì)列大小時(shí)，就開始執(zhí)行。
第二種用法的典型場景：分布式環(huán)境中，一個(gè)大任務(wù) TaskA，需要在很多子任務(wù)完成（或者條件就緒）情況下才能進(jìn)行。此時(shí)，只要其中一個(gè)子任務(wù)完成（就緒），就去 /taskList 下建立自己的臨時(shí)節(jié)點(diǎn)，當(dāng) /tashList 發(fā)現(xiàn)自己下面的子節(jié)點(diǎn)滿足指定個(gè)數(shù)，就可以進(jìn)行下一步按序處理了。