部署
這部分包含了部署ZooKeeper的信息和覆蓋這些話題
- 系統要求
- 集群(多服務)安裝
- 單服務和開發者安裝
前兩部分假定你對在例如數據中心的生產環境安裝ZooKeeper有興趣。最后一部分包含你在一個有限的基礎上安裝ZooKeeper的情況 - 為了評估，測試，或者開發 - 但是不在生產環境 。
系統要求
支持的平台
- GNU/Linux作為服務端和客戶端的開發和生產平台被支持
- Sun Solaris作為服務端和客戶端的開發和生產平台被支持
- FreeBSD作為服務端和客戶端的開發和生產平台被支持
- Win32作為服務端和客戶端的開發平台被支持
- Win64作為服務端和客戶端的開發平台被支持
- MacOX作為服務端和客戶端的開發平台被支持
軟件要求
ZooKeepr運行在java 發行版本1.6或更高(JDK 6 或更高，FreeBSD支持需要openjdk7)。它作為一個ZooKeeper服務器集成運行。三個ZooKeeper服務端是建議的集群最小了數量，我們也建議他們運行在不同的機器上。在Yahoo!，ZooKeeper通常被布置在專用的RHEL上面。一個雙核的處理器，2GM的內在，和80G的硬盤。
集群(多個服務端)安裝
為了ZooKeeer服務更可靠，你應該在集群中部署ZooKeeper,只要集群中的大多數運行起來，服務就是可用的。因為ZooKeer需要一個大多數，最好用一個奇數的機器。例如，用四台機器ZooKeeeperk只能處理一個機器故障。如果兩台機器失效，剩下的兩台不能組成大多數。然而，用五台機器ZooKeeper可能處理2台機器失效。
注意:
就像在入門指南中提到的，最少需要三個服務端對於一個容錯集群安裝，並且強烈建議你有奇數個服務端。
通常三台服務端對生產環境安裝是夠的，但是在維護期間為了最大化的可靠性，你可能想要安裝五台服務端。對於三台服務端，如果你在其中一台上執行維修，在維修期間其中一台將會是容易失效的。如果你有五台運行的服務，你可以讓一台停掉來維修。
並且知道如果其它四台中和一台突然失效也是ok的。
你的冗余考慮應該包含你的環境的所有方面。如果你有三個ZooKeeper服務端，但是他們的網線都插入到同一個網絡交換機上面，那么交換機的失敗將掛掉你整個集群。
這里是安裝集群中一個服務端的步驟。這些步驟應該在集群中的每一個主機上執行:
- 安裝Java JDK。你可以使用本地的系統包，或從http://java.sun.com/javase/downloads/index.jsp下載
- 設置Java 堆大小。這對於避免交換很重要。交換將嚴重降低ZooKeeper的性能。為了決定正確的。使用壓力測試，並且確保引起交換的限制的下面。保守起見 - 對於4G內在的機器，使用最多3G的堆內存。
- 安裝ZooKeeper服務端安裝包。它可以從http://zookeeper.apache.org/releases.html 下載。
- 創建配置文件。這個文件可以是任何名字。使用下面的設置作為開始:
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
你可以找到這些和其它設置的含義在Configuration Parameters部分。
每一個機器是ZooKeeper集群的一部分。他們應該知道集群中的其它機器。你使用server.id=host:port:port這樣的形式來達到這樣的目的。參數host和port是直觀的。你通過創建一個名字為myid的文件來區分每一台機器的服務id,每一服務端一個，它放在服務端的配置文件指定的dataDir的參數的數據目錄下。
5. myid文件包含一個單行文本，它的值是機器的id。所以服務端1的myid將包含文本"1"而沒有其它。這個id必須在集群中是唯一的並且是一個1到255之間的值。
6. 如果設置 好了你的配置文件，你可以啟動一個ZooKeeper服務:$ java -cp zookeeper.jar:lib/slf4j-api-1.7.5.jar:lib/slf4j-log4j12-1.7.5.jar:lib/log4j-1.2.16.jar:conf \ org.apache.zookeeper.server.quorum.QuorumPeerMain zoo.cfg
QuorumPeerMain啟動一個ZooKeeper服務，JMX管理beans也被注冊，它允許通過一個JMX管理控制台來管理。ZooKeeper JMX document 包含關於用JMX管理ZooKeeper的詳細內容。
參考包含在發行版本中的bin/zkServer.sh腳本來啟動服務端實例的例子。
7. 通過連接到主機來測試你的部署：
-
- 在Java,你可以運行下面的運行來執行簡單的操作：
$ java -cp zookeeper.jar:lib/slf4j-api-1.7.5.jar:lib/slf4j-log4j12-1.7.5.jar:lib/log4j-1.2.16.jar:conf:src/java/lib/jline-2.11.jar \ org.apache.zookeeper.ZooKeeperMain -server 127.0.0.1:2181
你可以程序給你的shell來執行簡單的類似文件系統的操作。為了使用多線程的客戶端連接ZooKeeper，你可以運行：$ cli_mt 127.0.0.1:2181
單一服務器和開發者安裝
如果你為了開發目的安裝ZooKeeper。你將可能想安裝一個ZooKeeper的服務實例，然后安裝Java或c的客戶端庫在你的開發機器上。
安裝一個服務實例的步驟和上面的相似，除了配置文件更簡單。你可以找到完整的操作指南在ZooKeeper Getting Started Guide的 Installing and Running ZooKeeper in Single Server Mode部分。
更多關於安裝客戶端庫的信息，參考 ZooKeeper Programmer's Guide的 Bindings部分
管理
這部分包含關於運行和維護ZooKeeper的信息並且包含這些主題：
- 設計一個ZooKeeper部署
- 准備
- 考慮的事：ZooKeeper的長處和局限性
- 管理
- 維護
- 監督
- 監測
- 日志
- 故障排除
- 配置參數
- ZooKeeper命令
- 數據文件管理
- 避免的事
- 最佳實踐
設計一個ZooKeeper部署
ZooKeeper的可靠性基於兩個假設。
- 只有部署中的一小部分將失效。在這里失效是指機器崩潰，或網絡的一些問題使一個服務端和其它的隔離開來。
- 正確地部署機器。正確操作是正確地執行代碼，使時間正常地工作，並且使存儲和網絡組件執行一致。
下面包含的部分對於ZooKeeper管理員來說是最大限度地認為這些假設是成立的。一些是跨機器的考慮，其它是一些你應該為每一台機器考慮的事情。
跨機器的要求
為了做ZooKeeper服務活躍，必須有大多數的機器可以彼此通信。為了構建一個可以容忍F台機器失效的部署，你應該部署2×F+1台機器。因此，一個包含三台機器的部署可以處理一個失效，一外包含5台機器的部署可以處理2台失效。注意一個6台機器的部署只能處理2個失效因為3台機器不是大多數。因為這個原因，ZooKeeper部署通常由奇數個機器組成。
為了達到最大可能地容忍失效，你應該試着使機器失效獨立地。例如，如果大部分機器用相同的交換機，交換機的失效將引起相互關聯的失效並且使服務掛掉。對於使用相同的電源，空調系統也一樣。
單機要求
如果ZooKeeper不得不和其它應用競爭像存儲設置，CPU,網絡或內在的資源，它的性能將受到顯著影響。ZooKeeper具有很強的持久性保證，這意為它使用存儲設置來記錄改變在負責改變的操作完成之前。你應該意識到這個依賴，並且照顧好它，如果你想保證ZooKeeper的操作不被你的存在設置掛起。這里有一些你可以做的事情來減小這種下降。
- ZooKeeper的事務日志必須在一個專門的設備上(一個專門的分區是不夠的)ZooKeeper順序地寫日志，沒有尋找，共享你的日志設備和其它進程可能引起尋找和競爭，這可能導致幾秒的延遲。
- 不要把ZooKeeepr放到一個引起交換的位置。為了使ZooKeeper運行的及時性，簡單地不能允許它交換。因些，確保給ZooKeeper分配最大堆的大小不比真實的內存大。關於這點的更多內容，參考下面的 Things to Avoid。
Provisioning
Things to Consider: ZooKeeper Strengths and Limitations
Administering
官網關於上面這個主題沒有內容
維護
對於ZooKeeper的集群的長時間的維護是必要的，然而你必須注意以下事情：
正在進行的數據目錄清理
ZooKeeper的數據目錄包含的文件是存儲在特定服務集群中的znode的持久化副本。他們是快照和事務日志文件。當對znode做了改變，這些改變被附加到一個事務日志里，有時候，當一個日志增大，當前所有 znode的狀態的快照將被 寫到文件系統中。
這個快照取代所有先前的日志。
ZooKeeper服務端將不會刪除老的快照和日志文件。當使用默認的配置時(參考下面的自動清除)，這是操作者的責任。每一個服務端環境是不同的因此管理這些文件的要求也不盡相同()。
PurgeTxnLo工具實現了一個管理者可以使用的簡單的保留策略。API文檔包含了調用規則的詳細信息(參數，等等)。
在下面的例子最后幾個快照和他們相應的日志被保留並且其它的被刪除。<count>的值通常應該大於3(盡管不是很必要,這提供了三個備份,在不可能的情況下，最近一個已經被破壞)。這可以在ZooKeeper服務端的機器上運行一個定時任務來每天清除日志。
java -cp zookeeper.jar:lib/slf4j-api-1.7.5.jar:lib/slf4j-log4j12-1.7.5.jar:lib/log4j-1.2.16.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir> <snapDir> -n <count>
自動清除快照和它對應的日志文件在ZooKeeper3.4中被引入並且可以通過下面的參數開啟。autopurge.snapRetainCount 和autopurge.purgeInterval，關於這方面更多信息，請參考下面的Advanced Configuration。
調試日志清除(log4j)
參考這個文檔關於logging的部分。它假設你使用log4j內置的特性設置一個滾動文件附加器。。conf/log4j.properties里的配置例子提供了這樣的一個例子。
監督
你將想要一個監督進程來管理你所有的ZooKeeper服務端進程，ZK服務端被設計成快速失敗的。意為着它將關閉(進程退出)如果它遇到一個不能恢復的錯誤。一個ZK服務集群是高度可靠的，意為着它當一個服務掛掉的時候，集群作為一個整體還是可以活躍和處理請求。另外，因為集群是"自治愈的"，失效的服務端啟動后將自動地加入集群而不任何人為干預。
檢測
ZooKeeper服務可以被檢測用兩種主要的方式；1)通過使用4字母單詞的命令 2)JMX參考適當的部分為你的需求。
日志
ZooKeeper使用版本為1.2的log4j作為它的日志框架。ZooKeeper默認的log4j.properties文件存在conf目錄下面。Log4j要求log4jproperties要么在工作目錄下(ZooKeeper運行的目錄)，要么可以在類路徑下被訪問。
關於更多信息，參考log4j手冊的Log4j Default Initialization Procedure
故障排除
服務沒有起來因為文件損壞
一個服務可能不能讀它的數據庫並且不能啟動因為一些ZooKeeper服務的事務日志文件損壞。你將看到一些IOException在載入Zookeeper數據庫的時候。在這樣的情況下，確保你集群中所有其它服務端啟動起來並且工作。在命令端口使用“stat”命令查看是否他們處於健康狀態。在你檢測所有其它服務端都起來后，你可以繼續並且清理壞掉的服務端的數據庫。刪除datadir/version-2目錄下的所有文件和datalogdir/version-2/。重啟服務。
配置參數
ZooKeeper的行為由ZooKeeper的配置文件支配。這個文件被設計，所以完全相同的文件可以被ZooKeeper集群中的所有服務端使用，假設他們的硬盤分布是一樣的。如果服務端使用不同的配置文件，必須特別小心確保所有的服務端和他們的配置文件想匹配。
注意:
在3.5和最新的,其中一些參數應該被放在動態配置文件中，如果他們放在靜態的配置文件中，ZooKeeper將自動地把他們移動到動態配置文件中。參考Dynamic Reconfiguration來獲取更多的信息。
最小配置
這里是在配置文件中必須被定義的最小的配置關鍵字：
clientPort
監聽客戶端連接的端口;也就是說，客戶端試圖連接的端口
dataDir
ZooKeeper將存儲內在數據庫快照的地方，除非另外指定，也是數據庫更新的事務日志的地方。
注意
小心你在那里放你的事務日志。一個專門的事務日志存儲設備是一致好性能的關鍵。把日志放到忙的設置上將嚴重影響性能。
tickTime
一個tick的長度，ZooKeeper使用的最基本的時間單位，以毫秒為單位。它被用來管理心跳，超時。例如，最小的會話超時是兩個tick.
高級配置
這部分的配置是可選的。你可以使用他們進一步地調試ZooKeeper服務端的行為。其中一些可以使用Java系統參數來設置，通常以zookeeper.keyword的格式。對於系統參數，當可用時，被標注出來在下面。
dataLogDir(不是Java系統參數)
這個選項將指導機器寫事務日志到dataLogDir而不是dataDir。這允許一個專門的日志設備被使用，並且幫助避免在日志和快照之間的沖突。
注意：
有一個專門的日志設備對吞吐量和延遲有一個大的影響。強烈建議指定一個日志設備並且設置dataLogDir來指到這個設備的目錄，並且確保dataDir的目錄不是在這個設備上。
globalOutstandingLimit（Java system property: zookeeper.globalOutstandingLimit）
客戶端可以更快地提交請求比ZooKeeper處理他們，特別是有很多客戶端的時候。為了避免因為排隊的請求使ZooKeeper內在溢出，ZooKeeper將控制客戶端，使在系統中沒有多於globalOutstandingLimit 個沒有處理的請求。默認的限制是1000。
preAllocSize（Java system property: zookeeper.preAllocSize）
為了避免以preAllocSize千字節的塊尋找ZooKeeper分配空間在事務日志文件。默認的塊大小是64M。改變這個塊大小的原因是減小塊大小如果快照被經常拿走。（同時參考snapCount）.
snapCount (Java system property: zookeeper.snapCount)
ZooKeeper記錄事務到一個事務日志中。在snapCount個事務被寫入到一個日志文件中，一個快照被開始一個新的事務日志文件被創建。默認的snapCount 是100000。
traceFile(Java system property: requestTraceFile)
如果這個選項被定義，請求將被記錄到一個名字為traceFile.year.month.day的追蹤文件中。這個選項的使用提供了有用的調試信息，但是將影響性能。（注意：系統參數沒有zookeeper前綴，並且配置變量參數名系統參數是不同的。）
maxClientCnxns(No Java system property)
限制被IP地址標識的一個客戶端同時連接的數量。這被用來阻止DoS一類的攻擊。包含文件描述符消耗。默認的是60。設置為0就公完全地刪除了同時連接的數量限制。
clientPortAddress
3.3.0新增內容：監聽客戶連接的地址(ipv4,ipv6或者主機名);也就是說，客戶端試圖連接的地址。這是可選的，默認地我們以這樣的方式綁定，任何到clientPort的連接將被服務端接受。
minSessionTimeout(No Java system property)
3.3.0新增內容，服務端允許的客戶端最小的會話超時時間。默認是2倍的tickTime.
maxSessionTimeout(No Java system property)
3.3.0新增內容：服務端允許的客戶端最大的會話超時時間。默認是20倍的tickTime.
fsync.warningthresholdms(Java system property: fsync.warningthresholdms)
3.3.4新增內容：當fsync事務日志花費時間超過這個值，將輸出一個警告信息到日志文件中。這個被默認是1000毫秒。這個值只能作為系統參數被設置。
autopurge.snapRetainCount(No Java system property)
3.4.0新增內容：當啟用的時候，ZooKeeper自動清除特性保留最近的autopurge.snapRetainCount個快照和相應的事務日志並且刪除其它的。默認是3。最小值是3。
autopurge.purgeInterval(No Java system property)
3.4.0新增內容：清除任務被觸發的以小時為間隔的時間。設置一個正數來啟用自動清除特性。默認是0。
syncEnabled(Java system property: zookeeper.observer.syncEnabled)
3.4.6，3.5.0新增內容：觀察者記錄事務並且寫快照到磁盤上就像一個參與者。這減小了重啟時觀察者的恢復時間。設置“false”來關閉這個特性。默認是true.
集群選項
這部分的選項是為集群使用設置的 -- 也就是說，部署服務集群。
electionAlg(No Java system property)
使用的選舉實現。0值對應着原來UDP-based版本。1對應着 快速領導選舉的non-authenticated UDP-based的版本。2對應着快速領導選舉的authenticated UDP-based的版本。3對應着快速領導選舉的TCP-based版本。當前，3是默認的。
注意
0,1,2的領導選舉的實現已經過時。在下一個版本我們打算刪除它們，那時只有 FastLeaderElection 可用。
initLimit(No Java system property)
時間的值，以ticks為單位（參考tickTime）,允許追隨者與領導者連接和同步。如果需要增加這個值，如果被ZooKeeper管理的數據量比較大。
leaderServes(Java system property: zookeeper.leaderServes)
領導者接受客戶端連接。默認值是“yes”。領導者機器協調更新。為了更高的更新吞吐量同步，領導者可以被設置成不接受接受客戶端連接並且集中協調。這個選項的默認值是yes,意為領導者接受客戶端連接。
注意：
開啟領導者選擇是強烈建議的，當在你的集群當中有多於三台ZooKeeper的時候。
server.x=[hostname]:nnnnn[:nnnnn]等等(No Java system property)
組成ZooKeeper集群的服務端。當服務端啟動。它確定它是那一台服務器通過在數據目錄中尋找myid文件。這個文件包含服務號，並且它應該和這個配置左邊的server.x的x想匹配。
組成ZooKeeper集群的客戶端使用服務列表必須和每一個ZooKeeper服務端擁有的服務列表相匹配。
這里有兩個端口號nnnnn。第一個追隨者用來連接領導者，每二個是為了領導者選舉。領導選舉的端口只有在electionAlg是1，2，或3的時候才是必須的。如果electionAlg是0，第二個端口不是必須的。如果你想在一台機器上測試 多個服務，那么不同的端口可以被每一個服務端使用。
syncLimit(No Java system property)
時間數量，以ticks為單位，允許追隨者和ZooKeeper同步，如果追隨者和領導者拉開距離太大，它們將被丟掉。
group.x=nnnnn[:nnnnn](No Java system property)
啟用分層法定人數結構。“x"是一個組標識符，並且”=“后面的數字和服務器標識符對應。左邊的是一個冒號分割的服務標識號。注意組必須不相交的，並且所有組的單位必須是ZooKeeper集群。
你也可以在這里找到例子
weight.x=nnnnn(No Java system property)
和”group“一塊使用，在組成法定人數的時候給一個服務端分配一個權重。當投票的時候這個值和服務端的重要程序相對應。有一部分ZooKeeper要求投票例如領導者選擇和原子傳播協議。默認的一個服務端的權重是1。如果配置了組，而不是權重，那么1的值將分配給所有的服務端。
你可以在這里找到例子。
cnxTimeout(Java system property: zookeeper.cnxTimeout)
設置為領導者選舉通知打開連接的超時時間。只在如果你的electionAlg為3的時候才是可用的。
注意
默認值是5秒
standaloneEnabled(No Java system property)
3.5.0新增內容：當設置false的時候，一個單獨的服務端可以以復制模式啟動，一個參與者可以和觀察者運行，並且一個集群可以重新配置為一個節點，並且從一個節點啟動。這個默認值是true為了向后兼容。它可以被設置通過QuorumPeerConfig的setStandaloneEnabled方法，或通過在服務端的配置文件中增加 "standaloneEnabled=false" 或 "standaloneEnabled=true"。
認證和授權選項
這部分的選項可能控制被服務端執行的認證和授權。
zookeeper.DigestAuthenticationProvider.superDigest(Java system property only: zookeeper.DigestAuthenticationProvider.superDigest)
默認這個特性是關閉的
3.2中新增內容：允許ZooKeeper集群管理者訪問znode分層結構作為超級用戶。特別是被授權為超級用戶沒有ACL檢查。
org.apache.zookeeper.server.auth.DigestAuthenticationProvider可以被用來生成superDigest，用一個參數"super:<password>"調用它。提供生成的 "super:<data>"作為系統參數當啟動每一個集群中的服務端。
當授權(從ZooKeeper客戶端)一個ZooKeeper服務端傳遞一個"digest"的方案和"super:<password>"的授權數據時。注意digest auth以明文傳遞authdata給服務端，這應該謹慎使用這個授權方法在localhost(不通過網絡)或通過一加密的連接。
實驗性選項/特性
被現在認為是實驗性的新特性。
只讀模式的服務端(Java system property: readonlymode.enabled)
3.4.0中新增內容：設置這個值為true來使服務端支持只讀模式(默認是關閉的)。ROM允許請求ROM支持的客戶端連接連接到一個服務端即使服務端可能被隔離了從法定人數中。
在 這個模式下，客戶端將仍然讀數據從ZK服務端，但是將不會寫數據和看到從其它客戶端的改變。更多信息請參考 ZOOKEEPER-784。
不安全的選項
下面的選項可能非常有用，但使用的時候要小心。第一個的風險和這個參考能做什么一塊講解。
forceSync(Java system property: zookeeper.forceSync)
在更新完成處理之前要求更新同步到事務日志上。如果這個選項設置為no,ZK將不要求更新被同步到設備上。
jute.maxbuffer:(Java system property: jute.maxbuffer)
這個選項只能被作為Java 系統參數設置。它不是zookeeper前綴。它指定了可以被存在在znode中的數據的值。默認是0xfffff,或小於1M.如果這個選項被改變，系統參數必須被設置到所有的服務端和客戶端上，否則將會出現問題。這真是一個明智的檢查。ZooKeeper被設計成存儲以數據大小的順序存儲。
skipACL(Java system property: zookeeper.skipACL)
跳過ACL檢查。這可以提高吞吐量。但是對數據樹打開完全的訪問給所有人。
quorumListenOnAllIPs
當設置成true,ZK 服務端將在所有可用的ip地址上監聽所有的連接，並且不僅是在配置文件中的服務列表。它影響處理ZAB協議和快速領導者選舉協議的連接。默認是false。
禁用數據目錄自動創建
3.5中新增內容:ZK服務端的默認行為是在啟動的時候如果沒有不存在數據目錄，將會自動創建數據目錄。這可能是不方便的甚至是危險的在一些情況下。考慮這樣的情況，在運行的服務端上改變了一個配置，dataDir參數意外地改變了。ZK服務端被重啟后它將創建這個不存在的目錄並且開始服務 - 用一個空的znode命名空間。這種情況可能導致"腦裂"(例如，數據同時存在新的不合法的目錄和原來的合法數據存儲)。像這樣有一個關閉自動創建的行為選項將是好的。通常對於生產環境這這應該這樣做。不幸的是默認的行為不能被改變現在，因此這必須在案例上進行。
當運行zkServer.sh自動創建可以被關閉通過設置環境變量ZOO_DATADIR_AUTOCREATE_DISABLE為1。當直接從類文件運行ZK服務端這個可以被實現通過設置zookeeper.datadir.autocreate=false在java 命令行上，例如-Dzookeeper.datadir.autocreate=false
當這個特性被關閉，ZK服務端檢測到需要的目錄不存在，它將生成一個錯誤並拒絕啟動。
一個新的zkServer-initialize.sh被提供來支持這個新特性。如果自動創建被關閉，用戶必須先安裝ZK,然后創建數據目錄(潛在的事務日志目錄)，然后啟動服務。否則，正如在前面提到服務將不會啟動。運行zkServer-initialize.sh將創建需要的目錄，並且設置myid文件(可選的命令行參數)。這個腳本可以被使用即使自動創建特性沒有被使用，並對用戶來說有用當這個在過去是一個問題(安裝，包括創建myid文件)。注意這個腳本只確保數據目錄存在，它不創建配置文件，但是為了執行需要一個可用的配置文件。
性能調試選項
3.5.0中的新增內容：幾個子系統已經被重新設計來提高讀吞吐量。這包括NIO通信的多線程子系統和請求處理通道(提交處理器)。NIO是默認的客戶端/服務端通信 子系統。它的線程模型包括一個接受者線程，1-n個seleector線程和0-m socket I/O工作線程。在請求處理通道，系統可以被配置成一次處理多個讀請求同時保證相同的一致性保證(相同的會話，寫后讀)。提交處理者線程模型包括一個主線程和0-n個工作線程。
默認值是目的是實現在ZK機器上最大化的讀吞吐量。同時子系統需要足夠數量的線程來達到高峰的志吞吐量。
zookeeper.nio.numSelectorThreads(Java system property only: zookeeper.nio.numSelectorThreads)
3.5.0新增內容：NIO selector線程數量。最少需要一個selector線程。建議使用多於一個selector對於大量的客戶連接。默認值是sqrt( cpu核心數 / 2 )。
zookeeper.nio.numWorkerThreads(Java system property only: zookeeper.nio.numWorkerThreads)
3.5.0新增內容：NIO 工作者線程數量。如果被配置成0個工作者線程，selector線程直接使用socket I/O。默認值是2倍的cpu核心數。
zookeeper.commitProcessor.numWorkerThreads(Java system property only: zookeeper.commitProcessor.numWorkerThreads)
3.5.0新增內容：提交處理器工作線程的數量。如果配置成0個工作者線程，主線程將直接處理請求。默認值是cpu核心數量。
使用Netty框架來通信
3.4.0新增內容：Netty是一個基於NIO的客戶端/服務端通信框架，它為Java應用簡化(和直接使用NIO相比)了很多網絡層通信的復雜性。另外Netty框架內置支持加密(SSL)和授權(certificates).這些是可選的特性，並且可以被單獨地開啟和關閉。
在版本3.4之前，ZK總是直接使用NIO,然而在3.4和以后版本中，Netty被直持作為NIO的一個選項。NIO繼續是默認的，然則基於Netty通信可以被用來替換NIO通過設置環境變量 "zookeeper.serverCnxnFactory"為 "org.apache.zookeeper.server.NettyServerCnxnFactory"。你有設置客戶端或服務端的選項，通常你可能想兩個都設置，決定權再於你。
TBD(待定) - netty的調試選項 - 現在沒有netty的配置選項但我們應該增加一些。例如netty創建的讀工作者線程的最大值。
TBD - 怎么管理加密
TBD - 怎么管理證書
管理服務端配置
3.5.0新增內容：下面的選項用來設置 AdminServer
admin.enableServer(Java system property: zookeeper.admin.enableServer)
設置為false來關閉AdminServer。默認是開啟的。
admin.serverPort(Java system property: zookeeper.admin.serverPort)
內置的Jetty服務器監聽的端口。默認是8080。
admin.commandURL(Java system property: zookeeper.admin.commandURL)
用於列舉和發起的和root URL相關的命令的URL。默認是/commands。
ZK命令
四字母的單詞（The Four Letter Words）
ZK響應一組命令。每一個命令由四個字母組成。你在客戶端口通過telnet或nc發送命令給ZK。
三個更有趣的命令：‘stat’給出一些一般信息關於服務端和連接的客戶端，"srvr"和”cons“給出更詳細的信息關於服務端和客戶端。
conf 3.3.0新增：打印服務端配置的詳細信息。
cons 3.3.0新增: 列出連接到這個服務端的所有客戶端會話信息。包括發送和接收包的數量信息，會話id,操作延遲，最后執行的操作等等。
crst 3.3.0新增:重置所有連接的會話
dump 列出未處理的會話和臨時節點。這只在領導者上可用。
envi 打印服務端的詳細信息
ruok 檢測如果服務端運行在一個沒有錯誤的狀態。服務端將響應imok如果它正在運行。否則它將不會響應。
"imok"的響應不能表示服務端已經加入了法定人數。僅僅是服務進程是活躍的和綁定到了指定的客戶端口。使用"stat"來查看關於法定人數和客戶端連接的詳細信息。
srst 重置服務端的統計
srvr 3.3.0新增 列出服務端的詳細信息
stat 列出端和連接的客戶端的簡明信息
wchs 3.3.0新增 列出服務端的監視器的簡明信息
wchc 3.3.0新增 列出服務端的監視器的詳細信息，以會話分組。這輸出一個帶着相關監視器的會話列表。注意，根據監視器的數量，這個操作可能很耗時(也就是說影響服務端性能)，小心使用它。
wchp 3.3.0新增 列出服務端關於監視器的詳細信息，以路徑分組。這輸出一個帶着相關會話的路徑信息。注意，根據監視器的數量，這個操作可能很耗時(也就是說影響服務端性能)，小心使用它。
mntr 3.3.0新增 輸入可以被用來監視群集健康狀態的變量列表。
$ echo mntr | nc localhost 2185 zk_version 3.4.0 zk_avg_latency 0 zk_max_latency 0 zk_min_latency 0 zk_packets_received 70 zk_packets_sent 69 zk_outstanding_requests 0 zk_server_state leader zk_znode_count 4 zk_watch_count 0 zk_ephemerals_count 0 zk_approximate_data_size 27 zk_followers 4 - only exposed by the Leader zk_synced_followers 4 - only exposed by the Leader zk_pending_syncs 0 - only exposed by the Leader zk_open_file_descriptor_count 23 - only available on Unix platforms zk_max_file_descriptor_count 1024 - only available on Unix platforms
輸出兼容java屬性格式並且內容隨着時間可能有變化(加入新關鍵詞)。
注意：一些關鍵詞是平台有關的並且一些關鍵詞只對領導者暴露。
輸出包含多行，以下面的格式：
key \t value
這里有一個ruok的命令例子：
$ echo ruok | nc 127.0.0.1 5111 imok
AdminServer
3.5.0新增內容：AdminServer是一個內置的Jettry服務，它提供了一個HTTP接口為四字母單詞命令。默認的，服務被啟動在8080端口，並且命令被發起通過URL "/commands/[command name]",例如，http://localhost:8080/commands/stat。命令響應以JSON的格式返回。不像原來的協議，命令不是限制為四字母的名字，並且命令可以有多個名字。例如"stmk"可以被指定為"set_trace_mask"。為了查看所有可用命令的列表，指向一個瀏覽器的URL /commands (例如， http://localhost:8080/commands)。參考 AdminServer configuration options關於怎么改變端口和URLS。
AdminServer默認開啟，但是可以被關閉通過下面的方法：
- 設置系統屬性zookeeper.admin.enableServer為false.
- 從類路徑中移除Jetty.(這個選項是有用的如果你想覆蓋ZooKeeper的jetty依賴)。
注意TCP四字母單詞接口是仍然可用的如果AdminServer被關閉。
數據文件管理
ZK存儲它的數據在數據目錄和它的事務日志在事務日志目錄里，默認的這兩個目錄是相同的。服務端可以(應該)被配置成存儲事務日志文件到一個單獨的目錄而不是數據文件目錄。吞吐量上升和延遲減小當事務日志放在一個專門的日志設置上。
數據目錄
這個目錄有兩個文件：
- myid - 包含一個單獨的代表服務器id的數字
- snapshot.<zxid> - 保存數據樹的快照
每一個ZK服務端有一個唯一的id。這個id被用在兩個地方：myid文件和配置文件中。myid文件標識給定數據目錄的服務端。配置文件列出聯系信息為每一個被它的服務id標識的服務端。當一個ZK服務端實例啟動的時候，它從myid文件中讀它的id，然后使用這個id,從配置文件讀取找出它應該監視的端口，
存在數據目錄中的snapshot文件是模糊的快照，在這個意義上，在ZK服務端正在操作快照的時間內，更新也正在發生在數據樹上。snapshot文件的后綴是zxid，ZK的最后提交的事務id。因此snapshot包含對數據樹更新的一個字集在snapshot正在處理中的時候。snapshot可能不對應任何真實存在的數據樹，因為這個原因我們說它是模糊的快照。仍然ZK可以恢復使用這個快照因為它使用了更新的冪等特性。通過重新演義事務日志對模糊的快照，ZooKeeer獲取系統的狀態在日志的最后。
日志目錄
日志目錄包含ZK的事務日志。在任何更新發生之前，ZK確保代表這個更新的事務被寫入到存儲上。一個新的日志文件被開始每次一個快照被開始。日志文件的后綴寫到日志的第一個zxid。
文件管理
快照和日志文件格式不會改變在單獨的Zk服務器和不同配置的可復制的ZK服務器之間。因此，你可以從一個運行的可復制的ZK服務端把這個文件放到一個單機的ZK服務端的開發機器上來故障排除。
使用老的日志和快照文件，你可以找到先前的ZK服務端狀態甚至恢復這個狀態。 LogFormatter 類允許一個管理者來查看一個日志中的事務。
ZK服務端創建快照和日志文件，但是從不刪除他們。數據和日志文件的保留策略被實現在ZK服務端之外。服務端自己只需要最新完整的模糊快照和從快照開始的日志文件。參考這個文檔的 maintenance部分關於設置保留策略和ZK存儲的更詳細信息。
注意
這個文件中存的數據沒有被加密。在ZK中存儲敏感數據的情況下，需要采取必要的方法來防止未授權的訪問。這些方法是外部的對ZK來說。它取決於ZK部署的機器的單獨設置。
應該避免的事
這里有一些你可以通過正確設置配置文件來避免的普遍的問題：
不一致的服務端列表
被客戶端使用的服務端列表必須和每一個ZK服務端擁有的服務端列表相匹配。如果客戶端列表是一個真實列表的子集工作能正常進行。但事情將很奇怪如果客戶端有一個服務端列表和ZK集群的不一樣。同時在每一個ZK服務端配置文件中的服務端列表應該彼此一樣。
事務日志的不正確存放
ZK性能最關鍵的部分是事務日志。ZK同步事務日志到存儲設置上在它返回一個響應之前。一個專門的事務日志設置是一貫好性能的關鍵。把日志放到一個繁忙的劥上將嚴重地影響性能。如果你只有一個存儲設備，在NFS上存入追蹤文件並且 減小snapshotCount;它不能消除問題，但是能減輕它。
不正確的Java 堆大小
你應該特別小心，來正確地設置你的Java最大堆大小。特別是你不應試使用ZooKeeper交換到磁盤。磁盤對ZK來說是致命的。所有事都是有序的，所以如果處理一個請求交換磁盤，所有其它隊列中的請求將可能做同樣的事。對於磁盤，不要交換。
在你的估計中保持保守：如果你有一個4G的內在，不要設置Java最大堆大小為6G或4G，例如，你更應該使用一個3G的堆對於一個4G的機器，因為操作系統和緩存也需要內存。最好的和只是建議的行為來估計你的系統需要的堆大小是運行壓力測試，然后確保正好在可能引起系統交換的使用限制下面。
最佳實踐
為了最好的結果，重視下面Zk的最佳實踐列表：
對於多用戶安裝參考這個部分詳述ZK"chroot"支持，這非常有用當部署多個應用接口到一個單獨的ZK群集中。
插播個廣告
老丈人家的粉皮兒，農產品，沒有亂七八糟的添加劑，歡迎惠顧