文章目錄

• 一、zookeeper簡介
• • 1.1 zookeeper的概述
  • 1.2 Zookeeper的定義
  • 1.3 Zookeeper的工作機制
  • 1.4 Zookeeper 的特點
  • 1.5 zookeeper 的數據結構
• 二、Zookeeper的應用場景
• • 2.1 統一命名服務
  • 2.2 統一配置管理
  • 2.3 統一集群管理
  • 2.4 服務器動態上下線
  • 2.5 軟負載均衡
• 三、Zookeeper的選舉機制
• • 3.1 第一次啟動選舉機制
  • 3.2 非第一次啟動選舉機制
• 四、部署Zookeeper集群
• • 4.1 部署Zookeeper集群的具體實驗步驟（實操）
  • • 1.安裝前準備
    • 2.安裝Zookeeper\
    • 3.修改配置文件
    • • ① 復制配置文件
      • ② 修改配置，添加集群信息
    • 4.在每個節點上創建數據目錄和日志目錄
    • 5.在每個節點的dataDir指定的目錄下創建一個myid的文件
    • 6.配置Zookeeper啟動腳本
    • 7.設置開機自啟
    • 8.分別啟動 Zookeeper并查看狀態

一、zookeeper簡介

1.1 zookeeper的概述

ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。

ZooKeeper的目標就是封裝好復雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

ZooKeeper包含一個簡單的原語集，提供Java和C的接口。

ZooKeeper代碼版本中，提供了分布式獨享鎖、選舉、隊列的接口，代碼在$zookeeper_home\src\recipes。其中分布鎖和隊列有Java和C兩個版本，選舉只有Java版本。

1.2 Zookeeper的定義

Zookeeper是一~個開源的分布式的，為分布式框架提供協調服務的Apache項目。

1.3 Zookeeper的工作機制

Zookeeper從設計模式角度來理解:是一個基于觀察者模式設計的分布式服務管理框架，它負責存儲和管理大家都關心的數據，然后接受觀察者的注冊，一旦這些數據的狀態發生變化，Zookeeper就將負責通知已經在Zookeeper上注冊的那些觀察者做出相應的反應。

就是說Zookeeper =文件系統+通知機制。

1.4 Zookeeper 的特點

(1) Zookeeper：一個領導者(Leader) ，多個跟隨者(Follower) 組成的集群。
(2) Zookeepe集群中只要有半數以上節點存活，Zookeeper集群就能正常服務。所以Zookeeper適合安裝奇數臺服務器。
(3)全局數據一致：每個Server保存一份相同的數據副本，Client無論連接到哪個Server， 數據都是一致的。
(4)更新請求順序執行，來自同一個Client的更新請求按其發送順序依次執行，即先進先出。.
(5)數據更新原子性，一次數據更新要么成功，要么失敗。
(6)實時性，在一定時間范圍內，Client能讀到最新數據。

1.5 zookeeper 的數據結構

ZooKeeper數據模型的結構與Linux文件系統很類似，整體上可以看作是一棵樹，每個節點稱做–個ZNode。
每一個ZNode默認能夠存儲1MB的數據，每個ZNode都可以通過其路徑唯一標識。

二、Zookeeper的應用場景

提供的服務包括:統一命名服務、 統一配置管理、統一集群管理、服務器節點動態上下線、軟負載均衡等。

2.1 統一命名服務

在分布式環境下，經常需要對應用/服務進行統一命名， 便于識別。例如: IP不容 易記住，而域名容易記住。

2.2 統一配置管理

分布式環境下，配置文件同步非常常見。一般要求一個集群中，所有節點的配置信息是一致的，比如Kafka集群。對配置文
件修改后，希望能夠快速同步到各個節點上。
配置管理可交由ZooKeeper實現?？蓪⑴渲眯畔懭隯ooKeeper.上的一-個Znode。各個客戶端服務器監聽這個Znode。一旦
Znode中的數據被修改，ZooKeeper將 通知各個客戶端服務器。

2.3 統一集群管理

分布式環境中，實時掌握每個節點的狀態是必要的。可根據節點實時狀態做出一-些調整。
ZooKeeper可以實現實時監控節點狀態變化?？蓪⒐濣c信息寫入ZooKeeper.上的一-個ZNode。監聽這個ZNode可獲取它的實時狀態變化。

2.4 服務器動態上下線

客戶端能實時洞察到服務器上下線的變化。

2.5 軟負載均衡

在Zookeeper中記錄每臺服務器的訪問數，讓訪問數最少的服務器去處理最新的客戶端請求。

三、Zookeeper的選舉機制

3.1 第一次啟動選舉機制

服務器1啟動，發起一次選舉。服務器1投自己一票。此時服務器1票數一票， 不夠半數以上(3票)，選舉無法完成，服務器1狀態保持為LO0KING;
服務器2啟動，再發起一次選舉。服務器1和2分別投自己一票并交換選票信息:此時服務器1發現服務器2的myid比自己目前
投票推舉的( 服務器1)大，更改選票為推舉服務器2。此時服務器1票數0票，服務器2票數2票，沒有半數以上結果，選舉無法完成，服務器1，2狀態保持LOOKING
服務器3啟動，發起一次選舉。此時服務器1和2都會更改選票為服務器3。此次投票結果:服務器1為0票，服務器2為0票，服
務器3為3票。此時服務器3的票數已經超過半數，服務器3當選Leader。服務器1，2更改狀態為FOLLOWING，服務器3更改狀態為LEADING;
服務器4啟動，發起一次選舉。此時服務器1，2，3已經不是L00KING狀態，不會更改選票信息。交換選票信息結果:服務器3為3票，服務器4為1票。此時服務器4服從多數，更改選票信息為服務器3，并更改狀態為FOLLOWING;
服務器5啟動，同4服從多數，更改選票信息為服務器3，并更改狀態為FOLLOWING;

3.2 非第一次啟動選舉機制

1）當ZooKeeper集群中的一臺 服務器出現以下兩種情況之一時， 就會開始進入Leader選舉:

服務器初始化啟動。
服務器運行期間無法和Leader保持連接。

2）而當一臺機器進入Leader選舉流程時，當前集群也可能會處于以下兩種狀態:

集群中本來就已經存在一個Leader。
對于已經存在Leader的情況，機器試圖去選舉Leader時，會被告知當前服務器的Leader信息，對于該機器來說，僅僅需要和Leader機器建立連接，并進行狀態同步即可。

集群中確實不存在Leader
假設ZooKeeper由5臺服務器組成，SID分別為1、2、3、4、5，ZXID分別為8、8、8、7、7，并且此時SID為3的服務器是Leader。某一時刻，3和5服務器出現故障，因此開始進行Leader選舉。

選舉Leader規則:

EPOCH大的直接勝出。
EPOCH相同，事務id大的勝出。
事務id相同，服務器id大的勝出。

SID: 服務器ID。用來唯一 標識一臺ZooKeeper集群中的機器，每臺機器不能重復，和myid一致。
ZXID:事務ID。ZXID是-一個事務ID，用來標識一次服務器狀態的變更。在某-一時刻，集群中的每臺機器的ZXID值不一定完全一致，這和ZooKeeper服務器對于客戶端“更新請求”的處理邏輯速度有關。
Epoch:每個Leader任期的代號。沒有Leader時同一輪投票過程中的邏輯時鐘值是相同的。每投完一次票這個數據就會增加

四、部署Zookeeper集群

4.1 部署Zookeeper集群的具體實驗步驟（實操）

1.安裝前準備

查看版本

2.安裝Zookeeper\

3.修改配置文件

① 復制配置文件

② 修改配置，添加集群信息

4.在每個節點上創建數據目錄和日志目錄

5.在每個節點的dataDir指定的目錄下創建一個myid的文件

6.配置Zookeeper啟動腳本

7.設置開機自啟

8.分別啟動 Zookeeper并查看狀態

總結

以上是生活随笔為你收集整理的分布式系统的可靠协调系统——Zookeeper的全部內容，希望文章能夠幫你解決所遇到的問題。

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