ZooKeeper管理員指南——部署與管理ZooKeeper

問題導讀
ZooKeeper Server須要的jdk版本是哪一個？
ZooKeeper集羣配置是否必須奇數，奇數的好處是什麼？
關於myid文件myid表明什麼？
ZK是否有程序日誌？
ZK日誌級別都是什麼？
ZK監控有幾種方法？
加載數據出錯該如何恢復？
JVM堆大小該如何，提升ZK的性能？



本文並不是一個ZK搭建的快速入門，關於這方面，能夠查看《ZooKeeper快速搭建》。
 

1.部署

本章節主要講述如何部署ZooKeeper，包括如下三部分的內容：

 

1. 系統環境

2. 集羣模式的配置

3. 單機模式的配置

系統環境和集羣模式配置這兩節內容大致講述瞭如何部署一個可以用於生產環境的ZK集羣。若是僅僅是想在單機上將ZK運行起來，進行一些開發與測試，那麼第三部分或許是你的菜。

 

1.1系統環境

1.1.1平臺支持

平 臺	運行client	運行server	開發環境	生產環境
GNU/Linux	√	√	√	√
Sun Solaris	√	√	√	√
FreeBSD	√	ⅹ，對nio的支持很差	√	√
Win32	√	√	√	ⅹ
MacOSX	√	√	√	ⅹ

注：運行client是指做爲客戶端，與server進行數據通訊，而運行server是指將ZK做爲服務器部署運行。

 

1.1.2軟件環境

ZooKeeper Server是一個Java語言實現的分佈式協調服務框架，所以須要6或更高版本的JDK支持。集羣的機器數量方面，寬泛的講，實際上是任意臺機器均可以部署運行的，注意，這裏並無說必定要奇數臺機器哦！一般狀況下，建議使用3臺獨立的Linux服務器構成的一個ZK集羣。

 

1.2集羣模式的配置

爲了確保ZooKeeper服務的穩定與可靠性，一般是搭建成一個ZK集羣來對外提供服務。關於ZooKeeper，須要明確一個很重要的特性：集羣中只要有過半的機器是正常工做的，那麼整個集羣對外就是可用的（本文下面就用「過半存活便可用」來代替這個特性吧^-^）。正是基於這個特性，建議是將ZK集羣的機器數量控制爲奇數較爲合適。爲何選擇奇數臺機器，咱們能夠來看一下，假如是4臺機器構成的ZK集羣，那麼只可以容許集羣中有一個機器down掉，由於若是down掉2臺，那麼只剩下2臺機器，顯然沒有過半。而若是是5臺機器的集羣，那麼就可以對2臺機器down掉的狀況進行容災了。

你能夠按照如下步驟來配置一個ZK機器，更多詳細步驟請查看《ZooKeeper快速搭建》：

 

1. 安裝JDK。相關連接：http://java.sun.com/javase/downloads/index.jsp

2. 設置Java heap 大小。避免內存與磁盤空間的交換，可以大大提高ZK的性能，設置合理的heap大小則能有效避免此類空間交換的觸發。在正式發佈上線以前，建議是針對使用場景進行一些壓力測試，確保正常運行後內存的使用不會觸發此類交換。一般在一個物理內存爲4G的機器上，最多設置-Xmx爲3G。

3. 下載安裝ZooKeeper，相關連接：http://zookeeper.apache.org/releases.html

4. 配置文件zoo.cfg。初次使用zookeeper，按照以下這個簡單配置便可：

1. tickTime=2000 
2. dataDir=/var/lib/zookeeper/ 
3. clientPort=2181 
4. initLimit=5 
5. syncLimit=2 server.1=zoo1:2888:3888 
6. server.2=zoo2:2888:3888 
7. server.3=zoo3:2888:3888

複製代碼

本文後續章節會對這些參數進行詳細的介紹，這裏只是簡單說幾點：
   A. 集羣中的每臺機器都須要感知整個集羣是由哪幾臺機器組成的，在配置文件中，能夠按照這樣的格式，每行寫一個機器配置：server.id=host:port:port. 關於這個id，咱們稱之爲Server ID，標識host機器在集羣中的機器序號，在每一個ZK機器上，咱們須要在數據目錄（數據目錄就是dataDir參數指定的那個目錄）下建立一個myid文件，myid中就是這個Server ID數字。
   B. 在ZooKeeper的設計中，集羣中任意一臺機器上的zoo.cfg文件的內容都是一致的。所以最好是用SVN把這個文件管理起來，保證每一個機器都能共享到一份相同的配置。

5. 關於myid文件。myid文件中只有一個數字，即一個Server ID。例如，server.1 的myid文件內容就是「1」。注意，請確保每一個server的myid文件中id數字不一樣，而且和server.id=host:port:port中的id一致。另外，id的範圍是1~255。

6. 至此，配置文件基本ok，能夠嘗試使用以下命令來啓動zookeeper了：
 

1. $ java -cp zookeeper.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf \ org.apache.zookeeper.server.quorum.QuorumPeerMainzoo.cfg

複製代碼

注意，不一樣的ZK版本，依賴的log4j和slf4j版本也是不同的，請看清楚本身的版本後，再執行上面這個命令。QuorumPeerMain類會啓動ZooKeeper Server，同時，JMX MB也會被啓動，方便管理員在JMX管理控制檯上進行ZK的控制。這裏有對ZK JMX的詳細介紹：http://zookeeper.apache.org/doc/r3.4.3/zookeeperJMX.html.  另外，徹底能夠有更簡便的方式，直接使用%ZK_HOME%/bin 中的腳本啓動便可。

1. ./zkServer.sh start

複製代碼

 

7. 鏈接ZK host來檢驗部署是否成功。

   A. Java語言的話，能夠經過運行這個命令來檢測：

1. $ java -cp zookeeper.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf:src/java/lib/jline-0.9.94.jar \ org.apache.zookeeper.ZooKeeperMain -server 127.0.0.1:2181

複製代碼
B. 若是是C語言的話，方法以下：

1. $ make cli_st 
2. $ make cli_mt

複製代碼

而後按照的這樣的方式鏈接ZK：$ cli_mt 127.0.0.1:2181。不管運行哪一種客戶端，最終都是一個相似於文件系統的命令行操做。

注意：除了上面這種檢測方法，其實%ZK_HOME%/bin也有其它腳本，下面這個命令執行後，就進入了zookeeper樹狀結構的文件系統中。

1. ./zkCli.sh

複製代碼
另外，還有一種方式，可以查看ZK服務器當前狀態，以下，這個可以很好的看出目前這個機器的運行狀況了：

1. $ echo stat|nc localhost 2181 
2. Zookeeper version: 3.4.3-1240972, built on 02/06/2012 10:48 GMT 
3. Clients: 
4. /127.0.0.1:40293[0](queued=0,recved=1,sent=0) 
5.  
6. Latency min/avg/max: 1/2/3 
7. Received: 4 
8. Sent: 3 
9. Outstanding: 0 
10. Zxid: 0×200000006 
11. Mode: leader 
12. Node count: 4

複製代碼

1.3單機模式的配置

若是你想安裝一個ZooKeeper來進行開發測試，一般可使用單機模式來啓動ZK。大致的步驟和上面說的是同樣了，除了配置文件會更加簡單一些。詳細的配置方法能夠查看這裏：http://zookeeper.apache.org/doc/r3.4.3/zookeeperStarted.html#sc_InstallingSingleMode

 

2.運 維

本章節主要要講述如何更好地運維ZooKeepr，大體包含如下幾部份內容：

   2.1. 部署方案的設計

   2.2. 平常運維

   2.3. Server的自檢恢復

   2.4. 監控

   2.5. 日誌管理

   2.6. 數據加載出錯

   2.7. 配置參數詳解

   2.8. 經常使用的四字命令

   2.9. 數據文件管理

   2.10. 注意事項

 

2.1 部署方案的設計

咱們常說的ZooKeeper可以提供高可用分佈式協調服務，是要基於如下兩個條件：

    1. 集羣中只有少部分的機器不可用。這裏說的不可用是指這些機器或者是自己down掉了，或者是由於網絡緣由，有一部分機器沒法和集羣中其它絕大部分的機器通訊。例如，若是ZK集羣是跨機房部署的，那麼有可能一些機器所在的機房被隔離了。

   2. 正確部署ZK server，有足夠的磁盤存儲空間以及良好的網絡通訊環境。

下面將會從集羣和單機兩個維度來講明，幫助zookeeper管理員儘量地提升ZK集羣的可用性。

 

2.1.1集羣維度

在上面提到的「過半存活便可用」特性中已經講到過，整個集羣若是對外要可用的話，那麼集羣中必需要有過半的機器是正常工做而且彼此之間可以正常通訊。基於這個特性，那麼若是想搭建一個可以容許F臺機器down掉的集羣，那麼就要部署一個由2xF+1 臺機器構成的ZK集羣。所以，一個由3臺機器構成的ZK集羣，可以在down掉一臺機器後依然正常工做，而5臺機器的集羣，可以對兩臺機器down掉的狀況容災。注意，若是是一個6臺機器構成的ZK集羣，一樣只可以down掉兩臺機器，由於若是down掉3臺，剩下的機器就沒有過半了。基於這個緣由，ZK集羣一般設計部署成奇數臺機器。

 

因此，爲了儘量地提升ZK集羣的可用性，應該儘可能避免一大批機器同時down掉的風險，換句話說，最好可以爲每臺機器配置互相獨立的硬件環境。舉個例子，若是大部分的機器都掛在同一個交換機上，那麼這個交換機一旦出現問題，將會對整個集羣的服務形成嚴重的影響。其它相似的還有諸如：供電線路，散熱系統等。其實在真正的實踐過程當中，若是條件容許，一般都建議嘗試跨機房部署。畢竟多個機房同時發生故障的機率仍是挺小的。

 

2.1.2 單機維度

對於ZK來講，若是在運行過程當中，須要和其它應用程序來競爭磁盤，CPU，網絡或是內存資源的話，那麼總體性能將會大打折扣。

 

首先來看看磁盤對於ZK性能的影響。客戶端對ZK的更新操做都是永久的，不可回退的，也就是說，一旦客戶端收到一個來自server操做成功的響應，那麼這個變動就永久生效了。爲作到這點，ZK會將每次更新操做以事務日誌的形式寫入磁盤，寫入成功後纔會給予客戶端響應。明白這點以後，你就會明白磁盤的吞吐性能對於ZK的影響了，磁盤寫入速度制約着ZK每一個更新操做的響應。爲了儘可能減小ZK在讀寫磁盤上的性能損失，不仿試試下面說的幾點：

   A、使用單獨的磁盤做爲事務日誌的輸出（好比咱們這裏的ZK集羣，使用單獨的掛載點用於事務日誌的輸出）。事務日誌的寫性能確實對ZK性能，尤爲是更新操做的性能影響很大，因此想辦法搞到一個單獨的磁盤吧！ZK的事務日誌輸出是一個順序寫文件的過程，自己性能是很高的，因此儘可能保證不要和其它隨機寫的應用程序共享一塊磁盤，儘可能避免對磁盤的競爭。

 

   B、儘可能避免內存與磁盤空間的交換。若是但願ZK可以提供徹底實時的服務的話，那麼基本是不容許操做系統觸發此類swap的。所以在分配JVM堆大小的時候必定要很是當心，具體在本文最後的「注意事項」章節中有講到。

 

2.2 平常運維

對zookeeper運維是一個長期積累經驗的過程，但願如下幾點對廣大ZK運維人員有必定的幫助：

 

2.2.1 清理數據目錄

上文中提到dataDir目錄指定了ZK的數據目錄，用於存儲ZK的快照文件（snapshot）。另外，默認狀況下，ZK的事務日誌也會存儲在這個目錄中。在完成若干次事務日誌以後（在ZK中，凡是對數據有更新的操做，好比建立節點，刪除節點或是對節點數據內容進行更新等，都會記錄事務日誌），ZK會觸發一次快照（snapshot），將當前server上全部節點的狀態以快照文件的形式dump到磁盤上去，即snapshot文件。這裏的若干次事務日誌是能夠配置的，默認是100000，具體參看下文中關於配置參數「snapCount」的介紹。

 

考慮到ZK運行環境的差別性，以及對於這些歷史文件，不一樣的管理員可能有本身的用途（例如做爲數據備份），所以默認ZK是不會自動清理快照和事務日誌，須要交給管理員本身來處理。這裏是咱們用的清理方法，保留最新的66個文件，將它寫到crontab中，天天凌晨2點觸發一次：

1. #!/bin/bash 
2.  
3. #snapshot file dir 
4. dataDir=/home/yinshi.nc/test/zk_data/version-2 
5. #tran log dir 
6. dataLogDir=/home/yinshi.nc/test/zk_log/version-2 
7. #zk log dir 
8. logDir=/home/yinshi.nc/test/logs 
9. #Leave 66 files 
10. count=66 
11. count=$[$count+1] 
12. ls -t $dataLogDir/log.* | tail -n +$count | xargs rm -f 
13. ls -t $dataDir/snapshot.* | tail -n +$count | xargs rm -f 
14. ls -t $logDir/zookeeper.log.* | tail -n +$count | xargs rm -f 
15.  
16. #find /home/yinshi.nc/taokeeper/zk_data/version-2 -name 「snap*」 -mtime +1 | xargs rm -f 
17. #find /home/yinshi.nc/taokeeper/zk_logs/version-2 -name 「log*」 -mtime +1 | xargs rm -f 
18. #find /home/yinshi.nc/taokeeper/logs/ -name 「zookeeper.log.*」 -mtime +1 | xargs rm –f

複製代碼
其實，僅管ZK沒有自動幫咱們清理歷史文件，可是它的仍是提供了一個叫PurgeTxnLog的 工具類，實現了一種簡單的歷史文件清理策略，能夠在這裏看一下他的使用方法：http://zookeeper.apache.org/doc/r3.4.3/api/index.html簡單使用以下：

1. java -cp zookeeper.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf org.apache.zookeeper.server.PurgeTxnLog<dataDir><snapDir> -n <count>

複製代碼

最後一個參數表示但願保留的歷史文件個數，注意，count必須是大於3的整數。能夠把這句命令寫成一個定時任務，以便天天定時執行清理。

注意： 從3.4.0版本開始， zookeeper提供了本身清理歷史文件的功能了，相關的配置參數是autopurge.snapRetainCount和autopurge.purgeInterval，在本文後面會具體說明。更多關於zookeeper的日誌清理，能夠閱讀這個文章《ZooKeeper日誌清理》。

 

2.2.2 ZK程序日誌

這裏說兩點，ZK默認是沒有向ROLLINGFILE文件輸出程序運行時日誌的，須要咱們本身在conf/log4j.properties中配置日誌路徑。另外，沒有特殊要求的話，日誌級別設置爲INFO或以上，我曾經測試過，日誌級別設置爲DEBUG的話，性能影響很大！

 

2.3 Server的自檢恢復

ZK運行過程當中，若是出現一些沒法處理的異常，會直接退出進程，也就是所謂的快速失敗（fail fast）模式。在上文中有提到，「過半存活便可用」的特性使得集羣中少數機器down掉後，整個集羣仍是能夠對外正常提供服務的。另外，這些down掉的機器重啓以後，可以自動加入到集羣中，而且自動和集羣中其它機器進行狀態同步（主要就是從Leader那裏同步最新的數據），從而達到自我恢復的目的。

所以，咱們很容易就能夠想到，是否能夠藉助一些工具來自動完成機器的狀態檢測與重啓工做。回答是確定的，這裏推薦兩個工具： Daemontools(http://cr.yp.to/daemontools.html) 和 SMF（http://en.wikipedia.org/wiki/Service_Management_Facility），可以幫助你監控ZK進程，一旦進程退出後，可以自動重啓進程，從而使down掉的機器可以從新加入到集羣中去~

 

2.4 監控

有幾種方法：

    一、 ZK提供一些簡單可是功能強大的4字命令，經過對這些4字命令的返回內容進行解析，能夠獲取很多關於ZK運行時的信息。

    二、用jmx也可以獲取一些運行時信息，詳細能夠查看這裏：http://zookeeper.apache.org/doc/r3.4.3/zookeeperJMX.html

    三、淘寶網已經實現的一個ZooKeeper監控——TaoKeeper，已開源，在這裏：http://rdc.taobao.com/team/jm/archives/1450，主要功能以下:

       A、機器CPU/MEM/LOAD的監控

       B、ZK日誌目錄所在磁盤空間監控

       C、單機鏈接數的峯值報警

       D、單機Watcher數的峯值報警

       E、節點自檢

       F、ZK運行時信息展現

 

2.5 日誌管理

ZK使用log4j做爲日誌系統，conf目錄中有一份默認的log4j配置文件，注意，這個配置文件中尚未開啓ROLLINGFILE文件輸出，配置下便可。其它關於log4j的詳細介紹，能夠移步到log4j的官網：http://logging.apache.org/log4j/1.2/manual.html#defaultInit

 

2.6加載數據出錯

ZK在啓動的過程當中，首先會根據事務日誌中的事務日誌記錄，從本地磁盤加載最後一次提交時候的快照數據，若是讀取事務日誌出錯或是其它問題（一般在日誌中能夠看到一些IO異常），將致使server將沒法啓動。碰到相似於這種數據文件出錯致使沒法啓動服務器的狀況，通常按照以下順序來恢復：

    一、確認集羣中其它機器是否正常工做，方法是使用「stat」這個命令來檢查：echo stat|nc ip 2181

    二、若是確認其它機器是正常工做的（這裏要說明下，所謂正常工做仍是指集羣中有過半機器可用），那麼能夠開始刪除本機的一些數據了，刪除$dataDir/version-2和$dataLogDir/version-2 兩個目錄下的全部文件。

重啓server。重啓以後，這個機器就會從Leader那裏同步到最新數據，而後從新加入到集羣中提供服務。

 

2.7 配置參數詳解(主要是%ZOOKEEPER_HOME%/conf/zoo.cfg文件)

參數名	說明
clientPort	客戶端鏈接server的端口，即對外服務端口，通常設置爲2181吧。
dataDir	存儲快照文件snapshot的目錄。默認狀況下，事務日誌也會存儲在這裏。建議同時配置參數dataLogDir, 事務日誌的寫性能直接影響zk性能。
tickTime	ZK中的一個時間單元。ZK中全部時間都是以這個時間單元爲基礎，進行整數倍配置的。例如，session的最小超時時間是2*tickTime。
dataLogDir	事務日誌輸出目錄。儘可能給事務日誌的輸出配置單獨的磁盤或是掛載點，這將極大的提高ZK性能。 （No Java system property）
globalOutstandingLimit	最大請求堆積數。默認是1000。ZK運行的時候， 儘管server已經沒有空閒來處理更多的客戶端請求了，可是仍是容許客戶端將請求提交到服務器上來，以提升吞吐性能。固然，爲了防止Server內存溢出，這個請求堆積數仍是須要限制下的。 (Java system property:?zookeeper.globalOutstandingLimit.)
preAllocSize	預先開闢磁盤空間，用於後續寫入事務日誌。默認是64M，每一個事務日誌大小就是64M。若是ZK的快照頻率較大的話，建議適當減少這個參數。(Java system property:zookeeper.preAllocSize)
snapCount	每進行snapCount次事務日誌輸出後，觸發一次快照(snapshot), 此時，ZK會生成一個snapshot.*文件，同時建立一個新的事務日誌文件log.*。默認是100000.（真正的代碼實現中，會進行必定的隨機數處理，以免全部服務器在同一時間進行快照而影響性能）(Java system property:zookeeper.snapCount)
traceFile	用於記錄全部請求的log，通常調試過程當中可使用，可是生產環境不建議使用，會嚴重影響性能。(Java system property:requestTraceFile)
maxClientCnxns	單個客戶端與單臺服務器之間的鏈接數的限制，是ip級別的，默認是60，若是設置爲0，那麼代表不做任何限制。請注意這個限制的使用範圍，僅僅是單臺客戶端機器與單臺ZK服務器之間的鏈接數限制，不是針對指定客戶端IP，也不是ZK集羣的鏈接數限制，也不是單臺ZK對全部客戶端的鏈接數限制。指定客戶端IP的限制策略，這裏有一個patch，能夠嘗試一下：http://rdc.taobao.com/team/jm/archives/1334（No Java system property）
clientPortAddress	對於多網卡的機器，能夠爲每一個IP指定不一樣的監聽端口。默認狀況是全部IP都監聽clientPort指定的端口。New in 3.3.0
minSessionTimeoutmaxSessionTimeout	Session超時時間限制，若是客戶端設置的超時時間不在這個範圍，那麼會被強制設置爲最大或最小時間。默認的Session超時時間是在2 * tickTime ~ 20 * tickTime這個範圍 New in 3.3.0
fsync.warningthresholdms	事務日誌輸出時，若是調用fsync方法超過指定的超時時間，那麼會在日誌中輸出警告信息。默認是1000ms。(Java system property:fsync.warningthresholdms) New in 3.3.4
autopurge.purgeInterval	在上文中已經提到，3.4.0及以後版本，ZK提供了自動清理事務日誌和快照文件的功能，這個參數指定了清理頻率，單位是小時，須要配置一個1或更大的整數，默認是0，表示不開啓自動清理功能。(No Java system property) New in 3.4.0
autopurge.snapRetainCount	這個參數和上面的參數搭配使用，這個參數指定了須要保留的文件數目。默認是保留3個。(No Java system property) New in 3.4.0
electionAlg	在以前的版本中， 這個參數配置是容許咱們選擇leader選舉算法，可是因爲在之後的版本中，只會留下一種「TCP-based version of fast leader election」算法，因此這個參數目前看來沒有用了，這裏也不詳細展開說了。(No Java system property)
initLimit	Follower在啓動過程當中，會從Leader同步全部最新數據，而後肯定本身可以對外服務的起始狀態。Leader容許F在initLimit時間內完成這個工做。一般狀況下，咱們不用太在乎這個參數的設置。若是ZK集羣的數據量確實很大了，F在啓動的時候，從Leader上同步數據的時間也會相應變長，所以在這種狀況下，有必要適當調大這個參數了。(No Java system property)
syncLimit	在運行過程當中，Leader負責與ZK集羣中全部機器進行通訊，例如經過一些心跳檢測機制，來檢測機器的存活狀態。若是L發出心跳包在syncLimit以後，尚未從F那裏收到響應，那麼就認爲這個F已經不在線了。注意：不要把這個參數設置得過大，不然可能會掩蓋一些問題。(No Java system property)
leaderServes	默認狀況下，Leader是會接受客戶端鏈接，並提供正常的讀寫服務。可是，若是你想讓Leader專一於集羣中機器的協調，那麼能夠將這個參數設置爲no，這樣一來，會大大提升寫操做的性能。(Java system property: zookeeper.leaderServes)。
server.x=[hostname]:nnnnn[:nnnnn]	這裏的x是一個數字，與myid文件中的id是一致的。右邊能夠配置兩個端口，第一個端口用於F和L之間的數據同步和其它通訊，第二個端口用於Leader選舉過程當中投票通訊。 (No Java system property)
group.x=nnnnn[:nnnnn]weight.x=nnnnn	對機器分組和權重設置，能夠 參見這裏(No Java system property)
cnxTimeout	Leader選舉過程當中，打開一次鏈接的超時時間，默認是5s。(Java system property: zookeeper.cnxTimeout)
zookeeper.DigestAuthenticationProvider .superDigest	ZK權限設置相關，具體參見《使用super身份對有權限的節點進行操做》 和 《ZooKeeper權限控制》
skipACL	對全部客戶端請求都不做ACL檢查。若是以前節點上設置有權限限制，一旦服務器上打開這個開頭，那麼也將失效。(Java system property:zookeeper.skipACL)
forceSync	這個參數肯定了是否須要在事務日誌提交的時候調用FileChannel.force來保證數據徹底同步到磁盤。(Java system property:zookeeper.forceSync)
jute.maxbuffer	每一個節點最大數據量，是默認是1M。這個限制必須在server和client端都進行設置纔會生效。(Java system property:jute.maxbuffer)

 

2.8 經常使用的四字命令

 

conf:

輸出server的詳細配置信息。New in 3.3.0

1. [        DISCUZ_CODE_513        ]gt;echo conf|nc localhost 2181 
2. clientPort=2181 
3. dataDir=/home/test/taokeeper/zk_data/version-2 
4. dataLogDir=/test/admin/taokeeper/zk_log/version-2 
5. tickTime=2000 
6. maxClientCnxns=1000 
7. minSessionTimeout=4000 
8. maxSessionTimeout=40000 
9. serverId=2 
10. initLimit=10 
11. syncLimit=5 
12. electionAlg=3 
13. electionPort=3888 
14. quorumPort=2888 
15. peerType=0

複製代碼
cons:

輸出指定server上全部客戶端鏈接的詳細信息，包括客戶端IP，會話ID等。 New in 3.3.0相似於這樣的信息：

1. [        DISCUZ_CODE_514        ]gt;echo cons|nc localhost 2181 
2. /1.2.3.4:43527[1](queued=0,recved=152802,sent=152806,sid=0x2389e662b98c424,lop=PING,est=1350385542196,to=6000,lcxid=0×114,lzxid=0xffffffffffffffff,lresp=1350690663308,llat=0,minlat=0,avglat=0,maxlat=483)
3. ……

複製代碼
crst:

功能性命令。重置全部鏈接的統計信息。New in 3.3.0

 

dump:

這個命令針對Leader執行，用於輸出全部等待隊列中的會話和臨時節點的信息。

 

envi:

用於輸出server的環境變量。包括操做系統環境和Java環境。

 

ruok:

用於測試server是否處於無錯狀態。若是正常，則返回「imok」,不然沒有任何響應。 注意：ruok不是一個特別有用的命令，它不能反映一個server是否處於正常工做。「stat」命令更靠譜。

 

stat

輸出server簡要狀態和鏈接的客戶端信息。

srvr
和stat相似，New in 3.3.0

1. [        DISCUZ_CODE_580        ]gt;echo stat|nc localhost 2181 
2. Zookeeper version: 3.3.5-1301095, built on 03/15/2012 19:48 GMT 
3. Clients: 
4. /10.2.3.4:59179[1](queued=0,recved=44845,sent=44845) 
5.  
6. Latency min/avg/max: 0/0/1036 
7. Received: 2274602238 
8. Sent: 2277795620 
9. Outstanding: 0 
10. Zxid: 0xa1b3503dd 
11. Mode: leader 
12. Node count: 37473

複製代碼

1. [        DISCUZ_CODE_581        ]gt;echo srvr|nc localhost 2181 
2. Zookeeper version: 3.3.5-1301095, built on 03/15/2012 19:48 GMT 
3. Latency min/avg/max: 0/0/980 
4. Received: 2592698547 
5. Sent: 2597713974 
6. Outstanding: 0 
7. Zxid: 0xa1b356b5b 
8. Mode: follower 
9. Node count: 37473

複製代碼
srst:
重置server的統計信息。


wchs:
列出全部watcher信息概要信息，數量等：New in 3.3.0

1. 列出全部watcher信息概要信息，數量等：New in 3.3.0

複製代碼
wchc:
出全部watcher信息，以watcher的session爲歸組單元排列，列出該會話訂閱了哪些path：New in 3.3.0

1. [        DISCUZ_CODE_583        ]gt;echo wchc|nc localhost 2181 
2. 0x2389e662b97917f 
3. /mytest/test/path1/node1 
4. 0x3389e65c83cd790 
5. /mytest/test/path1/node2 
6. 0x1389e65c7ef6313 
7. /mytest/test/path1/node3 
8. /mytest/test/path1/node1 
9.  

複製代碼
wchp
列出全部watcher信息，以watcher的path爲歸組單元排列，列出該path被哪些會話訂閱着：New in 3.3.0

1. [        DISCUZ_CODE_584        ]gt;echo wchp|nc localhost 2181 
2. /mytest/test/path1/node 
3. 0x1389e65c7eea4f5 
4. 0x1389e65c7ee2f68 
5. /mytest/test/path1/node2 
6. 0x2389e662b967c29 
7. /mytest/test/path1/node3 
8. 0x3389e65c83dd2e0 
9. 0x1389e65c7f0c37c 
10. 0x1389e65c7f0c364

複製代碼注意，wchc和wchp這兩個命令執行的輸出結果都是針對session的，對於運維人員來講可視化效果並不理想，能夠嘗試將cons命令執行輸出的信息整合起來，就能夠用客戶端IP來代替會話ID了，具體能夠看這個實現：http://rdc.taobao.com/team/jm/archives/1450

mntr:
輸出一些ZK運行時信息，經過對這些返回結果的解析，能夠達到監控的效果。New in 3.4.0

1. $ echo mntr | nc localhost 2185 
2. zk_version 3.4.0 
3. zk_avg_latency 0 
4. zk_max_latency 0 
5. zk_min_latency 0 
6. zk_packets_received 70 
7. zk_packets_sent 69 
8. zk_outstanding_requests 0 
9. zk_server_state leader 
10. zk_znode_count 4 
11. zk_watch_count 0 
12. zk_ephemerals_count 0 
13. zk_approximate_data_size 27 
14. zk_followers 4 – only exposed by the Leader 
15. zk_synced_followers 4 – only exposed by the Leader 
16. zk_pending_syncs 0 – only exposed by the Leader 
17. zk_open_file_descriptor_count 23 – only available on Unix platforms 
18. zk_max_file_descriptor_count 1024 – only available on Unix platforms

複製代碼



 

2.9 數據文件管理

默認狀況下，ZK的數據文件和事務日誌是保存在同一個目錄中，建議是將事務日誌存儲到單獨的磁盤上。

 

2.9.1數據目錄

ZK的數據目錄包含兩類文件：

    A、myid – 這個文件只包含一個數字，和server id對應。

    B、snapshot. - 按zxid前後順序的生成的數據快照。

集羣中的每臺ZK server都會有一個用於唯一標識本身的id，有兩個地方會使用到這個id：myid文件和zoo.cfg文件中。myid文件存儲在dataDir目錄中，指定了當前server的server id。在zoo.cfg文件中，根據server id，配置了每一個server的ip和相應端口。Zookeeper啓動的時候，讀取myid文件中的server id，而後去zoo.cfg 中查找對應的配置。

zookeeper在進行數據快照過程當中，會生成 snapshot文件，存儲在dataDir目錄中。文件後綴是zxid，也就是事務id。（這個zxid表明了zk觸發快照那個瞬間，提交的最後一個事務id）。注意，一個快照文件中的數據內容和提交第zxid個事務時內存中數據近似相同。僅管如此，因爲更新操做的冪等性，ZK仍是可以從快照文件中恢復數據。數據恢復過程當中，將事務日誌和快照文件中的數據對應起來，就可以恢復最後一次更新後的數據了。

 

2.9.2事務日誌目錄

dataLogDir目錄是ZK的事務日誌目錄，包含了全部ZK的事務日誌。正常運行過程當中，針對全部更新操做，在返回客戶端「更新成功」的響應前，ZK會確保已經將本次更新操做的事務日誌寫到磁盤上，只有這樣，整個更新操做纔會生效。每觸發一次數據快照，就會生成一個新的事務日誌。事務日誌的文件名是log.，zxid是寫入這個文件的第一個事務id。

 

2.9.3文件管理

不一樣的zookeeper server生成的snapshot文件和事務日誌文件的格式都是一致的（不管是什麼環境，或是什麼樣的zoo.cfg 配置）。所以，若是某一天生產環境中出現一些古怪的問題，你就能夠把這些文件下載到開發環境的zookeeper中加載起來，便於調試發現問題，而不會影響生產運行。另外，使用這些較舊的snapshot和事務日誌，咱們還可以方便的讓ZK回滾到一個歷史狀態。

另外，ZK提供的工具類LogFormatter可以幫助可視化ZK的事務日誌，幫助咱們排查問題，關於事務日誌的能夠化，請查看這個文章《可視化zookeeper的事務日誌》.

須要注意的一點是，zookeeper在運行過程當中，不斷地生成snapshot文件和事務日誌，可是不會自動清理它們，須要管理員來處理。（ZK自己只須要使用最新的snapshot和事務日誌便可）關於如何清理文件，上面章節「平常運維」有提到。

 

2.10 注意事項

2.10.1 保持Server地址列表一致

    A、客戶端使用的server地址列表必須和集羣全部server的地址列表一致。（若是客戶端配置了集羣機器列表的子集的話，也是沒有問題的，只是少了客戶端的容災。）

    B、集羣中每一個server的zoo.cfg中配置機器列表必須一致。

 

2.10.2 獨立的事務日誌輸出

對於每一個更新操做，ZK都會在確保事務日誌已經落盤後，纔會返回客戶端響應。所以事務日誌的輸出性能在很大程度上影響ZK的總體吞吐性能。強烈建議是給事務日誌的輸出分配一個單獨的磁盤。

 

2.10.3 配置合理的JVM堆大小

確保設置一個合理的JVM堆大小，若是設置太大，會讓內存與磁盤進行交換，這將使ZK的性能大打折扣。例如一個4G內存的機器的，若是你把JVM的堆大小設置爲4G或更大，那麼會使頻繁發生內存與磁盤空間的交換，一般設置成3G就能夠了。固然，爲了得到一個最好的堆大小值，在特定的使用場景下進行一些壓力測試。