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

2017-02-06 11:43:57

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

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

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

一、運行模式

Zookeeper 有三種運行模式：單機模式、偽集群模式和集群模式。

1.1 單機模式

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

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

1. 準備 Java 運行環(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，并進行以下配置

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

4. 啟動服務(wù)

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

1.2 集群模式

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

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

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

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

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

1. 準備 Java 運行環(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

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

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

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

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

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

6. 啟動服務(wù)

1.3 偽集群模式

這是一種特殊的集群模式，即集群的所有服務(wù)器都部署在一臺機器上。當(dāng)你手頭上有一臺比較好的機器，如果作為單機模式進行部署，就會浪費資源，這種情況下，ZooKeeper允許你在一臺機器上通過啟動不同的端口來啟動多個 ZooKeeper 服務(wù)實例，以此來以集群的特性來對外服務(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

二、集群組成

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

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

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

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

三、容災(zāi)

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

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

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

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

3.1 單點問題

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

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

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

3.2 容災(zāi)

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

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

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

3.3.1 雙機房部署

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

3.3.2 三機房部署

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

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

1. 計算 N₁

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

N1 = (N-1)/2

在 Java 中，“/” 運算符會自動對計算結(jié)果向下取整操作。舉個例子，如果 N=8，那么 N₁=3；如果 N=7，那么 N₁ 也等于 3。

2. 計算 N₂ 的可選值

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

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

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

3. 計算 N₃，同時確定 N₂ 的值

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

N3 = N - N1 - N2

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

現(xiàn)在我們以 7 臺機器為例，來看看如何分配三機房的機器分布。根據(jù)算法的步驟 1，我們首先確定 N₁ 的取值為 3。根據(jù)算法的步驟 2，我們確定了 N₂ 的可選值為 1 和 2。***根據(jù)步驟 3，我們遍歷 N₂ 的可選值，即可得到兩種部署方案，分別是 (3,1,3) 和 (3,2,2)。以下是 Java 程序代碼對以上算法的一種簡單實現(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+")"); 
        } 
    } 
}

四、水平擴容

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

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

4.1 整體重啟

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

4.2 逐臺重啟

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

責(zé)任編輯：王雪燕來源： cyfonly

ZooKeeper 集群

成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

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

一、運行模式

1.1 單機模式

1. 準備 Java 運行環(huán)境

2. 下載 ZooKeeper 安裝包

3. 配置 zoo.cfg

1.2 集群模式

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

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

3. 配置 zoo.cfg

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

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

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

6. 啟動服務(wù)

1.3 偽集群模式

三、容災(zāi)

3.1 單點問題

3.2 容災(zāi)

3.3.1 雙機房部署

3.3.2 三機房部署

1. 計算 N1

2. 計算 N2 的可選值

3. 計算 N3，同時確定 N2 的值

四、水平擴容

4.1 整體重啟

4.2 逐臺重啟

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

1. 計算 N₁

2. 計算 N₂ 的可選值

3. 計算 N₃，同時確定 N₂ 的值