如何構(gòu)建高可用ZooKeeper集群

2017-02-06 11:43:57

本文的目標(biāo)讀者是對(duì) ZooKeeper 有一定了解的技術(shù)人員，將從 ZooKeeper 運(yùn)行模式、集群組成、容災(zāi)和水平擴(kuò)容四方面逐步深入，最終構(gòu)建出高可用的 ZooKeeper 集群。

ZooKeeper 是 Apache 的一個(gè)***項(xiàng)目，為分布式應(yīng)用提供高效、高可用的分布式協(xié)調(diào)服務(wù)，提供了諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知和分布式鎖等分布式基礎(chǔ)服務(wù)。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的穩(wěn)定性，被廣泛地應(yīng)用于諸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系統(tǒng)中。

本文的目標(biāo)讀者是對(duì) ZooKeeper 有一定了解的技術(shù)人員，將從 ZooKeeper 運(yùn)行模式、集群組成、容災(zāi)和水平擴(kuò)容四方面逐步深入，最終構(gòu)建出高可用的 ZooKeeper 集群。

一、運(yùn)行模式

Zookeeper 有三種運(yùn)行模式：?jiǎn)螜C(jī)模式、偽集群模式和集群模式。

1.1 單機(jī)模式

這種模式一般適用于開發(fā)測(cè)試環(huán)境，一方面我們沒有那么多機(jī)器資源，另外就是平時(shí)的開發(fā)調(diào)試并不需要極好的穩(wěn)定性。

在 Linux 環(huán)境下運(yùn)行單機(jī)模式需要執(zhí)行以下步驟：

1. 準(zhǔn)備 Java 運(yùn)行環(huán)境

安裝 Java 1.6 或更高版本的 JDK，并配置好 Java 相關(guān)的環(huán)境變量 $JAVA_HOME 。

2. 下載 ZooKeeper 安裝包

下載地址：http://zookeeper.apache.org/releases.html。選擇***的 stable 版本并解壓到指定目錄，我們用 $ZK_HOME 表示該目錄。

3. 配置 zoo.cfg

***使用 ZooKeeper，需要將 $ZK_HOME 下的 zoo_sample.cfg 文件重命名為 zoo.cfg，并進(jìn)行以下配置

tickTime=2000    ##Zookeeper最小時(shí)間單元，單位毫秒(ms)，默認(rèn)值為3000 
dataDir=/var/lib/zookeeper    ##Zookeeper服務(wù)器存儲(chǔ)快照文件的目錄，必須配置 
dataLogDir=/var/lib/log     ##Zookeeper服務(wù)器存儲(chǔ)事務(wù)日志的目錄，默認(rèn)為dataDir 
clientPort=2181    ##服務(wù)器對(duì)外服務(wù)端口，一般設(shè)置為2181 
initLimit=5    ##Leader服務(wù)器等待Follower啟動(dòng)并完成數(shù)據(jù)同步的時(shí)間，默認(rèn)值10，表示tickTime的10倍 
syncLimit=2    ##Leader服務(wù)器和Follower之間進(jìn)行心跳檢測(cè)的***延時(shí)時(shí)間，默認(rèn)值5，表示tickTime的5倍

4. 啟動(dòng)服務(wù)

使用 $ZK_HOME/bin 目錄下的 zkServer.sh 腳本進(jìn)行服務(wù)的啟動(dòng)。

1.2 集群模式

一個(gè) ZooKeeper 集群通常由一組機(jī)器組成，一般 3 臺(tái)以上就可以組成一個(gè)可用的 ZooKeeper 集群了。

組成 ZooKeeper 集群的每臺(tái)機(jī)器都會(huì)在內(nèi)存中維護(hù)當(dāng)前的服務(wù)器狀態(tài)，并且每臺(tái)機(jī)器之間都會(huì)互相保持通信。

重要的一點(diǎn)是，只要集群中存在超過一半的機(jī)器能夠正常工作，那么整個(gè)集群就能夠正常對(duì)外服務(wù)。

ZooKeeper 的客戶端程序會(huì)選擇和集群中的任意一臺(tái)服務(wù)器創(chuàng)建一個(gè) TCP 連接，而且一旦客戶端和服務(wù)器斷開連接，客戶端就會(huì)自動(dòng)連接到集群中的其他服務(wù)器。

那么如何運(yùn)行 ZooKeeper 集群模式呢？首先假如我們有三臺(tái)服務(wù)器，IP 分別為 IP₁、IP₂ 和 IP₃，則需要執(zhí)行以下步驟：

1. 準(zhǔn)備 Java 運(yùn)行環(huán)境（同上）

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

3. 配置 zoo.cfg

tickTime=2000 
dataDir=/var/lib/zookeeper 
dataLogDir=/var/lib/log 
clientPort=2181 
initLimit=5 
syncLimit=2 
server.1=IP1:2888:3888 
server.2=IP2:2888:3888 
server.3=IP3:2888:3888

可以看到，相比于單機(jī)模式，集群模式多了 server.id=host:port₁:port₂ 的配置。

其中，id 被稱為 Server ID，用來標(biāo)識(shí)該機(jī)器在集群中的機(jī)器序號(hào)（在每臺(tái)機(jī)器的 dataDir 目錄下創(chuàng)建 myid 文件，文件內(nèi)容即為該機(jī)器對(duì)應(yīng)的 Server ID 數(shù)字）。host 為機(jī)器 IP，port₁ 用于指定 Follower 服務(wù)器與 Leader 服務(wù)器進(jìn)行通信和數(shù)據(jù)同步的端口，port₂用于進(jìn)行 Leader 選舉過程中的投票通信。

4. 創(chuàng)建 myid 文件

在 dataDir 目錄下創(chuàng)建名為 myid 的文件，在文件***行寫上對(duì)應(yīng)的 Server ID。

5. 按照相同步驟，為其他機(jī)器配置 zoo.cfg 和 myid文件

6. 啟動(dòng)服務(wù)

1.3 偽集群模式

這是一種特殊的集群模式，即集群的所有服務(wù)器都部署在一臺(tái)機(jī)器上。當(dāng)你手頭上有一臺(tái)比較好的機(jī)器，如果作為單機(jī)模式進(jìn)行部署，就會(huì)浪費(fèi)資源，這種情況下，ZooKeeper允許你在一臺(tái)機(jī)器上通過啟動(dòng)不同的端口來啟動(dòng)多個(gè) ZooKeeper 服務(wù)實(shí)例，以此來以集群的特性來對(duì)外服務(wù)。

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

tickTime=2000 
dataDir=/var/lib/zookeeper 
dataLogDir=/var/lib/log 
clientPort=2181 
initLimit=5 
syncLimit=2 
server.1=IP1:2888:3888 
server.2=IP1:2889:3889 
server.3=IP1:2890:3890

二、集群組成

要搭建一個(gè)高可用的 ZooKeeper 集群，我們首先需要確定好集群的規(guī)模。

關(guān)于 ZooKeeper 集群的服務(wù)器組成，相信很多對(duì) ZooKeeper 了解但是理解不夠深入的讀者，都存在或曾經(jīng)存在過這樣一個(gè)錯(cuò)誤的認(rèn)識(shí)：為了使得 ZooKeeper 集群能夠順利地選舉出 Leader，必須將 ZooKeeper 集群的服務(wù)器數(shù)部署成奇數(shù)。這里我們需要澄清的一點(diǎn)是：任意臺(tái) ZooKeeper 服務(wù)器都能部署且能正常運(yùn)行。

那么存在于這么多讀者中的這個(gè)錯(cuò)誤認(rèn)識(shí)是怎么回事呢？其實(shí)關(guān)于 ZooKeeper 集群服務(wù)器數(shù)，ZooKeeper 官方確實(shí)給出了關(guān)于奇數(shù)的建議，但絕大部分 ZooKeeper 用戶對(duì)于這個(gè)建議認(rèn)識(shí)有偏差。在本書前面提到的“過半存活即可用”特性中，我們已經(jīng)了解了，一個(gè) ZooKeeper 集群如果要對(duì)外提供可用的服務(wù)，那么集群中必須要有過半的機(jī)器正常工作并且彼此之間能夠正常通信。基于這個(gè)特性，如果想搭建一個(gè)能夠允許 N 臺(tái)機(jī)器 down 掉的集群，那么就要部署一個(gè)由 2*N+1 臺(tái)服務(wù)器構(gòu)成的 ZooKeeper 集群。因此，一個(gè)由 3 臺(tái)機(jī)器構(gòu)成的 ZooKeeper 集群，能夠在掛掉 1 臺(tái)機(jī)器后依然正常工作，而對(duì)于一個(gè)由 5 臺(tái)服務(wù)器構(gòu)成的 ZooKeeper 集群，能夠?qū)?2 臺(tái)機(jī)器掛掉的情況進(jìn)行容災(zāi)。注意，如果是一個(gè)由6臺(tái)服務(wù)器構(gòu)成的 ZooKeeper 集群，同樣只能夠掛掉 2 臺(tái)機(jī)器，因?yàn)槿绻麙斓?3 臺(tái)，剩下的機(jī)器就無法實(shí)現(xiàn)過半了。

因此，從上面的講解中，我們其實(shí)可以看出，對(duì)于一個(gè)由 6 臺(tái)機(jī)器構(gòu)成的 ZooKeeper 集群來說，和一個(gè)由 5 臺(tái)機(jī)器構(gòu)成的 ZooKeeper 集群，其在容災(zāi)能力上并沒有任何顯著的優(yōu)勢(shì)，反而多占用了一個(gè)服務(wù)器資源。基于這個(gè)原因，ZooKeeper 集群通常設(shè)計(jì)部署成奇數(shù)臺(tái)服務(wù)器即可。

三、容災(zāi)

所謂容災(zāi)，在 IT 行業(yè)通常是指我們的計(jì)算機(jī)信息系統(tǒng)具有的一種在遭受諸如火災(zāi)、地震、斷電和其他基礎(chǔ)網(wǎng)絡(luò)設(shè)備故障等毀滅性災(zāi)難的時(shí)候，依然能夠?qū)ν馓峁┛捎梅?wù)的能力。

對(duì)于一些普通的應(yīng)用，為了達(dá)到容災(zāi)標(biāo)準(zhǔn)，通常我們會(huì)選擇在多臺(tái)機(jī)器上進(jìn)行部署來組成一個(gè)集群，這樣即使在集群的一臺(tái)或是若干臺(tái)機(jī)器出現(xiàn)故障的情況下，整個(gè)集群依然能夠?qū)ν馓峁┛捎玫姆?wù)。

而對(duì)于一些核心應(yīng)用，不僅要通過使用多臺(tái)機(jī)器構(gòu)建集群的方式來提供服務(wù)，而且還要將集群中的機(jī)器部署在兩個(gè)機(jī)房，這樣的話，即使其中一個(gè)機(jī)房遭遇災(zāi)難，依然能夠?qū)ν馓峁┛捎玫姆?wù)。

上面講到的都是應(yīng)用層面的容災(zāi)模式，那么對(duì)于 ZooKeeper 這種底層組件來說，如何進(jìn)行容災(zāi)呢？講到這里，可能多少讀者會(huì)有疑問，ZooKeeper 既然已經(jīng)解決了單點(diǎn)問題，那為什么還要進(jìn)行容災(zāi)呢？

3.1 單點(diǎn)問題

單點(diǎn)問題是分布式環(huán)境中最常見也是最經(jīng)典的問題之一，在很多分布式系統(tǒng)中都會(huì)存在這樣的單點(diǎn)問題。

具體地說，單點(diǎn)問題是指在一個(gè)分布式系統(tǒng)中，如果某一個(gè)組件出現(xiàn)故障就會(huì)引起整個(gè)系統(tǒng)的可用性大大下降甚至是處于癱瘓狀態(tài)，那么我們就認(rèn)為該組件存在單點(diǎn)問題。

ZooKeeper 確實(shí)已經(jīng)很好地解決了單點(diǎn)問題。我們已經(jīng)了解到，基于“過半”設(shè)計(jì)原則，ZooKeeper 在運(yùn)行期間，集群中至少有過半的機(jī)器保存了***的數(shù)據(jù)。因此，只要集群中超過半數(shù)的機(jī)器還能夠正常工作，整個(gè)集群就能夠?qū)ν馓峁┓?wù)。

3.2 容災(zāi)

解決了單點(diǎn)問題，是不是該考慮容災(zāi)了呢？答案是否定的，在搭建一個(gè)高可用的集群的時(shí)候依然需要考慮容災(zāi)問題。正如上面講到的，如果集群中超過半數(shù)的機(jī)器還在正常工作，集群就能夠?qū)ν馓峁┱５姆?wù)。

那么，如果整個(gè)機(jī)房出現(xiàn)災(zāi)難性的事故，這時(shí)顯然已經(jīng)不是單點(diǎn)問題的范疇了。

在進(jìn)行 ZooKeeper 的容災(zāi)方案設(shè)計(jì)過程中，我們要充分考慮到“過半原則”。也就是說，無論發(fā)生什么情況，我們必須保證 ZooKeeper 集群中有超過半數(shù)的機(jī)器能夠正常工作。因此，通常有以下兩種部署方案。

3.3.1 雙機(jī)房部署

在進(jìn)行容災(zāi)方案的設(shè)計(jì)時(shí)，我們通常是以機(jī)房為單位來考慮問題。在現(xiàn)實(shí)中，很多公司的機(jī)房規(guī)模并不大，因此雙機(jī)房部署是個(gè)比較常見的方案。但是遺憾的是，在目前版本的 ZooKeeper 中，還沒有辦法能夠在雙機(jī)房條件下實(shí)現(xiàn)比較好的容災(zāi)效果——因?yàn)闊o論哪個(gè)機(jī)房發(fā)生異常情況，都有可能使得 ZooKeeper 集群中可用的機(jī)器無法超過半數(shù)。當(dāng)然，在擁有兩個(gè)機(jī)房的場(chǎng)景下，通常有一個(gè)機(jī)房是主要機(jī)房（一般而言，公司會(huì)花費(fèi)更多的錢去租用一個(gè)穩(wěn)定性更好、設(shè)備更可靠的機(jī)房，這個(gè)機(jī)房就是主要機(jī)房，而另外一個(gè)機(jī)房則更加廉價(jià)一些）。我們唯一能做的，就是盡量在主要機(jī)房部署更多的機(jī)器。例如，對(duì)于一個(gè)由 7 臺(tái)機(jī)器組成的 ZooKeeper 集群，通常在主要機(jī)房中部署 4 臺(tái)機(jī)器，剩下的 3 臺(tái)機(jī)器部署到另外一個(gè)機(jī)房中。

3.3.2 三機(jī)房部署

既然在雙機(jī)房部署模式下并不能實(shí)現(xiàn)好的容災(zāi)效果，那么對(duì)于有條件的公司，選擇三機(jī)房部署無疑是個(gè)更好的選擇，無論哪個(gè)機(jī)房發(fā)生了故障，剩下兩個(gè)機(jī)房的機(jī)器數(shù)量都超過半數(shù)。假如我們有三個(gè)機(jī)房可以部署服務(wù)，并且這三個(gè)機(jī)房間的網(wǎng)絡(luò)狀況良好，那么就可以在三個(gè)機(jī)房中都部署若干個(gè)機(jī)器來組成一個(gè) ZooKeeper 集群。

我們假定構(gòu)成 ZooKeeper 集群的機(jī)器總數(shù)為 N，在三個(gè)機(jī)房中部署的 ZooKeeper 服務(wù)器數(shù)分別為 N₁、N₂ 和 N₃，如果要使該 ZooKeeper 集群具有較好的容災(zāi)能力，我們可以根據(jù)如下算法來計(jì)算 ZooKeeper 集群的機(jī)器部署方案。

1. 計(jì)算 N₁

如果 ZooKeeper 集群的服務(wù)器總數(shù)是 N，那么：

N1 = (N-1)/2

在 Java 中，“/” 運(yùn)算符會(huì)自動(dòng)對(duì)計(jì)算結(jié)果向下取整操作。舉個(gè)例子，如果 N=8，那么 N₁=3；如果 N=7，那么 N₁ 也等于 3。

2. 計(jì)算 N₂ 的可選值

N₂ 的計(jì)算規(guī)則和 N₁ 非常類似，只是 N₂的取值是在一個(gè)取值范圍內(nèi)：

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

即如果 N=8，那么 N₁=3，則 N₂ 的取值范圍就是 1~2，分別是 1 和 2。注意，1 和 2 僅僅是 N₂ 的可選值，并非最終值——如果 N₂為某個(gè)可選值的時(shí)候，無法計(jì)算出 N₃ 的值，那么該可選值也無效。

3. 計(jì)算 N₃，同時(shí)確定 N₂ 的值

很顯然，現(xiàn)在只剩下 N₃ 了，可以簡(jiǎn)單的認(rèn)為 N₃ 的取值就是剩下的機(jī)器數(shù)，即：

N3 = N - N1 - N2

只是 N₃ 的取值必須滿足 N₃ < N₁+N2。在滿足這個(gè)條件的基礎(chǔ)下，我們遍歷步驟 2 中計(jì)算得到的 N₂ 的可選值，即可得到三機(jī)房部署時(shí)每個(gè)機(jī)房的服務(wù)器數(shù)量了。

現(xiàn)在我們以 7 臺(tái)機(jī)器為例，來看看如何分配三機(jī)房的機(jī)器分布。根據(jù)算法的步驟 1，我們首先確定 N₁ 的取值為 3。根據(jù)算法的步驟 2，我們確定了 N₂ 的可選值為 1 和 2。***根據(jù)步驟 3，我們遍歷 N₂ 的可選值，即可得到兩種部署方案，分別是 (3,1,3) 和 (3,2,2)。以下是 Java 程序代碼對(duì)以上算法的一種簡(jiǎn)單實(shí)現(xiàn)：

public class Allocation { 
  
    static final int n = 7; 
    public static void main(String[] args){ 
        int n1,n2,n3; 
        n1 = (n-1) / 2; 
        int n2_max = (n-n1) / 2; 
        for(int i=1; i<=n2_max; i++){ 
            n2 = i; 
            n3 = n - n1 -n2; 
            if(n3 >= (n1+n2)){ 
                continue; 
            } 
            System.out.println("("+n1+","+n2+","+n3+")"); 
        } 
    } 
}

四、水平擴(kuò)容

水平可擴(kuò)容可以說是對(duì)一個(gè)分布式系統(tǒng)在高可用性方面提出的基本的，也是非常重要的一個(gè)要求，通過水平擴(kuò)容能夠幫助系統(tǒng)在不進(jìn)行或進(jìn)行極少改進(jìn)工作的前提下，快速提高系統(tǒng)對(duì)外的服務(wù)支撐能力。簡(jiǎn)單地講，水平擴(kuò)容就是向集群中添加更多的機(jī)器，以提高系統(tǒng)的服務(wù)質(zhì)量。

很遺憾的是，ZooKeeper 在水平擴(kuò)容擴(kuò)容方面做得并不十分***，需要進(jìn)行整個(gè)集群的重啟。通常有兩種重啟方式，一種是集群整體重啟，另外一種是逐臺(tái)進(jìn)行服務(wù)器的重啟。

4.1 整體重啟

所謂集群整體重啟，就是先將整個(gè)集群停止，然后更新 ZooKeeper 的配置，然后再次啟動(dòng)。如果在你的系統(tǒng)中，ZooKeeper 并不是個(gè)非常核心的組件，并且能夠允許短暫的服務(wù)停止（通常是幾秒鐘的時(shí)間間隔），那么不妨選擇這種方式。在整體重啟的過程中，所有該集群的客戶端都無法連接上集群。等到集群再次啟動(dòng)，這些客戶端就能夠自動(dòng)連接上——注意，整體啟動(dòng)前建立起的客戶端會(huì)話，并不會(huì)因?yàn)榇舜握w重啟而失效。也就是說，在整體重啟期間花費(fèi)的時(shí)間將不計(jì)入會(huì)話超時(shí)時(shí)間的計(jì)算中。