部署与管理ZooKeeper
2019獨角獸企業重金招聘Python工程師標準>>>
部署與管理ZooKeeper 博客分類： zookeeper本文以ZooKeeper3.4.3版本的官方指南為基礎：http://zookeeper.apache.org/doc/r3.4.3/zookeeperAdmin.html，補充一些作者運維實踐中的要點，圍繞ZK的部署和運維兩個方面講一些管理員需要知道的東西。本文并非一個ZK搭建的快速入門，關于這方面，可以查看《ZooKeeper快速搭建》。
1.部署
本章節主要講述如何部署ZooKeeper，包括以下三部分的內容：
- 系統環境
- 集群模式的配置
- 單機模式的配置
系統環境和集群模式配置這兩節內容大體講述了如何部署一個能夠用于生產環境的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，按照如下這個簡單配置即可：
tickTime=2000
dataDir=/var/lib/zookeeper/
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888
本文后續章節會對這些參數進行詳細的介紹，這里只是簡單說幾點：集群中的每臺機器都需要感知整個集群是由哪幾臺機器組成的，在配置文件中，可以按照這樣的格式，每行寫一個機器配置：server.id=host:port:port. 關于這個id，我們稱之為Server ID，標識host機器在集群中的機器序號，在每個ZK機器上，我們需要在數據目錄（數據目錄就是dataDir參數指定的那個目錄）下創建一個myid文件，myid中就是這個Server ID數字。
在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了：
$ 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 中的腳本啟動即可。
./zkServer.sh start
7. 連接ZK host來檢驗部署是否成功。
->Java語言的話，可以通過運行這個命令來檢測：
$ 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
->如果是C語言的話，方法如下：
$ make cli_st
$ make cli_mt
然后按照的這樣的方式連接ZK：$ cli_mt 127.0.0.1:2181。無論運行哪種客戶端，最終都是一個類似于文件系統的命令行操作。
注意：除了上面這種檢測方法，其實%ZK_HOME%/bin也有其它腳本，下面這個命令執行后，就進入了zookeeper樹狀結構的文件系統中。
./zkCli.sh
另外，還有一種方式，能夠查看ZK服務器當前狀態，如下，這個能夠很好的看出目前這個機器的運行情況了：
$ echo stat|nc localhost 2181
Zookeeper version: 3.4.3-1240972, built on 02/06/2012 10:48 GMT
Clients:
/127.0.0.1:40293[0](queued=0,recved=1,sent=0)
Latency min/avg/max: 1/2/3
Received: 4
Sent: 3
Outstanding: 0
Zxid: 0×200000006
Mode: leader
Node count: 4
1.3單機模式的配置
如果你想安裝一個ZooKeeper來進行開發測試，通常可以使用單機模式來啟動ZK。大體的步驟和上面說的是一樣了，除了配置文件會更加簡單一些。詳細的配置方法可以查看這里：http://zookeeper.apache.org/doc/r3.4.3/zookeeperStarted.html#sc_InstallingSingleMode
2.運 維
本章節主要要講述如何更好地運維ZooKeepr，大致包含以下幾部分內容：
- 部署方案的設計
- 日常運維
- Server的自檢恢復
- 監控
- 日志管理
- 數據加載出錯
- 配置參數詳解
- 常用的四字命令
- 數據文件管理
- 注意事項
2.1部署方案的設計
我們常說的ZooKeeper能夠提供高可用分布式協調服務，是要基于以下兩個條件：
下面將會從集群和單機兩個維度來說明，幫助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在讀寫磁盤上的性能損失，不仿試試下面說的幾點：
- 使用單獨的磁盤作為事務日志的輸出（比如我們這里的ZK集群，使用單獨的掛載點用于事務日志的輸出）。事務日志的寫性能確實對ZK性能，尤其是更新操作的性能影響很大，所以想辦法搞到一個單獨的磁盤吧！ZK的事務日志輸出是一個順序寫文件的過程，本身性能是很高的，所以盡量保證不要和其它隨機寫的應用程序共享一塊磁盤，盡量避免對磁盤的競爭。
- 盡量避免內存與磁盤空間的交換。如果希望ZK能夠提供完全實時的服務的話，那么基本是不允許操作系統觸發此類swap的。因此在分配JVM堆大小的時候一定要非常小心，具體在本文最后的“注意事項”章節中有講到。
2.2日常運維
對zookeeper運維是一個長期積累經驗的過程，希望以下幾點對廣大ZK運維人員有一定的幫助：
- 清理數據目錄
上文中提到dataDir目錄指定了ZK的數據目錄，用于存儲ZK的快照文件（snapshot）。另外，默認情況下，ZK的事務日志也會存儲在這個目錄中。在完成若干次事務日志之后（在ZK中，凡是對數據有更新的操作，比如創建節點，刪除節點或是對節點數據內容進行更新等，都會記錄事務日志），ZK會觸發一次快照（snapshot），將當前server上所有節點的狀態以快照文件的形式dump到磁盤上去，即snapshot文件。這里的若干次事務日志是可以配置的，默認是100000，具體參看下文中關于配置參數“snapCount”的介紹。
考慮到ZK運行環境的差異性，以及對于這些歷史文件，不同的管理員可能有自己的用途（例如作為數據備份），因此默認ZK是不會自動清理快照和事務日志，需要交給管理員自己來處理。這里是我們用的清理方法，保留最新的66個文件，將它寫到crontab中，每天凌晨2點觸發一次：
#!/bin/bash
#snapshot file dir
dataDir=/home/yinshi.nc/test/zk_data/version-2
#tran log dir
dataLogDir=/home/yinshi.nc/test/zk_log/version-2
#zk log dir
logDir=/home/yinshi.nc/test/logs
#Leave 66 files
count=66
count=$[$count+1]
ls -t $dataLogDir/log.* | tail -n +$count | xargs rm -f
ls -t $dataDir/snapshot.* | tail -n +$count | xargs rm -f
ls -t $logDir/zookeeper.log.* | tail -n +$count | xargs rm -f
#find /home/yinshi.nc/taokeeper/zk_data/version-2 -name “snap*” -mtime +1 | xargs rm -f
#find /home/yinshi.nc/taokeeper/zk_logs/version-2 -name “log*” -mtime +1 | xargs rm -f
#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?簡單使用如下：
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日志清理》。
- 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 監控
有幾種方法：
- 機器CPU/MEM/LOAD的監控
- ZK日志目錄所在磁盤空間監控
- 單機連接數的峰值報警
- 單機Watcher數的峰值報警
- 節點自檢
- 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將無法啟動。碰到類似于這種數據文件出錯導致無法啟動服務器的情況，一般按照如下順序來恢復：
重啟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 ? $>echo conf|nc localhost 2181 |
| cons | 輸出指定server上所有客戶端連接的詳細信息，包括客戶端IP，會話ID等。 New in 3.3.0類似于這樣的信息： ? $>echo cons|nc localhost 2181 |
| 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 ? $>echo stat|nc localhost 2181 Latency min/avg/max: 0/0/1036 $>echo srvr|nc localhost 2181 |
| srst | 重置server的統計信息。 |
| wchs | 列出所有watcher信息概要信息，數量等：New in 3.3.0 ? $>echo wchs|nc localhost 2181 |
| wchc | 列出所有watcher信息，以watcher的session為歸組單元排列，列出該會話訂閱了哪些path：New in 3.3.0 ? $>echo wchc|nc localhost 2181 |
| wchp | 列出所有watcher信息，以watcher的path為歸組單元排列，列出該path被哪些會話訂閱著：New in 3.3.0 ? $>echo wchp|nc localhost 2181 注意，wchc和wchp這兩個命令執行的輸出結果都是針對session的，對于運維人員來說可視化效果并不理想，可以嘗試將cons命令執行輸出的信息整合起來，就可以用客戶端IP來代替會話ID了，具體可以看這個實現：http://rdc.taobao.com/team/jm/archives/1450 |
| mntr | 輸出一些ZK運行時信息，通過對這些返回結果的解析，可以達到監控的效果。New in 3.4.0 ? $ echo mntr | nc localhost 2185 |
2.9 數據文件管理
默認情況下，ZK的數據文件和事務日志是保存在同一個目錄中，建議是將事務日志存儲到單獨的磁盤上。
2.9.1數據目錄
ZK的數據目錄包含兩類文件：
- myid – 這個文件只包含一個數字，和server id對應。
- 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地址列表一致
- 客戶端使用的server地址列表必須和集群所有server的地址列表一致。（如果客戶端配置了集群機器列表的子集的話，也是沒有問題的，只是少了客戶端的容災。）
- 集群中每個server的zoo.cfg中配置機器列表必須一致。
2.10.2 獨立的事務日志輸出
對于每個更新操作，ZK都會在確保事務日志已經落盤后，才會返回客戶端響應。因此事務日志的輸出性能在很大程度上影響ZK的整體吞吐性能。強烈建議是給事務日志的輸出分配一個單獨的磁盤。
2.10.3 配置合理的JVM堆大小
確保設置一個合理的JVM堆大小，如果設置太大，會讓內存與磁盤進行交換，這將使ZK的性能大打折扣。例如一個4G內存的機器的，如果你把JVM的堆大小設置為4G或更大，那么會使頻繁發生內存與磁盤空間的交換，通常設置成3G就可以了。當然，為了獲得一個最好的堆大小值，在特定的使用場景下進行一些壓力測試。
?
轉自 ?http://rdc.taobao.com/team/jm/archives/2318
轉載于:https://my.oschina.net/xiaominmin/blog/1597600
總結
以上是生活随笔為你收集整理的部署与管理ZooKeeper的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spring MVC中使用Swagger
- 下一篇： maven 生命周期