ZooKeeper進階（一）：ZooKeeper簡介

#ZooKeeper進階（一）：Zookeeper簡介

##zookeeper配置文件簡介

-：點我下載

ZooKeeper 的功能特性通過 ZooKeeper 配置文件來進行控制管理（ zoo.cfg 配置文件）。ZooKeeper 這樣的設計其實是有它自身的原因的。通過前面對 ZooKeeper 的配置可以看出，對 ZooKeeper 集群進行配置的時候，它的配置文檔是完全相同的（對于集群偽分布模式來說，只有很少的部分是不同的）。這樣的配置方使得在部署 ZooKeeper 服務的時候非常地方便。另外，如果服務器使用不同的配置文件，必須要確保不同配置文件中的服務器列表相匹配。

zookeeper的配置文件在conf目錄下，有zoo_sample.cfg，需要將zoo_sample.cfg 改為zoo.cfg，因為zookeeper在啟動時會找這個文件作為默認的配置文件。

在設置 ZooKeeper 配置文檔的時候，某些參數是可選的，但是某些參數是必須的。這些必須的參數就構成了 ZooKeeper 配置文檔的最低配置要求。

下面是在最低配置要求中必須配置的參數：

參數：

###最低配置

tickTime：基本事件單元，以毫秒為單位。它用來控制心跳和超時，默認情況下最小的會話超時時間為兩倍的 tickTime 。zookeeper服務器或者客戶端與服務器之間維持心跳時間間隔參數。每個ticktime時間就會發送一個心跳。

dataDir ： zookeeper數據存儲目錄，存儲內存中數據庫快照的位置。默認情況會把日志文件保存到這個目錄。注意 應該謹慎地選擇日志存放的位置，使用專用的日志存儲設備能夠大大地提高系統的性能，如果將日志存儲在比較繁忙的存儲設備上，那么將會在很大程度上影響系統的性能。

clientPort ：zookeeper服務器端口，zookeeper會監聽這個端口，接受客戶端的請求。

###高級配置

下面是高級配置要求中可選的配置參數，用戶可以使用下面的參數來更好地規定 ZooKeeper 的行為：

dataLogDir : 這個操作將管理機器把***事務日志***寫入到“ dataLogDir ”所指定的目錄，而不是“ dataDir”所指定的目錄。這將允許使用一個專用的日志設備并且幫助我們避免日志和快照之間的競爭。

maxClientCnxns : 這個操作將限制連接到 ZooKeeper 的客戶端的數量，限制并發連接的數量，它通過 IP來區分不同的客戶端。此配置選項可以用來阻止某些類別的 Dos 攻擊。將它設置為 0 或者忽略而不進行設置將會取消對并發連接的限制。

##集群模式

zookeeper不僅可以單機提供服務，同時也支持多機組成集群來提供服務。實際上zookeeper還支持另外一種偽集群的方式，就是可以在一臺機器上配置多個zookeeper實例。

配置（zoo.cfg)：

initLimit=5 syncLimit=2 server.1=192.168.211.1:2888:3888 server.2=192.168.211.2:2888:3888

initLimit ：此配置表示，允許 follower （相對于 leader 而言的“客戶端”）連接并同步到 leader 的初始化連接時間，它以 tickTime 的倍數來表示。當超過設置倍數的 tickTime 時間，則連接失敗。

syncLimit : 此配置表示， leader 與 follower 之間發送消息，請求和應答時間長度。如果 follower 在設置的時間內不能與 leader 進行通信，那么此 follower 將被丟棄。

server.A = B : C : D 其中A是一個數字，表示這是第幾號服務器；B是這服務器的ip地址；C表示的是這個服務器與集群中的leader服務器交換信息的端口，是供follower和leader進行數據同步通信用的，這個是長連接隨時同步數據，健康情況下正常運行，leader宕機就無法正常執行，此時觸發選舉程序選擇新的leader；D表示的是萬一集群中的leader服務器掛了，需要一個端口來重新進行選舉新的leader。由于這兩個端口號完成的是不同的功能，所以C、D兩個端口號不能相同。

除了修改zoo.cfg配置文件，集群模式下還要配置一個文件myid， 這個文件在dataDir目錄下，這個文件里面就是一個數據就是A的值，zookeeper啟動時會讀取這個文件，拿到里面的數據與zoo.cfg里面的配置信息從而判斷到底是哪個server。myid文件的內容只有一行，且內容只能為1 - 255之間的數字，這個數字亦即上面介紹server.id中的id，表示zk進程的id。

###注意

單機模式的zk進程雖然便于開發與測試，但并不適合在生產環境使用。在生產環境下，我們需要使用集群模式來對zk進行部署。

在集群模式下，建議至少部署3個zk進程，或者部署奇數個zk進程。如果只部署2個zk進程，當其中一個zk進程掛掉后，剩下的一個進程并不能構成一個quorum的大多數。因此，部署2個進程甚至比單機模式更不可靠，因為2個進程其中一個不可用的可能性比一個進程不可用的可能性還大。

##原理

zookeeper使用zab協議，類似Paxos算法，但在操作方面卻是不同的，該協議包括2個不斷重復的階段：

領導者選舉：集群所有機器一起選出一臺領導者，其它機器成為跟隨者，一旦半數以上的跟隨者將狀態同步，表示這個階段完成（官方數據這個階段持續200毫秒）。

原子廣播：所有機器將寫操作轉發給領導者，領導者再將更新廣播給跟隨者，只有半數以上的跟隨者同步修改之后領導者才會提交更新，客戶端才能收到更新成功的信息。

它的核心是一個精簡的文件系統，形成一個樹狀的數據結構，統一使用節點（znode）的概念，節點可以有子節點，也可以用來保存數據，并且有一個關聯的ACL，因為zookeeper被設計來實現協調服務，通常使用小數據文件，所以znode能存儲的數據限制在1M以內。zookeeper采用斜杠分割的Unicode字符串來做引用類似文件系統路徑，但必須是標準的，不支持./這種特殊字符，使用/zookeeper子樹來保存管理信息。

客戶端與服務器通信采用tcp長連接，客戶端和服務器通過心跳來保持seesion的連接。當session失效時臨時節點會被刪除。

通過監控節點以及節點的變化來實現例如集群管理，配置的集中管理，分布式鎖等功能。

zookeeper通過復制實現高可用性，只要集群中半數以上的機器可用，就能提供服務，所以一個集群通常要奇數臺機器。

zookeeper的生命周期有以下3個狀態CONNECTION,CONNECTED,CLOSED。

新產生的zookeeper實例是CONNECTION狀態，通過建立連接進入CONNECTED狀態，當zookeeper實例斷開和重連的時候，zookeeper實例在CONNECTED和COONECTION之間轉換，調用close方法或者會話超時會進入到CLOSE狀態且不能恢復。

##應用場景

Zookeeper從設計模式的角度來看是一個觀察者模式的分布式服務管理框架，負責存儲和管理大家關心的數據，然后接受觀察者的注冊，一旦這些數據發生變化，Zookeeper就會負責通知已經注冊過了的那些observer做出相應的反應，從而實現集群中類似的Master、Slave管理模式。

###統一命名服務（Name Service)

分布式應用中，通常需要有一套完整的命名規則， 能夠產生唯一的名稱以便于識別和記住，通常情況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一個有層次的目錄結構，既對人友好又不會重復。 Name Service是Zookeeper內置的功能， 只須調用其api就可以實現。如調用create接口就可以容易的創建 一個目錄節點。（與JNDI 差不多吧）

###配置管理

配置的管理費用在分布式應用環境中很常見，例如同一個應用系統需要多個pc server運行， 但是它們運行的應用系統的某些配置項是相同的，如果要修改這些相同的的配置項，那么就必須同時修改每臺運行這個應用系統的PC server，這樣非常容易出錯。像這樣的配置信息完全可以交給zookeeper管理，將配置信息保存在zookeeper的某個目錄節點上，然后將所有需要修改的應用機器監控配置信息的狀態，一旦配置信息發生變化，每臺機器就會收zookeeper的通知。




ZooKeeper 任務調度

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。