一、ZooKeeper 基本概念

1、ZooKeeper 是什么？

Zookeeper官網地址： zookeeper.apache.org/

Zookeeper官網文檔地址：zookeeper.apache.org/doc/trunk/i…

ZooKeeper 是Hadoop下的一個子項目，它是一個針對大型分布式系統的可靠協調系統；它提供的功能包括：配置維護、名字服務、分布式同步、組服務等； 它的目標就是封裝好復雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

Zookeeper一個最常用的使用場景就是用于擔任服務生產者和服務消費者的注冊中心，服務生產者將自己提供的服務注冊到Zookeeper中心，服務的消費者在進行服務調用的時候先到Zookeeper中查找服務，獲取到服務生產者的詳細信息之后，再去調用服務生產者的內容與數據，簡單示例圖如下：

2、ZooKeeper設計目標：

ZooKeeper允許分布式進程通過共享的層次結構命名空間進行相互協調，這與標準文件系統類似。 名稱空間由ZooKeeper中的數據寄存器組成 - 稱為znode，這些類似于文件和目錄。 與為存儲設計的典型文件系統不同，ZooKeeper數據保存在內存中，這意味著ZooKeeper可以實現高吞吐量和低延遲。

Zookeeper層次結構命名空間示意圖如下：

通過這種樹圖結構的數據模型，很容易的查找到具體的某一個服務。

3、ZooKeeper主要特點：

1)、最終一致性：為客戶端展示同一視圖，這是 ZooKeeper 最重要的性能。 2)、可靠性：如果消息被一臺服務器接受，那么它將被所有的服務器接受。 3)、實時性：ZooKeeper 不能保證兩個客戶端同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。 4)、等待無關（wait-free）：慢的或者失效的 client 不干預快速的client的請求。 5)、原子性：更新只能成功或者失敗，沒有中間其它狀態。 6)、順序性：對于所有Server，同一消息發布順序一致。 復制代碼

二、ZooKeeper 基本原理

1、ZooKeeper 系統架構

首先看一下 ZooKeeper 的架構圖。

ZooKeeper 的架構圖中我們需要了解和掌握的主要有：

（1）ZooKeeper分為***服務器端（Server）*** 和***客戶端（Client）***，客戶端可以連接到整個 ZooKeeper服務的任意服務器上（除非 leaderServes 參數被顯式設置， leader 不允許接受客戶端連接）。

（2）客戶端使用并維護一個 TCP 連接，通過這個連接發送請求、接受響應、獲取觀察的事件以及發送心跳。如果這個 TCP 連接中斷，客戶端將自動嘗試連接到另外的 ZooKeeper服務器。客戶端第一次連接到 ZooKeeper服務時，接受這個連接的 ZooKeeper服務器會為這個客戶端建立一個會話。當這個客戶端連接到另外的服務器時，這個會話會被新的服務器重新建立。

（3）上圖中每一個Server代表一個安裝Zookeeper服務的機器，即是整個提供Zookeeper服務的集群（或者是由偽集群組成）；

（4）組成ZooKeeper服務的服務器必須彼此了解。 它們維護一個內存中的狀態圖像，以及持久存儲中的事務日志和快照， 只要大多數服務器可用，ZooKeeper服務就可用；

（5）ZooKeeper 啟動時，將從實例中選舉一個 leader，Leader 負責處理數據更新等操作，一個更新操作成功的標志是當且僅當大多數Server在內存中成功修改數據。每個Server 在內存中存儲了一份數據。

（6）Zookeeper是可以集群復制的，集群間通過Zab協議（Zookeeper Atomic Broadcast）來保持數據的一致性；

（7）Zab協議包含兩個階段：leader election階段***和***Atomic Brodcast階段。

• a) 集群中將選舉出一個leader，其他的機器則稱為follower，所有的寫操作都被傳送給leader，并通過brodcast將所有的更新告訴給follower。
• b) 當leader崩潰或者leader失去大多數的follower時，需要重新選舉出一個新的leader，讓所有的服務器都恢復到一個正確的狀態。
• c) 當leader被選舉出來，且大多數服務器完成了 和leader的狀態同步后，leadder election 的過程就結束了，就將會進入到Atomic brodcast的過程。
• d) Atomic Brodcast同步leader和follower之間的信息，保證leader和follower具有形同的系統狀態。

2、Zookeeper 角色

啟動 Zookeeper 服務器集群環境后，多個 Zookeeper 服務器在工作前會選舉出一個 Leader。選舉出 leader 前，所有 server 不區分角色，都需要平等參與投票（ obServer 除外，不參與投票）；

選主過程完成后，存在以下幾種角色：

思考：

1、為什么需要server?

①ZooKeeper 需保證高可用和強一致性; ②為了支持更多的客戶端，需要增加更多的Server; ③Follower增多會導致投票階段延遲增大，影響性能。 復制代碼

２、在Zookeeper 中ObServer 起到什么作用？

①ObServer 不參與投票過程，只同步 leader的狀態 ; ②Observers 接受客戶端的連接，并將寫請求轉發給 leader節點 ; ③加入更多ObServer 節點，提高伸縮性，同時還不影響吞吐率。 復制代碼

３、為什么在Zookeeper中Server 數目一般為奇數？

我們知道在Zookeeper中 Leader 選舉算法采用了Paxos協議。Paxos核心思想是當多數 Server 寫成功，則任務數據寫成功。 ①如果有3個Server，則最多允許1個Server 掛掉。 ②如果有4個Server，則同樣最多允許1個Server掛掉。 既然3個或者4個Server，同樣最多允許1個Server掛掉，那么它們的可靠性是一樣的，所以選擇奇數個ZooKeeper Server即可，這里選擇3個Server。 復制代碼

3、ZooKeeper 寫數據流程

ZooKeeper 寫數據的流程圖如下所示。

ZooKeeper 的寫數據流程主要分為以下幾步：

• a)、比如 Client 向 ZooKeeper 的 Server1 上寫數據，發送一個寫請求。

• b)、如果Server1不是Leader，那么Server1 會把接受到的請求進一步轉發給Leader，因為每個ZooKeeper的Server里面有一個是Leader。這個Leader 會將寫請求廣播給各個Server，比如Server1和Server2， 各個Server寫成功后就會通知Leader。

• c)、當Leader收到大多數 Server 數據寫成功了，那么就說明數據寫成功了。如果這里三個節點的話，只要有兩個節點數據寫成功了，那么就認為數據寫成功了。寫成功之后，Leader會告訴Server1數據寫成功了。

• d)、Server1會進一步通知 Client 數據寫成功了，這時就認為整個寫操作成功。

4、ZooKeeper 組件

ZooKeeper組件顯示了ZooKeeper服務的高級組件。 除了請求處理器，組成ZooKeeper服務的每個服務器復制其自己的每個組件的副本。

Replicated Database是包含整個數據樹的內存數據庫。 更新操作會記錄到磁盤里以進行可恢復性，并且寫操作將在放到內存數據庫之前序列化到磁盤。

每個ZooKeeper服務器服務客戶端。 客戶端連接到一個服務器以提交irequest。 讀取請求從每個服務器數據庫的本地副本服務。 更改服務狀態（寫入請求）的請求由協議進行處理。

作為協議協議的一部分，來自客戶端的所有寫請求被轉發到單個服務器，稱為leader。 其余的ZooKeeper服務器（稱為followers）從領導者接收消息提議并同意消息傳遞。 消息層負責在失敗時替換領導者，并與leader同步followers。

三、ZooKeeper 應用場景總結

1、統一命名服務

統一命名服務的命名結構圖如下所示：

? 1、在分布式環境下，經常需要對應用/服務進行統一命名，便于識別不同服務。 ? a）類似于域名與ip之間對應關系，ip不容易記住，而域名容易記住。 ? b）通過名稱來獲取資源或服務的地址，提供者等信息。 ? 2、按照層次結構組織服務/應用名稱。 ? a）可將服務名稱以及地址信息寫到ZooKeeper上，客戶端通過ZooKeeper獲取可用服務列表類。

2、配置管理

配置管理結構圖如下所示：

1、分布式環境下，配置文件管理和同步是一個常見問題。 ? a）一個集群中，所有節點的配置信息是一致的，比如 Hadoop 集群。 ? b）對配置文件修改后，希望能夠快速同步到各個節點上。 ?? 2、配置管理可交由ZooKeeper實現。 ? a）可將配置信息寫入ZooKeeper上的一個Znode。 ? b）各個節點監聽這個Znode。 ? c）一旦Znode中的數據被修改，ZooKeeper將通知各個節點。

3、集群管理

集群管理結構圖如下所示：

1、分布式環境中，實時掌握每個節點的狀態是必要的。 ??a）可根據節點實時狀態做出一些調整。 ?? 2、可交由ZooKeeper實現。 ??a）可將節點信息寫入ZooKeeper上的一個Znode。 ??b）監聽這個Znode可獲取它的實時狀態變化。 ?? 3、典型應用 ??a）HBase中Master狀態監控與選舉。

4、分布式通知與協調

1、分布式環境中，經常存在一個服務需要知道它所管理的子服務的狀態。 ??a）NameNode需知道各個Datanode的狀態。 ??b）JobTracker需知道各個TaskTracker的狀態。 ?? 2、心跳檢測機制可通過ZooKeeper來實現。

3、信息推送可由ZooKeeper來實現，ZooKeeper相當于一個發布/訂閱系統。

5、分布式鎖

處于不同節點上不同的服務，它們可能需要順序的訪問一些資源，這里需要一把分布式的鎖。

分布式鎖具有以下特性：

1、ZooKeeper是強一致的。比如各個節點上運行一個ZooKeeper客戶端，它們同時創建相同的Znode，但是只有一個客戶端創建成功。2、實現鎖的獨占性。創建Znode成功的那個客戶端才能得到鎖，其它客戶端只能等待。當前客戶端用完這個鎖后，會刪除這個Znode，其它客戶端再嘗試創建Znode，獲取分布式鎖。3、控制鎖的時序。各個客戶端在某個Znode下創建臨時Znode，這個類型必須為CreateMode.EPHEMERAL_SEQUENTIAL，這樣該Znode可掌握全局訪問時序。 復制代碼

6、分布式隊列

分布式隊列分為兩種：

1、當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達，這種是同步隊列。 ??a）一個job由多個task組成，只有所有任務完成后，job才運行完成。 ??b）可為job創建一個/job目錄，然后在該目錄下，為每個完成的task創建一個臨時的Znode，一旦臨時節點數目達到task總數，則表明job運行完成。 ?? 2、隊列按照FIFO方式進行入隊和出隊操作，例如實現生產者和消費者模型。

三、ZooKeeper 安裝部署

zookeeper 的安裝模式有三種：

• 單機模式（ stand-alone）：單機單 server；
• 集群模式：多機多 server，形成集群；
• 偽集群模式：單機多個 server，形成偽集群；

環境：Cent OS 7.0

1、單機模式

（1）根據需要創建目錄，例如我的目錄是：/home/xuliugen/Desktop/zookeeper-install

（2）進入目錄，使用wget下載zookeeper， 下載地址：mirrors.tuna.tsinghua.edu.cn/apache/zook…

其他版本下載地址：mirrors.tuna.tsinghua.edu.cn/apache/zook…

完成如下：

（3）使用： tar -xvf zookeeper-3.4.6.tar.gz 解壓縮該文件；

（4）創建Zookeeper配置文件：

在Zookeeper的安裝目錄下的conf文件下，默認為：

使用：cp zoo_sample.cfg zoo.cfg 命令，復制一份為zoo.cfg文件，這是因為Zookeeper再啟動的時候默認使用的是zoo.cfg這個配置文件。

（5）根據需求修改配置文件內容：

一般默認的配置文件就可以演示啟動，配置文件如下：

# Zookeeper服務心跳檢測時間，單位為ms tickTime=2000# 投票選舉新leader的初始化時間 initLimit=10# leader與follower心跳檢測最大容忍時間，響應超過syncLimit*tickTime， # leader認為follower死掉，從服務器列表中刪除該follower syncLimit=5# the directory where the snapshot is stored. # do not use /tmp for storage, /tmp here is just # example sakes. dataDir=/tmp/zookeeper# the port at which the clients will connect clientPort=2181# the maximum number of client connections. # increase this if you need to handle more clients #maxClientCnxns=60# The number of snapshots to retain in dataDir #autopurge.snapRetainCount=3# Purge task interval in hours # Set to "0" to disable auto purge feature #autopurge.purgeInterval=1復制代碼

小提示：

在Zookeeper官方文檔中給了一個關于性能優化的小經驗，就是有幾個其他配置參數可以大大提高性能：

為了獲得更新時的低延遲，重要的是有一個專用的事務日志目錄。 默認情況下，事務日志與數據快照和myid文件放在同一目錄中。 dataLogDir參數指示用于事務日志的不同目錄。 復制代碼

意思就是說，最好將屬具目錄和日志目錄分離開來，從而提高數據的讀取更新效率。

（6）啟動Zookeeper

在Zookeeper安裝目錄的bin目錄下：

使用命令：./zkServer.sh start 即可開啟服務：

使用： ./zkCli.sh 命令可以進入到命令行管理界面：

到此單機模式就安裝結束了！

2、集群模式 3、偽集群模式

關于集群模式 和偽集群模式的配置，網上已經有很多內容，這里不再演示，請移步查看：

www.open-open.com/lib/view/op…

附錄：

zoo.cfg配置參數解釋：

---

參考文章：

1、《大型分布式網站架構-設計與實踐 陳康賢-著》 2、《Zookeeper-3.3.5源碼分析 劉少偉》 3、m.blog.csdn.net/article/det… 4、mt.sohu.com/20160527/n4… 5、www.open-open.com/lib/view/op…

搜索或掃描下述二維碼關注微信公眾號：Java后端技術（ID: JavaITWork）,和20萬人一起學Java！

Java后端技術專注Java相關技術：SSM、Spring全家桶、微服務、MySQL、MyCat、集群、分布式、中間件、Linux、網絡、多線程，偶爾講點運維Jenkins、Nexus、Docker、ELK，偶爾分享些技術干貨，致力于Java全棧開發！

【視頻福利】2T免費學習視頻，搜索或掃描上述二維碼關注微信公眾號：Java后端技術（ID: JavaITWork）回復：1024，即可免費獲取！內含SSM、Spring全家桶、微服務、MySQL、MyCat、集群、分布式、中間件、Linux、網絡、多線程，Jenkins、Nexus、Docker、ELK等等免費學習視頻，持續更新！

轉載于:https://juejin.im/post/5ceb8ee7518825333359ce4e

總結

以上是生活随笔為你收集整理的简要分析ZooKeeper基本原理及安装部署的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。