ZooKeeper 是 Apache 的一個頂級專案，為分散式應用提供高效、高可用的分散式協調服務，提供了諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知和分散式鎖等分散式基礎服務。由於 ZooKeeper 便捷的使用方式、卓越的效能和良好的穩定性，被廣泛地應用於諸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分散式系統中。

本文的目標讀者是對 ZooKeeper 有一定了解的技術人員，將從 ZooKeeper 執行模式、叢集組成、容災和水平擴容四方面逐步深入，最終構建出高可用的 ZooKeeper 叢集。

一、執行模式

Zookeeper 有三種執行模式：單機模式、偽叢集模式和叢集模式。

1.1 單機模式

這種模式一般適用於開發測試環境，一方面我們沒有那麼多機器資源，另外就是平時的開發除錯並不需要極好的穩定性。

在 Linux 環境下執行單機模式需要執行以下步驟：

1、準備 Java 執行環境 安裝 Java 1.6 或更高版本的 JDK，並配置好 Java 相關的環境變數 $JAVA_HOME 。

2、下載 ZooKeeper 安裝包 下載地址：http://zookeeper.apache.org/releases.html。選擇最新的 stable 版本並解壓到指定目錄，我們用 $ZK_HOME 表示該目錄。

3、配置 zoo.cfg 首次使用 ZooKeeper，需要將 $ZK_HOME 下的 zoo_sample.cfg 檔案重新命名為 zoo.cfg，並進行以下配置

4、啟動服務 使用 $ZK_HOME/bin 目錄下的 zkServer.sh 指令碼進行服務的啟動。

1.2 叢集模式

一個 ZooKeeper 叢集通常由一組機器組成，一般 3 臺以上就可以組成一個可用的 ZooKeeper 叢集了。

組成 ZooKeeper 叢集的每臺機器都會在記憶體中維護當前的伺服器狀態，並且每臺機器之間都會互相保持通訊。

重要的一點是，只要叢集中存在超過一半的機器能夠正常工作，那麼整個叢集就能夠正常對外服務。

ZooKeeper 的客戶端程式會選擇和叢集中的任意一臺伺服器建立一個 TCP 連線，而且一旦客戶端和伺服器斷開連線，客戶端就會自動連線到叢集中的其他伺服器。

那麼如何執行 ZooKeeper 叢集模式呢？首先假如我們有三臺伺服器，IP 分別為 IP1、IP2 和 IP3，則需要執行以下步驟：

1. 準備 Java 執行環境（同上）

2. 下載 ZooKeeper 安裝包（同上）

3. 配置 zoo.cfg

4. 

可以看到，相比於單機模式，叢集模式多了 server.id=host:port1:port2 的配置。

其中，id 被稱為 Server ID，用來標識該機器在叢集中的機器序號（在每臺機器的 dataDir 目錄下建立 myid 檔案，檔案內容即為該機器對應的 Server ID 數字）。host 為機器 IP，port1 用於指定 Follower 伺服器與 Leader 伺服器進行通訊和資料同步的埠，port2 用於進行 Leader 選舉過程中的投票通訊。

1. 建立 myid 檔案 在 dataDir 目錄下建立名為 myid 的檔案，在檔案第一行寫上對應的 Server ID。

2. 按照相同步驟，為其他機器配置 zoo.cfg 和 myid檔案

3. 啟動服務

1.3 偽叢集模式

這是一種特殊的叢集模式，即叢集的所有伺服器都部署在一臺機器上。當你手頭上有一臺比較好的機器，如果作為單機模式進行部署，就會浪費資源，這種情況下，ZooKeeper允許你在一臺機器上通過啟動不同的埠來啟動多個 ZooKeeper 服務例項，以此來以叢集的特性來對外服務。

這種模式下，只需要把 zoo.cfg 做如下修改：

二、叢集組成

要搭建一個高可用的 ZooKeeper 叢集，我們首先需要確定好叢集的規模。

關於 ZooKeeper 叢集的伺服器組成，相信很多對 ZooKeeper 瞭解但是理解不夠深入的讀者，都存在或曾經存在過這樣一個錯誤的認識：為了使得 ZooKeeper 叢集能夠順利地選舉出 Leader，必須將 ZooKeeper 叢集的伺服器數部署成奇數。這裡我們需要澄清的一點是：任意臺 ZooKeeper 伺服器都能部署且能正常執行。

那麼存在於這麼多讀者中的這個錯誤認識是怎麼回事呢？其實關於 ZooKeeper 叢集伺服器數，ZooKeeper 官方確實給出了關於奇數的建議，但絕大部分 ZooKeeper 使用者對於這個建議認識有偏差。在本書前面提到的“過半存活即可用”特性中，我們已經瞭解了，一個 ZooKeeper 叢集如果要對外提供可用的服務，那麼叢集中必須要有過半的機器正常工作並且彼此之間能夠正常通訊。

基於這個特性，如果想搭建一個能夠允許 N 臺機器 down 掉的叢集，那麼就要部署一個由 2*N+1 臺伺服器構成的 ZooKeeper 叢集。因此，一個由 3 臺機器構成的 ZooKeeper 叢集，能夠在掛掉 1 臺機器後依然正常工作，而對於一個由 5 臺伺服器構成的 ZooKeeper 叢集，能夠對 2 臺機器掛掉的情況進行容災。注意，如果是一個由6臺伺服器構成的 ZooKeeper 叢集，同樣只能夠掛掉 2 臺機器，因為如果掛掉 3 臺，剩下的機器就無法實現過半了。

因此，從上面的講解中，我們其實可以看出，對於一個由 6 臺機器構成的 ZooKeeper 叢集來說，和一個由 5 臺機器構成的 ZooKeeper 叢集，其在容災能力上並沒有任何顯著的優勢，反而多佔用了一個伺服器資源。基於這個原因，ZooKeeper 叢集通常設計部署成奇數臺伺服器即可。

三、容災

所謂容災，在 IT 行業通常是指我們的計算機資訊系統具有的一種在遭受諸如火災、地震、斷電和其他基礎網路裝置故障等毀滅性災難的時候，依然能夠對外提供可用服務的能力。

對於一些普通的應用，為了達到容災標準，通常我們會選擇在多臺機器上進行部署來組成一個叢集，這樣即使在叢集的一臺或是若干臺機器出現故障的情況下，整個叢集依然能夠對外提供可用的服務。

而對於一些核心應用，不僅要通過使用多臺機器構建叢集的方式來提供服務，而且還要將叢集中的機器部署在兩個機房，這樣的話，即使其中一個機房遭遇災難，依然能夠對外提供可用的服務。

上面講到的都是應用層面的容災模式，那麼對於 ZooKeeper 這種底層元件來說，如何進行容災呢？講到這裡，可能多少讀者會有疑問，ZooKeeper 既然已經解決了單點問題，那為什麼還要進行容災呢？

3.1 單點問題

單點問題是分散式環境中最常見也是最經典的問題之一，在很多分散式系統中都會存在這樣的單點問題。

具體地說，單點問題是指在一個分散式系統中，如果某一個元件出現故障就會引起整個系統的可用性大大下降甚至是處於癱瘓狀態，那麼我們就認為該元件存在單點問題。

ZooKeeper 確實已經很好地解決了單點問題。我們已經瞭解到，基於“過半”設計原則，ZooKeeper 在執行期間，叢集中至少有過半的機器儲存了最新的資料。因此，只要叢集中超過半數的機器還能夠正常工作，整個叢集就能夠對外提供服務。

3.2 容災

解決了單點問題，是不是該考慮容災了呢？答案是否定的，在搭建一個高可用的叢集的時候依然需要考慮容災問題。正如上面講到的，如果叢集中超過半數的機器還在正常工作，叢集就能夠對外提供正常的服務。

那麼，如果整個機房出現災難性的事故，這時顯然已經不是單點問題的範疇了。

在進行 ZooKeeper 的容災方案設計過程中，我們要充分考慮到“過半原則”。也就是說，無論發生什麼情況，我們必須保證 ZooKeeper 叢集中有超過半數的機器能夠正常工作。因此，通常有以下兩種部署方案。

3.3.1 雙機房部署

在進行容災方案的設計時，我們通常是以機房為單位來考慮問題。在現實中，很多公司的機房規模並不大，因此雙機房部署是個比較常見的方案。但是遺憾的是，在目前版本的 ZooKeeper 中，還沒有辦法能夠在雙機房條件下實現比較好的容災效果——因為無論哪個機房發生異常情況，都有可能使得 ZooKeeper 叢集中可用的機器無法超過半數。

當然，在擁有兩個機房的場景下，通常有一個機房是主要機房（一般而言，公司會花費更多的錢去租用一個穩定性更好、裝置更可靠的機房，這個機房就是主要機房，而另外一個機房則更加廉價一些）。我們唯一能做的，就是儘量在主要機房部署更多的機器。例如，對於一個由 7 臺機器組成的 ZooKeeper 叢集，通常在主要機房中部署 4 臺機器，剩下的 3 臺機器部署到另外一個機房中。

3.3.2 三機房部署

既然在雙機房部署模式下並不能實現好的容災效果，那麼對於有條件的公司，選擇三機房部署無疑是個更好的選擇，無論哪個機房發生了故障，剩下兩個機房的機器數量都超過半數。假如我們有三個機房可以部署服務，並且這三個機房間的網路狀況良好，那麼就可以在三個機房中都部署若干個機器來組成一個 ZooKeeper 叢集。

我們假定構成 ZooKeeper 叢集的機器總數為 N，在三個機房中部署的 ZooKeeper 伺服器數分別為 N1、N2 和 N3，如果要使該 ZooKeeper 叢集具有較好的容災能力，我們可以根據如下演算法來計算 ZooKeeper 叢集的機器部署方案。

1、計算 N1 如果 ZooKeeper 叢集的伺服器總數是 N，那麼：

N1 = (N-1)/2

在 Java 中，“/” 運算子會自動對計算結果向下取整操作。舉個例子，如果 N=8，那麼 N1=3；如果 N=7，那麼 N1 也等於 3。

2、計算 N2 的可選值 N2 的計算規則和 N1 非常類似，只是 N2 的取值是在一個取值範圍內：

N2 的取值範圍是 1~(N-N1)/2

即如果 N=8，那麼 N1=3，則 N2 的取值範圍就是 1~2，分別是 1 和 2。注意，1 和 2 僅僅是 N2 的可選值，並非最終值——如果 N2 為某個可選值的時候，無法計算出 N3 的值，那麼該可選值也無效。

3、計算 N3，同時確定 N2 的值 很顯然，現在只剩下 N3 了，可以簡單的認為 N3 的取值就是剩下的機器數，即：

N3 = N - N1 - N2

只是 N3 的取值必須滿足 N3 < N1+N2。在滿足這個條件的基礎下，我們遍歷步驟 2 中計算得到的 N2 的可選值，即可得到三機房部署時每個機房的伺服器數量了。

現在我們以 7 臺機器為例，來看看如何分配三機房的機器分佈。根據演算法的步驟 1，我們首先確定 N1 的取值為 3。根據演算法的步驟 2，我們確定了 N2 的可選值為 1 和 2。最後根據步驟 3，我們遍歷 N2 的可選值，即可得到兩種部署方案，分別是 (3,1,3) 和 (3,2,2)。以下是 Java 程式程式碼對以上演算法的一種簡單實現：

四、水平擴容

水平可擴容可以說是對一個分散式系統在高可用性方面提出的基本的，也是非常重要的一個要求，通過水平擴容能夠幫助系統在不進行或進行極少改進工作的前提下，快速提高系統對外的服務支撐能力。簡單地講，水平擴容就是向叢集中新增更多的機器，以提高系統的服務質量。

很遺憾的是，ZooKeeper 在水平擴容擴容方面做得並不十分完美，需要進行整個叢集的重啟。通常有兩種重啟方式，一種是叢集整體重啟，另外一種是逐臺進行伺服器的重啟。

4.1 整體重啟

所謂叢集整體重啟，就是先將整個叢集停止，然後更新 ZooKeeper 的配置，然後再次啟動。如果在你的系統中，ZooKeeper 並不是個非常核心的元件，並且能夠允許短暫的服務停止（通常是幾秒鐘的時間間隔），那麼不妨選擇這種方式。在整體重啟的過程中，所有該叢集的客戶端都無法連線上叢集。等到叢集再次啟動，這些客戶端就能夠自動連線上——注意，整體啟動前建立起的客戶端會話，並不會因為此次整體重啟而失效。也就是說，在整體重啟期間花費的時間將不計入會話超時時間的計算中。

4.2 逐臺重啟

這種方式更適合絕大多數的實際場景。在這種方式中，每次僅僅重啟叢集中的一臺機器，然後逐臺對整個叢集中的機器進行重啟操作。這種方式可以在重啟期間依然保證叢集對外的正常服務。