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/l
og4j-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/l
og4j-1.2.15.jar:conf:src/java/lib/jline-0.9.94.jar \ org.apache.zookeeper.ZooKeep
erMain -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 r
m -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/log
4j-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 監控
有幾種方法：
1 、 ZK 提供一些簡單但是功能強大的 4 字命令，通過對這些 4 字命令的返回內容進行解析，可以獲取
不少關於 ZK 運行時的信息。
2、用 jmx 也能夠獲取一些運行時信息，詳細可以查看這裏：
http://zookeeper.apache.org/doc/r3.4.3/zookeeperJMX.html
3、淘寶網已經實現的一個 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 將無法
啓動。碰到類似於這種數據文件出錯導致無法啓動服務器的情況，一般按照如下順序來恢復：
1、確認集羣中其它機器是否正常工作，方法是使用―stat‖這個命令來檢查：echo stat|nc ip 2181
2、如果確認其它機器是正常工作的（這裏要說明下，所謂正常工作還是指集羣中有過半機器可用），
那麼可以開始刪除本機的一些數據了，刪除$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. $>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. $>echo cons|nc localhost 2181
2. /1.2.3.4:43527[1](queued=0,recved=152802,
3. sent=152806,sid=0x2389e662b98c424,lop=PING,
4. est=1350385542196,to=6000,
5. lcxid=0×114,lzxid=0xffffffffffffffff,lresp=1350690663308,llat=0,minlat=0,avglat=0,maxlat=483)
6. ……
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. $>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. $>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. $>echo wchs|nc localhost 2181
2. 3890 connections watching 537 paths
3. Total watches:6909
wchc
列出所有 watcher 信息，以 watcher 的 session 爲歸組單元排列，列出該會話訂閱了哪些 path：New in 3.3.0
1. $>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
wchp
列出所有 watcher 信息，以 watcher 的 path 爲歸組單元排列，列出該 path 被哪些會話訂閱着：New in 3.3.0
1. $>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 就可以了。當然，爲了獲得一個最好的