zookeeper 入門知識

zookeeper是什麼　

　　Zookeeper是一個開源的分布式協調服務，其設計目标是将那些複雜的且容易出錯的分布式一緻性服務封裝起來，構成一個高效可靠的原語集，并以一些列簡單的接口提供給使用者使用。其是一個典型的分布式資料一緻性的解決方案，分布式應用程式可以基于它實作諸如資料釋出/釋出、負載均衡、命名服務、分布式協調/通知、叢集管理、Master選舉、分布式鎖和分布式隊列等功能。其可以保證如下分布式一緻性特性。

　　① 順序一緻性，從同一個用戶端發起的事務請求，最終将會嚴格地按照其發起順序被應用到Zookeeper中去。

　　② 原子性，所有事務請求的處理結果在整個叢集中所有機器上的應用情況是一緻的，即整個叢集要麼都成功應用了某個事務，要麼都沒有應用。

　　③ 單一視圖，無論用戶端連接配接的是哪個Zookeeper伺服器，其看到的服務端資料模型都是一緻的。

　　④ 可靠性，一旦服務端成功地應用了一個事務，并完成對用戶端的響應，那麼該事務所引起的服務端狀态變更将會一直被保留，除非有另一個事務對其進行了變更。

　　⑤ 實時性，Zookeeper保證在一定的時間段内，用戶端最終一定能夠從服務端上讀取到最新的資料狀态。

設計目标

　　Zookeeper緻力于提供一個高性能、高可用、且具有嚴格的順序通路控制能力（主要是寫操作的嚴格順序性）的分布式協調服務，其具有如下的設計目标。

　　① 簡單的資料模型，Zookeeper使得分布式程式能夠通過一個共享的樹形結構的名字空間來進行互相協調，即Zookeeper伺服器記憶體中的資料模型由一系列被稱為ZNode的資料節點組成，Zookeeper将全量的資料存儲在記憶體中，以此來提高伺服器吞吐、減少延遲的目的。

　　② 可建構叢集，一個Zookeeper叢集通常由一組機器構成，組成Zookeeper叢集的而每台機器都會在記憶體中維護目前伺服器狀态，并且每台機器之間都互相通信。

　　③ 順序通路，對于來自用戶端的每個更新請求，Zookeeper都會配置設定一個全局唯一的遞增編号，這個編号反映了所有事務操作的先後順序。

　　④ 高性能，Zookeeper将全量資料存儲在記憶體中，并直接服務于用戶端的所有非事務請求，是以它尤其适用于以讀操作為主的應用場景。

zookeeper提供了什麼

檔案系統：zookeeper維護一個類似檔案系統的資料結構，每個子目錄項如 NameService 都被稱作為 znode，和檔案系統一樣，自由增加及删除，唯一不同其可存儲資料。Znode分為四種類型
- PERSISTENT-持久化目錄節點。（用戶端與zookeeper斷開連接配接後，該節點依舊存在）。
- PERSISTENT_SEQUENTIAL-持久化順序編号目錄節點。（用戶端與zookeeper斷開連接配接後，該節點依舊存在，隻是Zookeeper給該節點名稱進行順序編号）
- EPHEMERAL-臨時目錄節點（用戶端與zookeeper斷開連接配接後，該節點被删除）
- EPHEMERAL_SEQUENTIAL-臨時順序編号目錄節點。（用戶端與zookeeper斷開連接配接後，該節點被删除，隻是Zookeeper給該節點名稱進行順序編号）
通知機制：用戶端注冊監聽它關心的目錄節點，當目錄節點發生變化（資料改變、被删除、子目錄節點增加删除）時，zookeeper會通知用戶端。

zookeeper能為我們做什麼？

命名服務：在zookeeper的檔案系統裡建立一個目錄，即有唯一的path。在我們使用tborg無法确定上遊程式的部署機器時即可與下遊程式約定好path，通過path即能互相探索發現。

配置管理：把應用配置放置zookeeper上去,儲存在 Zookeeper 的某個目錄節點中，然後所有相關應用程式對這個目錄節點進行監聽，一旦配置資訊發生變化，每個應用程式就會收到 Zookeeper 的通知，然後從 Zookeeper 擷取新的配置資訊應用到系統中就好。

叢集管理：節點（機器）增删及Master選取。節點增删：所有機器約定在父目錄GroupMembers下建立臨時目錄節點，然後監聽父目錄節點的子節點變化消息。一旦有機器挂掉，該機器與 zookeeper的連接配接斷開，其所建立的臨時目錄節點被删除，所有其他機器都收到通知：某個兄弟目錄被删除，于是，所有人都知道：它上船了。新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount又有了。Master選取：所有機器建立臨時順序編号目錄節點，每次選取編号最小的機器作為master就好。

分布式鎖：基于zookeeper一緻性檔案系統,實作鎖服務。鎖服務分為儲存獨占及時序控制兩類。儲存獨占：将zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實作。所有用戶端都去建立 /distribute_lock 節點，最終成功建立的那個用戶端也即擁有了這把鎖。用完删除自己建立的distribute_lock 節點就釋放鎖。時序控制：基于/distribute_lock鎖，所有用戶端在它下面建立臨時順序編号目錄節點，和選master一樣，編号最小的獲得鎖，用完删除，依次友善。

隊列管理：分同步隊列,FIFO隊列（入隊與出隊），同步隊列：當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達。在約定目錄下建立臨時目錄節點，監聽節點數目是否是我們要求的數目。FIFO隊列：和分布式鎖服務中的控制時序場景基本原理一緻，入列有編号，出列按編号。

分布式與資料複制：Zookeeper作為一個叢集提供一緻的資料服務，必然在所有機器間做資料複制。資料複制好處：（1）容錯：一個節點出錯，不緻于讓整個系統停止工作，别的節點可以接管它的工作。（2）提高系統的擴充能力：把負載分布到多個節點上，或者增加節點來提高系統的負載能力；（3）性能提升：讓用戶端本地通路就近節點,提高使用者通路速度。

基本概念

　　① 叢集角色，最典型的叢集就是Master/Slave模式（主備模式），此情況下把所有能夠處理寫操作的機器稱為Master機器，把所有通過異步複制方式擷取最新資料，并提供讀服務的機器為Slave機器。Zookeeper引入了Leader、Follower、Observer三種角色，Zookeeper叢集中的所有機器通過Leaser選舉過程來標明一台被稱為Leader的機器，Leader伺服器為用戶端提供寫服務，Follower和Observer提供讀服務，但是Observer不參與Leader選舉過程，不參與寫操作的過半寫成功政策，Observer可以在不影響寫性能的情況下提升叢集的性能。

　　② 會話，指用戶端會話，一個用戶端連接配接是指用戶端和服務端之間的一個TCP長連接配接，Zookeeper對外的服務端口預設為2181，用戶端啟動的時候，首先會與伺服器建立一個TCP連接配接，從第一次連接配接建立開始，用戶端會話的生命周期也開始了，通過這個連接配接，用戶端能夠心跳檢測與伺服器保持有效的會話，也能夠向Zookeeper伺服器發送請求并接受響應，同時還能夠通過該連接配接接受來自伺服器的Watch事件通知。

　　③ 資料節點，第一類指構成叢集的機器，稱為機器節點，第二類是指資料模型中的資料單元，稱為資料節點-Znode，Zookeeper将所有資料存儲在記憶體中，資料模型是一棵樹，由斜杠/進行分割的路徑，就是一個ZNode，如/foo/path1，每個ZNode都會儲存自己的資料記憶體，同時還會儲存一些列屬性資訊。ZNode分為持久節點和臨時節點兩類，持久節點是指一旦這個ZNode被建立了，除非主動進行ZNode的移除操作，否則這個ZNode将一直儲存在Zookeeper上，而臨時節點的生命周期和用戶端會話綁定，一旦用戶端會話失效，那麼這個用戶端建立的所有臨時節點都會被移除。另外，Zookeeper還允許使用者為每個節點添加一個特殊的屬性：SEQUENTIAL。一旦節點被标記上這個屬性，那麼在這個節點被建立的時候，Zookeeper會自動在其節點後面追加一個整形數字，其是由父節點維護的自增數字。

　　④ 版本，對于每個ZNode，Zookeeper都會為其維護一個叫作Stat的資料結構，Stat記錄了這個ZNode的三個資料版本，分别是version（目前ZNode的版本）、cversion（目前ZNode子節點的版本）、aversion（目前ZNode的ACL版本）。

　　⑤ Watcher，Zookeeper允許使用者在指定節點上注冊一些Watcher，并且在一些特定事件觸發的時候，Zookeeper服務端會将事件通知到感興趣的用戶端。

　　⑥ ACL，Zookeeper采用ACL（Access Control Lists）政策來進行權限控制，其定義了如下五種權限：

　　　　· CREATE：建立子節點的權限。

　　　　· READ：擷取節點資料和子節點清單的權限。

　　　　· WRITE：更新節點資料的權限。

　　　　· DELETE：删除子節點的權限。

　　　　· ADMIN：設定節點ACL的權限。

ZAB協定

　　Zookeeper使用了Zookeeper Atomic Broadcast（ZAB，Zookeeper原子消息廣播協定）的協定作為其資料一緻性的核心算法。ZAB協定是為Zookeeper專門設計的一種支援崩潰恢複的原子廣播協定。

　　Zookeeper依賴ZAB協定來實作分布式資料的一緻性，基于該協定，Zookeeper實作了一種主備模式的系統架構來保持叢集中各副本之間的資料的一緻性，即其使用一個單一的諸程序來接收并處理用戶端的所有事務請求，并采用ZAB的原子廣播協定，将伺服器資料的狀态變更以事務Proposal的形式廣播到所有的副本程序中，ZAB協定的主備模型架構保證了同一時刻叢集中隻能夠有一個主程序來廣播伺服器的狀态變更，是以能夠很好地處理用戶端大量的并發請求。

　　ZAB協定的核心是定義了對于那些會改變Zookeeper伺服器資料狀态的事務請求的處理方式，即：所有事務請求必須由一個全局唯一的伺服器來協調處理，這樣的伺服器被稱為Leader伺服器，餘下的伺服器則稱為Follower伺服器，Leader伺服器負責将一個用戶端事務請求轉化成一個事務Proposal（提議），并将該Proposal分發給叢集中所有的Follower伺服器，之後Leader伺服器需要等待所有Follower伺服器的回報，一旦超過半數的Follower伺服器進行了正确的回報後，那麼Leader就會再次向所有的Follower伺服器分發Commit消息，要求其将前一個Proposal進行送出。

　　ZAB一些包括兩種基本的模式：崩潰恢複和消息廣播。

　　當整個服務架構啟動過程中或Leader伺服器出現網絡中斷、崩潰退出與重新開機等異常情況時，ZAB協定就會進入恢複模式并選舉産生新的Leader伺服器。當選舉産生了新的Leader伺服器，同時叢集中已經有過半的機器與該Leader伺服器完成了狀态同步之後，ZAB協定就會退出恢複模式，狀态同步時指資料同步，用來保證叢集在過半的機器能夠和Leader伺服器的資料狀态保持一緻。

　　當叢集中已經有過半的Follower伺服器完成了和Leader伺服器的狀态同步，那麼整個服務架構就可以進入消息廣播模式，當一台同樣遵守ZAB協定的伺服器啟動後加入到叢集中，如果此時叢集中已經存在一個Leader伺服器在負責進行消息廣播，那麼加入的伺服器就會自覺地進入資料恢複模式：找到Leader所在的伺服器，并與其進行資料同步，然後一起參與到消息廣播流程中去。Zookeeper隻允許唯一的一個Leader伺服器來進行事務請求的處理，Leader伺服器在接收到用戶端的事務請求後，會生成對應的事務提議并發起一輪廣播協定，而如果叢集中的其他機器收到用戶端的事務請求後，那麼這些非Leader伺服器會首先将這個事務請求轉發給Leader伺服器。

　　當Leader伺服器出現崩潰或者機器重新開機、叢集中已經不存在過半的伺服器與Leader伺服器保持正常通信時，那麼在重新開始新的一輪的原子廣播事務操作之前，所有程序首先會使用崩潰恢複協定來使彼此到達一緻狀态，于是整個ZAB流程就會從消息廣播模式進入到崩潰恢複模式。一個機器要成為新的Leader，必須獲得過半機器的支援，同時由于每個機器都有可能會崩潰，是以，ZAB協定運作過程中，前後會出現多個Leader，并且每台機器也有可能會多次成為Leader，進入崩潰恢複模式後，隻要叢集中存在過半的伺服器能夠彼此進行正常通信，那麼就可以産生一個新的Leader并再次進入消息廣播模式。如一個由三台機器組成的ZAB服務，通常由一個Leader、2個Follower伺服器組成，某一個時刻，加入其中一個Follower挂了，整個ZAB叢集是不會中斷服務的。

　　① 消息廣播，ZAB協定的消息廣播過程使用原子廣播協定，類似于一個二階段送出過程，針對用戶端的事務請求，Leader伺服器會為其生成對應的事務Proposal，并将其發送給叢集中其餘所有的機器，然後再分别收集各自的選票，最後進行事務送出。

　　在ZAB的二階段送出過程中，移除了中斷邏輯，所有的Follower伺服器要麼正常回報Leader提出的事務Proposal，要麼就抛棄Leader伺服器，同時，ZAB協定将二階段送出中的中斷邏輯移除意味着我們可以在過半的Follower伺服器已經回報Ack之後就開始送出事務Proposal，而不需要等待叢集中所有的Follower伺服器都回報響應，但是，在這種簡化的二階段送出模型下，無法處理Leader伺服器崩潰退出而帶來的資料不一緻問題，是以ZAB采用了崩潰恢複模式來解決此問題，另外，整個消息廣播協定是基于具有FIFO特性的TCP協定來進行網絡通信的，是以能夠很容易保證消息廣播過程中消息接受與發送的順序性。再整個消息廣播過程中，Leader伺服器會為每個事務請求生成對應的Proposal來進行廣播，并且在廣播事務Proposal之前，Leader伺服器會首先為這個事務Proposal配置設定一個全局單調遞增的唯一ID，稱之為事務ID（ZXID），由于ZAB協定需要保證每個消息嚴格的因果關系，是以必須将每個事務Proposal按照其ZXID的先後順序來進行排序和處理。

　　② 崩潰恢複，在Leader伺服器出現崩潰，或者由于網絡原因導緻Leader伺服器失去了與過半Follower的聯系，那麼就會進入崩潰恢複模式，在ZAB協定中，為了保證程式的正确運作，整個恢複過程結束後需要選舉出一個新的Leader伺服器，是以，ZAB協定需要一個高效且可靠的Leader選舉算法，進而保證能夠快速地選舉出新的Leader，同時，Leader選舉算法不僅僅需要讓Leader自身知道已經被選舉為Leader，同時還需要讓叢集中的所有其他機器也能夠快速地感覺到選舉産生的新的Leader伺服器。

　　③ 基本特性，ZAB協定規定了如果一個事務Proposal在一台機器上被處理成功，那麼應該在所有的機器上都被處理成功，哪怕機器出現故障崩潰。ZAB協定需要確定那些已經在Leader伺服器上送出的事務最終被所有伺服器都送出，假設一個事務在Leader伺服器上被送出了，并且已經得到了過半Follower伺服器的Ack回報，但是在它Commit消息發送給所有Follower機器之前，Leader服務挂了。如下圖所示

　　在叢集正常運作過程中的某一個時刻，Server1是Leader伺服器，其先後廣播了P1、P2、C1、P3、C2（C2是Commit Of Proposal2的縮寫），其中，當Leader伺服器發出C2後就立即崩潰退出了，針對這種情況，ZAB協定就需要確定事務Proposal2最終能夠在所有的伺服器上都被送出成功，否則将出現不一緻。

　　ZAB協定需要確定丢棄那些隻在Leader伺服器上被提出的事務。如果在崩潰恢複過程中出現一個需要被丢棄的提議，那麼在崩潰恢複結束後需要跳過該事務Proposal，如下圖所示

　　假設初始的Leader伺服器Server1在提出一個事務Proposal3之後就崩潰退出了，進而導緻叢集中的其他伺服器都沒有收到這個事務Proposal，于是，當Server1恢複過來再次加入到叢集中的時候，ZAB協定需要確定丢棄Proposal3這個事務。

　　在上述的崩潰恢複過程中需要處理的特殊情況，就決定了ZAB協定必須設計這樣的Leader選舉算法：能夠確定送出已經被Leader送出的事務的Proposal，同時丢棄已經被跳過的事務Proposal。如果讓Leader選舉算法能夠保證新選舉出來的Leader伺服器擁有叢集中所有機器最高編号（ZXID最大）的事務Proposal，那麼就可以保證這個新選舉出來的Leader一定具有所有已經送出的提議，更為重要的是如果讓具有最高編号事務的Proposal機器稱為Leader，就可以省去Leader伺服器查詢Proposal的送出和丢棄工作這一步驟了。

　　④ 資料同步，完成Leader選舉後，在正式開始工作前，Leader伺服器首先會确認日志中的所有Proposal是否都已經被叢集中的過半機器送出了，即是否完成了資料同步。Leader伺服器需要确所有的Follower伺服器都能夠接收到每一條事務Proposal，并且能夠正确地将所有已經送出了的事務Proposal應用到記憶體資料庫中。Leader伺服器會為每個Follower伺服器維護一個隊列，并将那些沒有被各Follower伺服器同步的事務以Proposal消息的形式逐個發送給Follower伺服器，并在每一個Proposal消息後面緊接着再發送一個Commit消息，以表示該事務已經被送出，等到Follower伺服器将所有其尚未同步的事務Proposal都從Leader伺服器上同步過來并成功應用到本地資料庫後，Leader伺服器就會将該Follower伺服器加入到真正的可用Follower清單并開始之後的其他流程。

　　下面分析ZAB協定如何處理需要丢棄的事務Proposal的，ZXID是一個64位的數字，其中32位可以看做是一個簡單的單調遞增的計數器，針對用戶端的每一個事務請求，Leader伺服器在産生一個新的事務Proposal時，都會對該計數器進行加1操作，而高32位則代表了Leader周期epoch的編号，每當選舉産生一個新的Leader時，就會從這個Leader上取出其本地日志中最大事務Proposal的ZXID，并解析出epoch值，然後加1，之後以該編号作為新的epoch，低32位則置為0來開始生成新的ZXID，ZAB協定通過epoch号來區分Leader周期變化的政策，能夠有效地避免不同的Leader伺服器錯誤地使用不同的ZXID編号提出不一樣的事務Proposal的異常情況。當一個包含了上一個Leader周期中尚未送出過的事務Proposal的伺服器啟動時，其肯定無法成為Leader，因為目前叢集中一定包含了一個Quorum（過半）集合，該集合中的機器一定包含了更高epoch的事務的Proposal，是以這台機器的事務Proposal并非最高，也就無法成為Leader。

ZAB協定原理

　　ZAB主要包括消息廣播和崩潰恢複兩個過程，進一步可以分為三個階段，分别是發現（Discovery）、同步（Synchronization）、廣播（Broadcast）階段。ZAB的每一個分布式程序會循環執行這三個階段，稱為主程序周期。

　　· 發現，選舉産生PL(prospective leader)，PL收集Follower epoch(cepoch)，根據Follower的回報，PL産生newepoch(每次選舉産生新Leader的同時産生新epoch)。

　　· 同步，PL補齊相比Follower多數派缺失的狀态、之後各Follower再補齊相比PL缺失的狀态，PL和Follower完成狀态同步後PL變為正式Leader(established leader)。

　　· 廣播，Leader處理用戶端的寫操作，并将狀态變更廣播至Follower，Follower多數派通過之後Leader發起将狀态變更落地(deliver/commit)。

　　在正常運作過程中，ZAB協定會一直運作于階段三來反複進行消息廣播流程，如果出現崩潰或其他原因導緻Leader缺失，那麼此時ZAB協定會再次進入發現階段，選舉新的Leader。

　運作分析

　　每個程序都有可能處于如下三種狀态之一

　　· LOOKING：Leader選舉階段。

　　· FOLLOWING：Follower伺服器和Leader伺服器保持同步狀态。

　　· LEADING：Leader伺服器作為主程序上司狀态。

　　所有程序初始狀态都是LOOKING狀态，此時不存在Leader，此時，程序會試圖選舉出一個新的Leader，之後，如果程序發現已經選舉出新的Leader了，那麼它就會切換到FOLLOWING狀态，并開始和Leader保持同步，處于FOLLOWING狀态的程序稱為Follower，LEADING狀态的程序稱為Leader，當Leader崩潰或放棄上司地位時，其餘的Follower程序就會轉換到LOOKING狀态開始新一輪的Leader選舉。

　　一個Follower隻能和一個Leader保持同步，Leader程序和所有與所有的Follower程序之間都通過心跳檢測機制來感覺彼此的情況。若Leader能夠在逾時時間内正常收到心跳檢測，那麼Follower就會一直與該Leader保持連接配接，而如果在指定時間内Leader無法從過半的Follower程序那裡接收到心跳檢測，或者TCP連接配接斷開，那麼Leader會放棄目前周期的上司，比你轉換到LOOKING狀态，其他的Follower也會選擇放棄這個Leader，同時轉換到LOOKING狀态，之後會進行新一輪的Leader選舉，并在選舉産生新的Leader之後開始新的一輪主程序周期。

　ZAB與Paxos的聯系和差別

　　聯系：

　　① 都存在一個類似于Leader程序的角色，由其負責協調多個Follower程序的運作。

　　② Leader程序都會等待超過半數的Follower做出正确的回報後，才會将一個提議進行送出。

　　③ 在ZAB協定中，每個Proposal中都包含了一個epoch值，用來代表目前的Leader周期，在Paxos算法中，同樣存在這樣的一個辨別，名字為Ballot。

　　差別：

　　Paxos算法中，新選舉産生的主程序會進行兩個階段的工作，第一階段稱為讀階段，新的主程序和其他程序通信來收集主程序提出的提議，并将它們送出。第二階段稱為寫階段，目前主程序開始提出自己的提議。

　　ZAB協定在Paxos基礎上添加了同步階段，此時，新的Leader會确儲存在過半的Follower已經送出了之前的Leader周期中的所有事務Proposal。

　　ZAB協定主要用于建構一個高可用的分布式資料主備系統，而Paxos算法則用于建構一個分布式的一緻性狀态機系統。

Zookeeper配置（搭建zookeeper伺服器叢集）

1.1 結構：一共三個節點 (zk伺服器叢集規模不小于3個節點),要求伺服器之間系統時間保持一緻。

1.2 上傳zk

進行解壓： tar zookeeper-3.4.5.tar.gz

重命名： mv zookeeper-3.4.5 zookeeper

修改環境變量： vi /etc/profile

export ZOOKEEPER_HOME=/usr/local/zookeeper

export PATH=.:$HADOOP_HOME/bin:$ZOOKEEPER_HOME/bin:$JAVA_HOME/...

重新整理： source /etc/profile

到zookeeper下修改配置檔案

cd /usr/local/zookeeper/conf

mv zoo_sample.cfg zoo.cfg

修改conf: vi zoo.cfg 修改兩處

（1）dataDir=/usr/local/zookeeper/data

（2）最後面添加

server.0=bhz:2888:3888

server.1=hadoop1:2888:3888

server.2=hadoop2:2888:3888

伺服器辨別配置：

建立檔案夾：mkdir data

建立檔案myid并填寫内容為0：vi myid (内容為伺服器辨別： 0)

進行複制zookeeper目錄到hadoop01和hadoop02 還有/etc/profile檔案

把hadoop01、hadoop02中的myid檔案裡的值修改為1和2 路徑(vi /usr/local/zookeeper/data/myid)

啟動zookeeper：

路徑：/usr/local/zookeeper/bin

執行：zkServer.sh start (注意這裡3台機器都要進行啟動)

狀态：zkServer.sh status(在三個節點上檢驗zk的mode,一個leader和倆個follower)

1.3 操作zookeeper (shell)

zkCli.sh 進入zookeeper用戶端

根據提示指令進行操作：

查找：ls / ls /zookeeper

建立并指派：create /bhz hadoop

擷取：get /bhz

設值：set /bhz baihezhuo

可以看到zookeeper叢集的資料一緻性

建立節點有倆種類型：短暫（ephemeral）持久（persistent）

zoo.cfg詳解：

　　tickTime：基本事件單元，以毫秒為機關。這個時間是作為 Zookeeper 伺服器之間或用戶端與伺服器之間維持心跳的時間間隔，也就是每隔 tickTime時間就會發送一個心跳。

dataDir：存儲記憶體中資料庫快照的位置，顧名思義就是 Zookeeper 儲存資料的目錄，預設情況下，Zookeeper 将寫資料的日志檔案也儲存在這個目錄裡。

clientPort：這個端口就是用戶端連接配接 Zookeeper 伺服器的端口，Zookeeper 會監聽這個端口，接受用戶端的通路請求。

initLimit：這個配置項是用來配置 Zookeeper 接受用戶端初始化連接配接時最長能忍受多少個心跳時間間隔數，當已經超過 10 個心跳的時間（也就是 tickTime）長度後 Zookeeper 伺服器還沒有收到用戶端的傳回資訊，那麼表明這個用戶端連接配接失敗。總的時間長度就是 10*2000=20 秒。

syncLimit：這個配置項辨別 Leader 與 Follower 之間發送消息，請求和應答時間長度，最長不能超過多少個 tickTime 的時間長度，總的時間長度就是 5*2000=10 秒

server.A = B:C:D :

A表示這個是第幾号伺服器,

B 是這個伺服器的 ip 位址；

C 表示的是這個伺服器與叢集中的 Leader 伺服器交換資訊的端口；

D 表示的是萬一叢集中的 Leader 伺服器挂了，需要一個端口來重新進行選舉，選出一個新的 Leader

出處：https://www.cnblogs.com/leesf456/p/6012777.html