ZooKeeper安裝 ( 資源 )

時間 2019-12-11

原文原文鏈接

ZooKeeper簡介

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

分佈式協調服務就是爲用戶的分佈式應用程序提供協調服務。
ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。java

Zookeeper是爲別的分佈式程序服務的；node

Zookeeper自己就是一個分佈式程序（只要有半數以上節點存活，zk就能正常服務，因此通常zk都是奇數臺服務器） linux

Zookeeper所提供的服務涵蓋：主從協調、服務器節點動態上下線、統一配置管理、分佈式共享鎖、統一名稱服務…… 算法

zookeeper在底層其實只提供了兩個功能：apache

管理(存儲，讀取)用戶程序提交的數據；編程
併爲用戶程序提供數據節點監聽服務；服務器

Zookeeper集羣的角色： Leader 和 follower （Observer）
只要集羣中有半數以上節點存活，集羣就能提供服務網絡

Zookeeper的數據存儲結構就像一棵樹，這棵樹由節點組成，這種節點叫作Znode
ZooKeeper包含一個簡單的原語集，提供Java和C的接口。調/通知、集羣管理、Master 選舉、配置維護，名字服務、分佈式同步、分佈式鎖和分佈式隊列session

分佈式應用程序能夠基於 ZooKeeper 實現諸如數據發佈/訂閱、負載均衡、命名服務、分佈式協
ZooKeeper代碼版本中，提供了分佈式獨享鎖、選舉、隊列的接口，代碼在zookeeper-3.4.3\src\recipes。其
中分佈鎖和隊列有Java和C兩個版本，選舉只有Java版本。
ZooKeeper是以Fast Paxos算法爲基礎的，Paxos 算法存在活鎖的問題，即當有多個proposer交錯提交時，
有可能互相排斥致使沒有一個proposer能提交成功，而Fast Paxos做了一些優化，經過選舉產生一個leader，只
有leader才能提交proposer，具體算法可見Fast Paxos。所以，要想弄懂ZooKeeper首先得對Fast Paxos有所了
解。

ZooKeeper是一個開放源碼的分佈式應用程序協調服務，它包含一個簡單的原語集，分佈式應用程序能夠基於它實現同步服務，配置維護和命名服務等。

ZooKeeper的基本運轉流程：

一、選舉Leader。
二、同步數據。
三、選舉Leader過程當中算法有不少，但要達到的選舉標準是一致的。
四、Leader要具備最高的zxid。
五、集羣中大多數的機器獲得響應並follow選出的Leader。

Znode分爲四種類型：

1.持久節點（PERSISTENT）

默認的節點類型。建立節點的客戶端與zookeeper斷開鏈接後，該節點依舊存在。

2.持久節點順序節點（PERSISTENT_SEQUENTIAL）

所謂順序節點，就是在建立節點時，Zookeeper根據建立的時間順序給該節點名稱進行編號：

3.臨時節點（EPHEMERAL）

和持久節點相反，當建立節點的客戶端與zookeeper斷開鏈接後，臨時節點會被刪除：

4.臨時順序節點（EPHEMERAL_SEQUENTIAL）

顧名思義，臨時順序節點結合和臨時節點和順序節點的特色：在建立節點時，Zookeeper根據建立的時間順序給該節點名稱進行編號；當建立節點的客戶端與zookeeper斷開鏈接後，臨時節點會被刪除。

Zookeeper分佈式鎖的原理

獲取鎖

首先，在Zookeeper當中建立一個持久節點ParentLock。當第一個客戶端想要得到鎖時，須要在ParentLock這個節點下面建立一個臨時順序節點 Lock1。

以後，Client1查找ParentLock下面全部的臨時順序節點並排序，判斷本身所建立的節點Lock1是否是順序最靠前的一個。若是是第一個節點，則成功得到鎖。

若是再有一個客戶端 Client2 前來獲取鎖，則在ParentLock下載再建立一個臨時順序節點Lock2。

Client2查找ParentLock下面全部的臨時順序節點並排序，判斷本身所建立的節點Lock2是否是順序最靠前的一個，結果發現節點Lock2並非最小的。

因而，Client2向排序僅比它靠前的節點Lock1註冊Watcher，用於監聽Lock1節點是否存在。這意味着Client2搶鎖失敗，進入了等待狀態。

若是又有一個客戶端Client3前來獲取鎖，則在ParentLock下載再建立一個臨時順序節點Lock3。

Client3查找ParentLock下面全部的臨時順序節點並排序，判斷本身所建立的節點Lock3是否是順序最靠前的一個，結果一樣發現節點Lock3並非最小的。

因而，Client3向排序僅比它靠前的節點Lock2註冊Watcher，用於監聽Lock2節點是否存在。這意味着Client3一樣搶鎖失敗，進入了等待狀態。

這樣一來，Client1獲得了鎖，Client2監聽了Lock1，Client3監聽了Lock2。這偏偏造成了一個等待隊列，很像是Java當中ReentrantLock所依賴的AQS（AbstractQueuedSynchronizer）。

釋放鎖

釋放鎖分爲兩種狀況：

1.任務完成，客戶端顯示釋放

當任務完成時，Client1會顯示調用刪除節點Lock1的指令。

2.任務執行過程當中，客戶端崩潰

得到鎖的Client1在任務執行過程當中，若是Duang的一聲崩潰，則會斷開與Zookeeper服務端的連接。根據臨時節點的特性，相關聯的節點Lock1會隨之自動刪除。

因爲Client2一直監聽着Lock1的存在狀態，當Lock1節點被刪除，Client2會馬上收到通知。這時候Client2會再次查詢ParentLock下面的全部節點，確認本身建立的節點Lock2是否是目前最小的節點。若是是最小，則Client2瓜熟蒂落得到了鎖。

同理，若是Client2也由於任務完成或者節點崩潰而刪除了節點Lock2，那麼Client3就會接到通知。

最終，Client3成功獲得了鎖。

用Zookeeper實現分佈式鎖和Redis實現分佈式鎖的區別

Zookeeper和Redis分佈式鎖的比較

下面的表格總結了Zookeeper和Redis分佈式鎖的優缺點：

Zookeeper和Redis實現的分佈式鎖支持可重入，二者均可以在客戶端實現可重入邏輯。者均可以在客戶端實現可重入邏輯。

Zookeeper TTL機制

鍵值系統有一個對應用配置頗有幫助的特性，能夠給每個鍵或目錄指定一個存活時限（TTL，即Time To Life）。TTL的單位是秒，當指定的秒數過去之後，若是相應的鍵或目錄沒有獲得更新，就會被自動從Etcd記錄中移除。
在zookeeper中，當你建立一個PERSISTENT或者PERSISTENT_SEQUENTIAL的節點的時候，能夠有選擇性給這個節點設置一個毫秒的TTL時間，若是這個節點在ttl時間以內沒有獲得更新而且沒有孩子節點，這個節點就會在server端被刪除掉。

什麼是TTL ： https://blog.csdn.net/Frozen_fish/article/details/2245462

TTL（生存時間）介紹：https://blog.csdn.net/tanga842428/article/details/52932221

ZooKeeper設計目的

1.最終一致性：client不論鏈接到哪一個Server，展現給它都是同一個視圖，這是zookeeper最重要的功能。

2.可靠性：具備簡單、健壯、良好的性能，若是消息m被到一臺服務器接受，那麼它將被全部的服務器接受。

3.實時性：Zookeeper保證客戶端將在一個時間間隔範圍內得到服務器的更新信息，或者服務器失效的信息。但因爲網絡延時等緣由，Zookeeper不能保證兩個客戶端能同時獲得剛更新的數據，若是須要最新數據，應該在讀數據以前調用sync()接口。

4.等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每一個client都能有效的等待。

5.原子性：更新只能成功或者失敗，沒有中間狀態。

6.順序性：包括全局有序和偏序兩種：全局有序是指若是在一臺服務器上消息a在消息b前發佈，則在全部Server上消息a都將在消息b前被髮布；偏序是指若是一個消息b在消息a後被同一個發送者發佈，a必將排在b前面。

ZooKeeper數據模型

Zookeeper會維護一個具備層次關係的數據結構，它很是相似於一個標準的文件系統，如圖所示：

Zookeeper這種數據結構有以下這些特色：

1）每一個子目錄項如NameService都被稱做爲znode，這個znode是被它所在的路徑惟一標識，如Server1這個znode的標識爲/NameService/Server1。

2）znode能夠有子節點目錄，而且每一個znode能夠存儲數據，注意EPHEMERAL（臨時的）類型的目錄節點不能有子節點目錄。

3）znode是有版本的（version），每一個znode中存儲的數據能夠有多個版本，也就是一個訪問路徑中能夠存儲多份數據，version號自動增長。

4）znode的類型：

Persistent 節點，一旦被建立，便不會意外丟失，即便服務器所有重啓也依然存在。每一個 Persist 節點便可包含數據，也可包含子節點。
Ephemeral 節點，在建立它的客戶端與服務器間的 Session 結束時自動被刪除。服務器重啓會致使 Session 結束，所以 Ephemeral 類型的 znode 此時也會自動刪除。

Non-sequence 節點，多個客戶端同時建立同一 Non-sequence 節點時，只有一個可建立成功，其它勻失敗。而且建立出的節點名稱與建立時指定的節點名徹底同樣。
Sequence 節點，建立出的節點名在指定的名稱以後帶有10位10進制數的序號。多個客戶端建立同一名稱的節點時，都能建立成功，只是序號不一樣。

5）znode能夠被監控，包括這個目錄節點中存儲的數據的修改，子節點目錄的變化等，一旦變化能夠通知設置監控的客戶端，這個是Zookeeper的核心特性，Zookeeper的不少功能都是基於這個特性實現的。

6）ZXID：每次對Zookeeper的狀態的改變都會產生一個zxid（ZooKeeper Transaction Id），zxid是全局有序的，若是zxid1小於zxid2，則zxid1在zxid2以前發生。

ZooKeeper Session

Client和Zookeeper集羣創建鏈接，整個session狀態變化如圖所示：

若是Client由於Timeout和Zookeeper Server失去鏈接，client處在CONNECTING狀態，會自動嘗試再去鏈接Server，若是在session有效期內再次成功鏈接到某個Server，則回到CONNECTED狀態。

注意：若是由於網絡狀態很差，client和Server失去聯繫，client會停留在當前狀態，會嘗試主動再次鏈接Zookeeper Server。client不能宣稱本身的session expired，session expired是由Zookeeper Server來決定的，client能夠選擇本身主動關閉session。

ZooKeeper Watch

Zookeeper watch是一種監聽通知機制。Zookeeper全部的讀操做getData(), getChildren()和 exists()均可以設置監視(watch)，監視事件能夠理解爲一次性的觸發器，官方定義以下： a watch event is one-time trigger, sent to the client that set the watch, whichoccurs when the data for which the watch was set changes。Watch的三個關鍵點：

*（一次性觸發）One-time trigger

當設置監視的數據發生改變時，該監視事件會被髮送到客戶端，例如，若是客戶端調用了getData("/znode1", true) 而且稍後 /znode1 節點上的數據發生了改變或者被刪除了，客戶端將會獲取到 /znode1 發生變化的監視事件，而若是 /znode1 再一次發生了變化，除非客戶端再次對/znode1 設置監視，不然客戶端不會收到事件通知。

*（發送至客戶端）Sent to the client

Zookeeper客戶端和服務端是經過 socket 進行通訊的，因爲網絡存在故障，因此監視事件頗有可能不會成功地到達客戶端，監視事件是異步發送至監視者的，Zookeeper 自己提供了順序保證(ordering guarantee)：即客戶端只有首先看到了監視事件後，纔會感知到它所設置監視的znode發生了變化(a client will never see a change for which it has set a watch until it first sees the watch event)。網絡延遲或者其餘因素可能致使不一樣的客戶端在不一樣的時刻感知某一監視事件，可是不一樣的客戶端所看到的一切具備一致的順序。

*（被設置 watch 的數據）The data for which the watch was set

這意味着znode節點自己具備不一樣的改變方式。你也能夠想象 Zookeeper 維護了兩條監視鏈表：數據監視和子節點監視(data watches and child watches) getData() 和exists()設置數據監視，getChildren()設置子節點監視。或者你也能夠想象 Zookeeper 設置的不一樣監視返回不一樣的數據，getData() 和 exists() 返回znode節點的相關信息，而getChildren() 返回子節點列表。所以，setData() 會觸發設置在某一節點上所設置的數據監視（假定數據設置成功），而一次成功的create() 操做則會出發當前節點上所設置的數據監視以及父節點的子節點監視。一次成功的 delete操做將會觸發當前節點的數據監視和子節點監視事件，同時也會觸發該節點父節點的child watch。

Zookeeper 中的監視是輕量級的，所以容易設置、維護和分發。當客戶端與 Zookeeper 服務器失去聯繫時，客戶端並不會收到監視事件的通知，只有當客戶端從新鏈接後，若在必要的狀況下，之前註冊的監視會從新被註冊並觸發，對於開發人員來講這一般是透明的。只有一種狀況會致使監視事件的丟失，即：經過exists()設置了某個znode節點的監視，可是若是某個客戶端在此znode節點被建立和刪除的時間間隔內與zookeeper服務器失去了聯繫，該客戶端即便稍後從新鏈接 zookeeper服務器後也得不到事件通知。

Consistency Guarantees

Zookeeper是一個高效的、可擴展的服務，read和write操做都被設計爲快速的，read比write操做更快。

順序一致性（Sequential Consistency）：從一個客戶端來的更新請求會被順序執行。

原子性（Atomicity）：更新要麼成功要麼失敗，沒有部分紅功的狀況。

惟一的系統鏡像（Single System Image）：不管客戶端鏈接到哪一個Server，看到系統鏡像是一致的。

可靠性（Reliability）：更新一旦有效，持續有效，直到被覆蓋。

時間線（Timeliness）：保證在必定的時間內各個客戶端看到的系統信息是一致的。

ZooKeeper的工做原理

在zookeeper的集羣中，各個節點共有下面3種角色和4種狀態：

角色：leader,follower,observer
狀態：leading,following,observing,looking

Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫作Zab協議（ZooKeeper Atomic Broadcast protocol）。Zab協議有兩種模式，它們分別是恢復模式（Recovery選主）和廣播模式（Broadcast同步）。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步之後，恢復模式就結束了。狀態同步保證了leader和Server具備相同的系統狀態。

爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。全部的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。

每一個Server在工做過程當中有4種狀態：

LOOKING：當前Server不知道leader是誰，正在搜尋。

LEADING：當前Server即爲選舉出來的leader。

FOLLOWING：leader已經選舉出來，當前Server與之同步。

OBSERVING：observer的行爲在大多數狀況下與follower徹底一致，可是他們不參加選舉和投票，而僅僅接受(observing)選舉和投票的結果。

Leader Election

當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式須要從新選舉出一個新的leader，讓全部的Server都恢復到一個正確的狀態。Zk的選舉算法有兩種：一種是基於basic paxos實現的，另一種是基於fast paxos算法實現的。系統默認的選舉算法爲fast paxos。先介紹basic paxos流程：

1.選舉線程由當前Server發起選舉的線程擔任，其主要功能是對投票結果進行統計，並選出推薦的Server；

2.選舉線程首先向全部Server發起一次詢問（包括本身）；

3.選舉線程收到回覆後，驗證是不是本身發起的詢問（驗證zxid是否一致），而後獲取對方的id（myid），並存儲到當前詢問對象列表中，最後獲取對方提議的leader相關信息（id,zxid），並將這些信息存儲到當次選舉的投票記錄表中；

4.收到全部Server回覆之後，就計算出zxid最大的那個Server，並將這個Server相關信息設置成下一次要投票的Server；

5.線程將當前zxid最大的Server設置爲當前Server要推薦的Leader，若是此時獲勝的Server得到n/2 + 1的Server票數，設置當前推薦的leader爲獲勝的Server，將根據獲勝的Server相關信息設置本身的狀態，不然，繼續這個過程，直到leader被選舉出來。

經過流程分析咱們能夠得出：要使Leader得到多數Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少於n+1.

每一個Server啓動後都會重複以上流程。在恢復模式下，若是是剛從崩潰狀態恢復的或者剛啓動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日誌並按期進行快照，方便在恢復時進行狀態恢復。

fast paxos流程是在選舉過程當中，某Server首先向全部Server提議本身要成爲leader，當其它Server收到提議之後，解決epoch和zxid的衝突，並接受對方的提議，而後向對方發送接受提議完成的消息，重複這個流程，最後必定能選舉出Leader。

Leader工做流程

Leader主要有三個功能：

1.恢復數據；

2.維持與follower的心跳，接收follower請求並判斷follower的請求消息類型；

3.follower的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據不一樣的消息類型，進行不一樣的處理。

PING消息是指follower的心跳信息；REQUEST消息是follower發送的提議信息，包括寫請求及同步請求；

ACK消息是follower的對提議的回覆，超過半數的follower經過，則commit該提議；

REVALIDATE消息是用來延長SESSION有效時間。

Follower工做流程

Follower主要有四個功能：

1. 向Leader發送請求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；

2.接收Leader消息並進行處理；

3.接收Client的請求，若是爲寫請求，發送給Leader進行投票；

4.返回Client結果。

Follower的消息循環處理以下幾種來自Leader的消息：

1.PING消息：心跳消息

2.PROPOSAL消息：Leader發起的提案，要求Follower投票

3.COMMIT消息：服務器端最新一次提案的信息

4.UPTODATE消息：代表同步完成

5.REVALIDATE消息：根據Leader的REVALIDATE結果，關閉待revalidate的session仍是容許其接受消息

6.SYNC消息：返回SYNC結果到客戶端，這個消息最初由客戶端發起，用來強制獲得最新的更新。

Zab: Broadcasting State Updates

Zookeeper Server接收到一次request，若是是follower，會轉發給leader，Leader執行請求並經過Transaction的形式廣播此次執行。Zookeeper集羣如何決定一個Transaction是否被commit執行？經過「兩段提交協議」（a two-phase commit）：

Leader給全部的follower發送一個PROPOSAL消息。
一個follower接收到此次PROPOSAL消息，寫到磁盤，發送給leader一個ACK消息，告知已經收到。
當Leader收到法定人數（quorum）的follower的ACK時候，發送commit消息執行。

Zab協議保證：

1）若是leader以T1和T2的順序廣播，那麼全部的Server必須先執行T1，再執行T2。
2）若是任意一個Server以T一、T2的順序commit執行，其餘全部的Server也必須以T一、T2的順序執行。

「兩段提交協議」最大的問題是若是Leader發送了PROPOSAL消息後crash或暫時失去鏈接，會致使整個集羣處在一種不肯定的狀態（follower不知道該放棄此次提交仍是執行提交）。Zookeeper這時會選出新的leader，請求處理也會移到新的leader上，不一樣的leader由不一樣的epoch標識。切換Leader時，須要解決下面兩個問題：

1. Never forget delivered messages

Leader在COMMIT投遞到任何一臺follower以前crash，只有它本身commit了。新Leader必須保證這個事務也必須commit。

2. Let go of messages that are skipped

Leader產生某個proposal，可是在crash以前，沒有follower看到這個proposal。該server恢復時，必須丟棄這個proposal。

Zookeeper會盡可能保證不會同時有2個活動的Leader，由於2個不一樣的Leader會致使集羣處在一種不一致的狀態，因此Zab協議同時保證：

1）在新的leader廣播Transaction以前，先前Leader commit的Transaction都會先執行。
2）在任意時刻，都不會有2個Server同時有法定人數（quorum）的支持者。

這裏的quorum是一半以上的Server數目，確切的說是有投票權力的Server（不包括Observer）。

總結：簡單介紹了Zookeeper的基本原理，數據模型，Session，Watch機制，一致性保證，Leader Election，Leader和Follower的工做流程和Zab協議。

1、下載zookeeper安裝包

在官網中下載，對於在牆內的用戶，並不推薦該方式下載速度可能比較慢
推薦方式：在cloudera倉庫進行下載，相較於官網下載更加穩定快速，地址http://archive.cloudera.com/cdh5/cdh/5/，選擇須要版本下載tar.gz的安裝包
下載zookeeper-3.4.6安裝包

[root@localhosts ~]#  cd/usr/developSoft/

[root@localhosts ~]# wget http://www.apache.org/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz

[root@localhosts ~]#  tar -zxvf  zookeeper-3.4.6.tar.gz  -C /usr/local/

進入/usr/local/zookeeper-3.4.6/bin目錄

./zkServer.sh start 啓動服務

./zkServer.sh stop 中止服務

2、將安裝包上傳解壓到服務器指定目錄

下載zookeeper的安裝包以後, 解壓到合適目錄. 進入zookeeper目錄下的conf子目錄

將zoo_sample.cfg複製一份成zoo.cfg

個人目錄：

/opt/zookeeper-3.4.8/data

/opt/zookeeper-3.4.8/logs

配置zoo.cfg

[root@localhosts ~]#  cd /usr/local/zookeeper-3.4.6/conf

[root@localhosts ~]#  vi   zoo.cfg

修改

dataDir=/opt/zookeeper-3.4.8/data

增長

dataLogDir=/opt/zookeeper-3.4.8/logs

保存退出

啓動zookeeper

進入bin目錄

```
[root@localhosts ~]#  cd bin
```

./zkServer.sh start-foreground #之前臺程序啓動服務

或者

./zkServer.sh start #之後臺程序啓動zkServer 服務器

./zkServer.shstop #中止zkServer服務器

使用客戶端鏈接

./zkCli.sh

配置文件zoo.cfg參數說明：

tickTime：這個時間是做爲zookeeper服務器之間或客戶端與服務器之間維持心跳的時間間隔，也就是tickTime時間就會發送一個心跳

initLimit：這個配置項是用來配置zookeeper接收客戶端（這所說的客戶端是zookeeper服務器集羣中鏈接到leader的Follower服務器）初始化鏈接時最長能忍受多少個心跳時間間隔數。當已經超過initLimit個心跳的時間（也就是tickTime）長度後zookeeper服務器尚未收到客戶端的返回信息，那麼代表這個客戶端鏈接失敗。總的時間長度就是tickTime * initLimit

syncLimit：這個配置標識Leader與Follower之間發送信息，請求和應答時間長度，最長不能超過多少個tickTime的時間長度，總的時間長度就是syncLimit * tickTime

clientPort：這個端口就是客戶端鏈接zookeeper服務器的端口，zookeeper會監聽這個端口，接收客戶端的訪問請求。

dataDir：存儲數據的目錄

dataLogDir：日誌目錄，若是不設置，會存放在dataDir

執行 tar -zxvf zookeeperXXX.tar.gz -C /modules將zookeeper解壓到指定的modules目錄，根據用戶本身的須要進行替換。

3、對默認配置文件進行重命名

將zookeeper根目錄中conf文件夾下的zoo_sample.cfg重命名爲zoo.cfg，修改後zookeeper即可以識別到該文件

4、修改zoo.cfg配置文件

在該文件中根據須要添加以下配置：

#發送心跳的間隔時間，單位：毫秒
tickTime=2000
#zookeeper保存數據的目錄
dataDir=/modules/zookeeper-3.4.5-cdh5.11.1/data
#日誌目錄
dataLogDir=/modules/zookeeper-3.4.5-cdh5.11.1/dataLog
#端口
clientPort=2181
#leader和follower初始化鏈接時最長能忍受多少個心跳時間的間隔數
initLimit=5
#leader和follower之間發送消息，請求和英達時間長度，最長不能超過多少個tickTime的時間長度
syncLimit=2
#zookeeper機器列表，server.order這裏的Order依據集羣的機器個數依次進行遞增，這裏的server一、server二、server3表示機器IP地址
server.1=server1:2888:3888
server.2=server2:2888:3888
server.3=server3:2888:3888

Ps:上面的data目錄和dataLog目錄默認是沒有的，須要本身預先創建好。而且真正用戶開發環境的配置文件，儘可能刪除刪掉上面的註釋，以及多餘的空白字符(劃重點)，有可能會形成zookeeper的讀取失敗

5、新建myid文件

在server1機器中，在上面配置的data目錄下，新建一個名爲 myid的文件，文件內容填寫 1，對的，沒有聽錯，文件中只保留一個數字 1。zookeeper是根據該文件來決定zookeeper集羣各個機器的身份分配。

6、將配置好的zookeeper分發到集羣的全部機器

通過上面的五個步驟zookeeper已經配置完畢，而後將其依次拷貝的集羣的其餘機器中。快捷一點可使用 scp 命令來作這件事：

scp 本地zookeeper安裝目錄登錄遠程機器的用戶名@遠程機器地址 : 遠程機器存放zookeeper的地址

eg:scp zookeeper skyler@slave1:/modules/

而後修改data目錄的下的myid 文件中的數字，在這裏即爲將server2的myid內容修改成2，將server3的myid內容修改成3。對於不一樣的集羣，根據須要進行修改，與配置文件中的order保持一致。

7、啓動zookeeper服務

修改完成後，在每臺機器上依次使用bin/zkServer.sh start來啓動zookeeper服務，待啓動完成後使用 bin/zkServer.sh status來查看該機器的身份

8、啓動zookeeper客戶端檢驗服務是否可用

使用 bin/zkCli.sh來檢驗zookeeper是否能夠鏈接成功，若出現以下提示，則表示zookeeper服務已經安裝成功。

參考連接：https://blog.csdn.net/u011186019/article/details/65034540?locationNum=11&fps=1

參考：

《ZooKeeper—Distributed Process Coordination》 by FlavioJunqueira and Benjamin Reed

http://zookeeper.apache.org/doc/trunk/zookeeperOver.html

http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/index.html

《ZooKeeper的一致性算法賞析》https://my.oschina.net/pingpangkuangmo/blog/778927

漫畫：如何用Zookeeper實現分佈式鎖？：https://mp.weixin.qq.com/s/u8QDlrDj3Rl1YjY4TyKMCA

連接：

5分鐘讓你瞭解 ZooKeeper 的功能和原理： https://www.jianshu.com/p/370f61549395

zookeeper的安裝分爲三種模式：單機模式、集羣模式和僞集羣模式。 : https://www.cnblogs.com/jxwch/p/6433310.html

zookeeper原理 : https://mp.weixin.qq.com/s/6S1YBp3ZpJYMeral2KADyw

ZooKeeper系列教學 : https://blog.csdn.net/weixin_39800144/article/details/79312457

一、Zookeeper深刻理解(一)(概念及基礎)

http://hao0.me/zookeeper/2015/02/28/zk-basic.html

二、Zookeeper深刻理解(二)(編程實踐之Master-Worker)

http://hao0.me/zookeeper/2015/03/02/zk-program-master-worker.html

三、Zookeeper深刻理解(二)(編程實踐之故障處理)

http://hao0.me/zookeeper/2015/03/10/zk-failure.html

四、Zookeeper深刻理解(二)(編程實踐之Zookeepr使用警告)

http://hao0.me/zookeeper/2015/03/15/zk-caveat-emptor.html

五、Zookeeper深刻理解(二)(編程實踐之高級API:Curator)

http://hao0.me/zookeeper/2015/03/20/zk-curator.html

六、Zookeeper深刻理解(三)(Zookeeper管理以內部組件)

http://hao0.me/zookeeper/2015/03/25/zk-admin-internals.html

七、Zookeeper深刻理解(三)(Zookeeper管理之運維)

http://hao0.me/zookeeper/2015/04/25/zk-admin-running.html

zookeeper-概述：https://mp.weixin.qq.com/s/SSP1CiBvvMBCuLA6iOcT2g

zookeeper-原理：https://mp.weixin.qq.com/s/kzI7t546Mybhk9AUGAVroA

zookeeper原理 https://mp.weixin.qq.com/s/6S1YBp3ZpJYMeral2KADyw

zookeeper-理論基礎-paxos協議：https://mp.weixin.qq.com/s/EhBUomPcg4lQ2woUdxKEmQ

zookeeper-理論基礎-zab協議：https://mp.weixin.qq.com/s/cH1LZulz4PFTGu93OOYFRQ

構建高可用ZooKeeper集羣： https://www.csharpkit.com/2017-10-14_72138.html

又一個支持斷線重連、永久watcher、遞歸操做 ZooKeeper 客戶端：https://www.csharpkit.com/2017-10-14_50672.html

支持斷線重連、永久watcher、遞歸操做而且能跨平臺（.NET Core）的ZooKeeper異步客戶端： https://www.csharpkit.com/2017-10-14_50632.html

zookeeper 基本原理 : https://mp.weixin.qq.com/s?__biz=MzI0MDQ4MTM5NQ==&mid=2247486649&idx=2&sn=208d5ee0a8c401b9bde345921e2a6881&chksm=e91b69a5de6ce0b34c072a354d4d5f8bae314197ab2921feeb4b6ac622dac1308b794165091e&scene=21#wechat_redirect

（W3Cschool）Zookeeper教程 ： https://www.w3cschool.cn/zookeeper/index.html