zookeeper 部署

1.1 zookeeper 簡介

1.1.1 zookeeper是什麼

ZooKeeper 是Hadoop下的一個子專案，它是一個針對大型分散式系統的可靠協調系統；它提供的功能包括：配置維護、名字服務、分散式同步、組服務等； 它的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。
Zookeeper一個最常用的使用場景就是用於擔任服務生產者和服務消費者的註冊中心，服務生產者將自己提供的服務註冊到Zookeeper中心，服務的消費者在進行服務呼叫的時候先到Zookeeper中查詢服務，獲取到服務生產者的詳細資訊之後，再去呼叫服務生產者的內容與資料，簡單示例圖如下

1.1.2 ZooKeeper設計目標

ZooKeeper允許分散式程序通過共享的層次結構名稱空間進行相互協調，這與標準檔案系統類似。 名稱空間由ZooKeeper中的資料暫存器組成 - 稱為znode，這些類似於檔案和目錄。 與為儲存設計的典型檔案系統不同，ZooKeeper資料儲存在記憶體中，這意味著ZooKeeper可以實現高吞吐量和低延遲。
Zookeeper層次結構名稱空間示意圖如下：

通過這種樹圖結構的資料模型，很容易的查詢到具體的某一個服務

1.1.3 ZooKeeper主要特點

• 最終一致性：為客戶端展示同一檢視，這是 ZooKeeper 最重要的效能。
• 可靠性：如果訊息被一臺伺服器接受，那麼它將被所有的伺服器接受。
• 實時性：ZooKeeper 不能保證兩個客戶端同時得到剛更新的資料，如果需要最新資料，應該在讀資料之前呼叫sync()介面。
• 等待無關（wait-free）：慢的或者失效的 client 不干預快速的client的請求。
• 原子性：更新只能成功或者失敗，沒有中間其它狀態。
• 順序性：對於所有Server，同一訊息釋出順序一致。123456123456

2.1 ZooKeeper基本原理

2.1.1 zookeeper系統架構

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

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

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

• 組成ZooKeeper服務的伺服器必須彼此瞭解。 它們維護一個記憶體中的狀態影象，以及持久儲存中的事務日誌和快照， 只要大多數伺服器可用，ZooKeeper服務就可用；

• ZooKeeper 啟動時，將從例項中選舉一個 leader，Leader 負責處理資料更新等操作，一個更新操作成功的標誌是當且僅當大多數Server在記憶體中成功修改資料。每個Server 在記憶體中儲存了一份資料。

• Zookeeper是可以叢集複製的，叢集間通過Zab協議（Zookeeper Atomic Broadcast）來保持資料的一致性；

• Zab協議包含兩個階段：leader election階段和Atomic Brodcast階段。

• 1. 叢集中將選舉出一個leader，其他的機器則稱為follower，所有的寫操作都被傳送給leader，並通過brodcast將所有的更新告訴給follower。
• 2. 當leader崩潰或者leader失去大多數的follower時，需要重新選舉出一個新的leader，讓所有的伺服器都恢復到一個正確的狀態。

• 3.當leader被選舉出來，且大多數伺服器完成了 和leader的狀態同步後，leadder election 的過程就結束了，就將會進入到Atomic brodcast的過程。

• 4.Atomic Brodcast同步leader和follower之間的資訊，保證leader和follower具有形同的系統狀態。

2.1.2 Zookeeper 角色

啟動 Zookeeper 伺服器叢集環境後，多個 Zookeeper 伺服器在工作前會選舉出一個 Leader。選舉出 leader 前，所有 server 不區分角色，都需要平等參與投票（ obServer 除外，不參與投票）；
選主過程完成後，存在以下幾種角色：

2.1.3 zookeeper讀寫資料流

ZooKeeper 的寫資料流程主要分為以下幾步：

• 比如 Client 向 ZooKeeper 的 Server1 上寫資料，傳送一個寫請求。
• 如果Server1不是Leader，那麼Server1 會把接受到的請求進一步轉發給Leader，因為每個ZooKeeper的Server裡面有一個是Leader。這個Leader 會將寫請求廣播給各個Server，比如Server1和Server2， 各個Server寫成功後就會通知Leader。
• 當Leader收到大多數 Server 資料寫成功了，那麼就說明資料寫成功了。如果這裡三個節點的話，只要有兩個節點資料寫成功了，那麼就認為資料寫成功了。寫成功之後，Leader會告訴Server1資料寫成功了。
• Server1會進一步通知 Client 資料寫成功了，這時就認為整個寫操作成功。

2.1.4 ZooKeeper 元件

ZooKeeper元件顯示了ZooKeeper服務的高階元件。 除了請求處理器，組成ZooKeeper服務的每個伺服器複製其自己的每個元件的副本。

Replicated Database是包含整個資料樹的記憶體資料庫。 更新操作會記錄到磁盤裡以進行可恢復性，並且寫操作將在放到記憶體資料庫之前序列化到磁碟。

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

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

3.1 安裝zookeeper

3.1.1 模式選擇

zookeeper 的安裝模式有三種：

• 單機模式（ stand-alone）：單機單 server；
• 叢集模式：多機多 server，形成叢集；
• 偽叢集模式：單機多個 server，形成偽叢集；
  這裡只有單點模式，叢集模式會再起一個文件詳細說明

3.1.2 安裝包下載

下載地址： https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper

wget https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/zookeeper-3.5.9/apache-zookeeper-3.5.9-bin.tar.gz --no-check-certificate

3.1.3 安裝部署

3.1.3.1 解壓

tar zxvf apache-zookeeper-3.5.9-bin.tar.gz
mv apache-zookeeper-3.5.9-bin /opt/zookeeper
cd /opt/zookeeper/conf;cp zoo_sample.cfg  zoo.cfg

3.1.3.2 修改配置檔案

vim /opt/zookeeper/conf/zoo.cfg
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/opt/zookeeper/data/zookeeper
clientPort=2181

3.1.3.3 啟動zookeeper

• 啟動server

cd /opt/zookeeper/bin/
sh zkServer.sh start
sh zkServer.sh status  #檢視狀態

• 開啟客戶端

sh zkCli.sh

• 檢視根節點下的子節點(Znode維繫在記憶體和磁碟中)

ls /

• 根節點下建立子節點（必須儲存配置資訊或節點描述）

create /log 'log servers'

• 子節點下建立子節點（必須儲存配置資訊或節點描述）

create /log/log01 ''

• 刪除節點(要求沒有子節點)

delete /music

• 檢視節點詳情

get /log

• 修改資料

set /log 'info'