zookeeper指南
部署和管理指南
· 部署
o 系統需求
§ 支持的平臺
§ 所需軟件
o 羣集(多服務器)設置
o 單一服務器和開發人員設置
· 管理
o 設計zookeeper部署
§ 跨機器要求
§ 單機需求
o 準備金提取
o 需要考慮的事情:zookeeper的優勢和侷限性
o 管理
o 保持
§ 正在進行的數據目錄清理
§ 調試日誌清理(log4j)
o 管理
o 監視
o 記錄
o 解決紛爭
o 配置參數
§ 最低配置
§ 高級配置
§ 集羣選項
§ 加密、身份驗證、授權選項
§ 實驗選項/功能
§ 不安全選項
§ 禁用數據目錄自動創建
§ 啓用數據庫存在驗證
§ 性能調整選項
§ 管理服務器配置
o 使用Netty框架進行溝通
§ 法定人數
§ 在不停機的情況下升級現有的非TLS羣集
o zookeeper命令
§ 四個字母單詞
§ 管理服務器
o 數據文件管理
§ 數據目錄
§ 日誌目錄
§ 文件管理
§ 恢復- TxnLogToolkit
o 需要避免的事情
o 最佳實踐
部署
本節包含有關部署zookeeper的信息，並涵蓋以下主題:
· 系統需求
· 羣集(多服務器)設置
· 單一服務器和開發人員設置
前兩部分假設您對在生產環境(如數據中心)中安裝ZooKeeper感興趣。最後一節介紹了在有限的基礎上建立ZooKeeper的情況——用於評估、測試或開發——但不是在生產環境中。
系統需求
支持的平臺
zookeeper由多個組件組成。一些組件得到廣泛支持，而其他組件只在一個較小的平臺上得到支持。
· 客戶是一個Java客戶端庫，應用程序使用它來連接到一個ZooKeeper集合。
· 服務器是運行在ZooKeeper集成節點上的Java服務器。
· 本地客戶端是一個用C實現的客戶端，類似於Java客戶端，被應用程序用來連接到ZooKeeper集合。
· 貢獻指多個可選的附加組件。
下表描述了在不同操作系統平臺上運行每個組件所承諾的支持級別。
支持矩陣
操作系統 | 客戶 | 服務器 | 本地客戶端 | 貢獻 |
GNU/Linux | 開發和生產 | 開發和生產 | 開發和生產 | 開發和生產 |
Solaris | 開發和生產 | 開發和生產 | 不支持 | 不支持 |
FreeBSD | 開發和生產 | 開發和生產 | 不支持 | 不支持 |
Windows | 開發和生產 | 開發和生產 | 不支持 | 不支持 |
Mac·OS X | 僅限發展 | 僅限發展 | 不支持 | 不支持 |
對於矩陣中未明確提到支持的任何操作系統，組件可能工作，也可能不工作。ZooKeeper社區將修復其他平臺報告的明顯缺陷，但是沒有完全的支持。
所需軟件
ZooKeeper運行在Java 1.7或更高版本(JDK 7或更高版本，FreeBSD支持需要openjdk7)。它作爲一個全體ZooKeeper服務器。三個ZooKeeper服務器是一個集合的最小推薦大小，我們還建議它們在不同的機器上運行。在雅虎！，ZooKeeper通常部署在專用的RHEL機箱上，配備雙核處理器、2GB內存和80GB IDE硬盤。
羣集(多服務器)設置
爲了獲得可靠的ZooKeeper服務，您應該在一個稱爲全體。只要大部分人都起來了，這項服務就可以用了。因爲zookeeper需要多數，所以最好使用奇數臺機器。例如，有四臺機器，ZooKeeper只能處理一臺機器的故障；如果兩臺機器出現故障，其餘兩臺機器不構成多數。然而，有了五臺機器，ZooKeeper可以處理兩臺機器的故障。
注意
如中所述zookeeper入門指南，容錯羣集設置至少需要三臺服務器，強烈建議您使用奇數臺服務器。
通常，三個服務器對於生產安裝來說已經足夠了，但是爲了在維護期間獲得最大的可靠性，您可能希望安裝五個服務器。對於三臺服務器，如果您在其中一臺服務器上執行維護，那麼在維護期間，您很容易在另外兩臺服務器中的一臺上出現故障。如果你有五個正在運行，你可以取下一個進行維護，並且知道如果另外四個中的一個突然出現故障，你仍然可以。
您的冗餘考慮應該包括您環境的所有方面。如果你有三個ZooKeeper服務器，但是它們的網絡電纜都插在同一個網絡交換機上，那麼這個交換機的故障會使你的整個系統癱瘓。
以下是設置服務器的步驟，服務器將成爲集合的一部分。這些步驟應該在集合中的每個主機上執行:
1. 安裝爪哇JDK。您可以將本機打包系統用於您的系統，或者從以下網址下載JDK:http://java.sun.com/javase/downloads/index.jsp
2. 設置Java堆的大小。這對於避免交換非常重要，交換會嚴重降低ZooKeeper的性能。要確定正確的值，請使用負載測試，並確保遠遠低於導致交換的使用限制。保守一點——4GB機器的最大堆大小爲3GB。
3. 安裝zookeeper服務器包。可從以下網站下載:http://zookeeper.apache.org/releases.html
4. 創建配置文件。這個文件可以被稱爲任何東西。使用以下設置作爲起點:
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
您可以在部分找到這些和其他配置設置的含義配置參數。這裏有幾個人想說一句話:zookeeper集合中的每一臺機器都應該知道集合中的其他每一臺機器。您可以通過表單的一系列行來實現這一點server.id =主機:端口:端口。參數宿主和港口很簡單。您可以通過創建名爲的文件將服務器id分配給每臺計算機myid，每個服務器一個，駐留在該服務器的數據目錄中，由配置文件參數指定數據目錄。
5. myid文件由一行僅包含該機器id的文本組成。因此myid服務器1的將包含文本“1”而沒有其他內容。id在集合中必須是唯一的，並且應該具有1到255之間的值。重要提示:如果啓用擴展功能，如TTL節點(見下文)，由於內部限制，id必須介於1和254之間。
6. 如果設置了配置文件，您可以啓動ZooKeeper服務器:
$ java -cp zookeeper.jar:lib/*:conf org.apache.zookeeper.server.quorum.QuorumPeerMain zoo.conf
QuorumPeerMain啓動一個zookeeper服務器，JMX還註冊了管理beans，允許通過JMX管理控制檯進行管理。這zookeeperJMX文件包含與JMX一起管理zookeeper的詳細信息。看劇本bin/zkServer.sh，它包含在發行版中，用於啓動服務器實例的示例。
1. 通過連接到主機來測試您的部署:在Java中，您可以運行以下命令來執行簡單的操作:
$ bin/zkCli.sh -server 127.0.0.1:2181
單一服務器和開發人員設置
如果您想爲開發目的設置ZooKeeper，您可能需要設置ZooKeeper的單個服務器實例，然後在您的開發機器上安裝Java或C客戶端庫和綁定。
設置單個服務器實例的步驟與上面類似，只是配置文件更簡單。您可以在在單服務器模式下安裝和運行ZooKeeper的部分zookeeper入門指南。
有關安裝客戶端庫的信息，請參閱粘合劑的部分zookeeper程序員指南。
管理
本節包含有關運行和維護ZooKeeper的信息，並涵蓋以下主題:
· 設計zookeeper部署
· 準備金提取
· 需要考慮的事情:zookeeper的優勢和侷限性
· 管理
· 保持
· 管理
· 監視
· 記錄
· 解決紛爭
· 配置參數
· zookeeper命令
· 數據文件管理
· 需要避免的事情
· 最佳實踐
設計zookeeper部署
zookeeper的可靠性基於兩個基本假設。
1. 部署中只有少數服務器會失敗。失敗在這種情況下，這意味着機器崩潰，或者網絡中的一些錯誤將服務器與大多數服務器隔離開來。
2. 部署的機器運行正常。正確操作意味着正確執行代碼，讓時鐘正常工作，讓存儲和網絡組件持續運行。
下面幾節包含了zookeeper的考慮事項，以最大化這些假設成立的可能性。其中一些是跨機器的考慮，其他的是您應該爲部署中的每一臺機器考慮的事情。
跨機器要求
要使ZooKeeper服務處於活動狀態，必須有大多數非故障機器能夠相互通信。要創建一個可以容忍F機器故障的部署，您應該依靠部署2xF+1機器。因此，由三臺機器組成的部署可以處理一個故障，而由五臺機器組成的部署可以處理兩個故障。請注意，六臺機器的部署只能處理兩臺故障，因爲三臺機器不是大多數。因此，ZooKeeper部署通常由奇數臺機器組成。
爲了獲得最大的容忍故障的可能性，你應該努力使機器故障獨立。例如，如果大多數機器共享同一個交換機，該交換機的故障可能會導致相關的故障並導致服務中斷。共享電源電路、冷卻系統等也是如此。
單機需求
如果ZooKeeper不得不與其他應用程序爭奪對存儲介質、中央處理器、網絡或內存等資源的訪問權，它的性能將會大打折扣。ZooKeeper有很強的持久性保證，這意味着它在負責變更的操作被允許完成之前，使用存儲介質記錄變更。那麼你應該意識到這種依賴性，如果你想確保ZooKeeper的操作不被你的媒體所阻礙，那就要非常小心。以下是您可以做的一些事情，以最大限度地減少這種退化:
· ZooKeeper的事務日誌必須在專用設備上。(專用分區是不夠的。)ZooKeeper按順序寫入日誌，而不尋求與其他進程共享您的日誌設備會導致尋道和爭用，這反過來又會導致多秒延遲。
· 不要將ZooKeeper置於可能導致交換的情況。爲了讓ZooKeeper以任何形式的及時性運行，它根本不能被允許交換。因此，確保給ZooKeeper的最大堆大小不大於ZooKeeper可用的實際內存量。有關這方面的更多信息，請參見需要避免的事情下面。
準備金提取
需要考慮的事情:zookeeper的優勢和侷限性
管理
保持
zookeeper集羣幾乎不需要長期維護，但是您必須注意以下幾點:
正在進行的數據目錄清理
動物園看守數據目錄包含由特定服務集合存儲的znodes的永久副本的文件。這些是快照和事務日誌文件。當對znodes進行更改時，這些更改會附加到事務日誌中。有時，當日志變大時，所有znodes的當前狀態的快照將被寫入文件系統，併爲將來的事務創建一個新的事務日誌文件。在快照期間，ZooKeeper可能會繼續將傳入的事務附加到舊的日誌文件中。因此，某些比快照更新的事務可能會在快照之前的最後一個事務日誌中找到。
zookeeper服務器不會刪除舊快照和日誌文件當使用默認配置時(見下面的自動敦促)，這是操作員的責任。每個服務環境都是不同的，因此管理這些文件的要求可能因安裝而異(例如備份)。
PurgeTxnLog實用程序實現了一個管理員可以使用的簡單保留策略。這原料藥包含調用約定(參數等)的詳細信息...)。
在以下示例中，保留最後一個計數快照及其對應的日誌，並刪除其他快照。的價值通常應大於3(雖然不是必需的，但這在最近的日誌損壞的情況下提供了3個備份)。這可以作爲一個cron作業在ZooKeeper服務器上運行，以便每天清理日誌。
java -cp zookeeper.jar:lib/slf4j-api-1.7.5.jar:lib/slf4j-log4j12-1.7.5.jar:lib/log4j-1.2.17.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir> <snapDir> -n <count>
快照和相應事務日誌的自動清除是在3.4.0版中引入的，可以通過以下配置參數啓用autopurge.snapRetainCount和autopurge.purgeInterval。有關這方面的更多信息，請參見高級配置下面。
調試日誌清理(log4j)
請參見中的一節記錄在這份文件中。預計您將使用內置的log4j功能設置一個滾動文件附加器。發佈tar的conf/log4j.properties中的示例配置文件提供了一個例子。
管理
您將希望有一個管理過程來管理您的每個ZooKeeper服務器進程(JVM)。ZK服務器被設計爲“快速故障”，這意味着如果出現無法恢復的錯誤，它將關閉(進程退出)。由於ZooKeeper服務集羣是高度可靠的，這意味着儘管服務器可能會關閉，但整個集羣仍然是活動的，並服務於請求。此外，由於集羣是“自我修復”的，故障服務器一旦重啓，將自動重新加入集羣，無需任何手動交互。
具有監督過程，例如daemontools或者SMF(管理進程的其他選項也是可用的，這取決於您想使用哪一個，這只是兩個例子)管理您的ZooKeeper服務器可以確保如果進程異常退出，它將自動重新啓動並快速重新加入集羣。
還建議將ZooKeeper服務器進程配置爲在發生OutOfMemoryError**時終止並轉儲其堆。這是通過在Linux和Windows上分別使用以下參數啓動JVM來實現的。這zkServer.sh和zkServer.cmdZooKeeper附帶的腳本設置了這些選項。
-XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p'
"-XX:+HeapDumpOnOutOfMemoryError" "-XX:OnOutOfMemoryError=cmd /c taskkill /pid %%%%p /t /f"
監視
ZooKeeper服務可以通過兩種主要方式之一進行監控；1)命令端口通過使用4個字母單詞和2)JMX。請參見適合您的環境/要求的部分。
記錄
zookeeper使用SLF4J版本1.7.5作爲其日誌記錄基礎設施。爲了向後兼容，它綁定到LOG4J但是你可以用日誌返回或者您選擇的任何其他受支持的日誌框架。
zookeeper默認log4j.properties文件駐留在conf目錄。Log4j要求log4j.properties要麼在工作目錄中(運行ZooKeeper的目錄)，要麼可以從類路徑訪問。
有關SLF4J的更多信息，請參見它的手冊。
有關LOG4J的更多信息，請參見Log4j默認初始化程序log4j手冊。
解決紛爭
· 由於文件損壞，服務器無法運行:服務器可能無法讀取其數據庫，並且由於ZooKeeper服務器的事務日誌中的某些文件損壞而無法啓動。你會看到一些加載zookeeper數據庫的異常。在這種情況下，請確保您的集羣中的所有其他服務器都正常工作。使用命令端口上的“stat”命令查看他們是否健康。在您驗證了集合中的所有其他服務器都已啓動之後，您可以繼續清理損壞服務器的數據庫。刪除datadir/version-2和datalogdir/version-2/中的所有文件。重新啓動服務器。
配置參數
管理員的行爲由管理員配置文件控制。假設磁盤佈局相同，該文件的設計使得組成ZooKeeper服務器的所有服務器都可以使用完全相同的文件。如果服務器使用不同的配置文件，必須注意確保所有不同配置文件中的服務器列表匹配。
注意
在3.5.0和更高版本中，其中一些參數應該放在動態配置文件中。如果它們被放在靜態配置文件中，ZooKeeper會自動將它們移到動態配置文件中。看見動態重構瞭解更多信息。
最低配置
以下是必須在配置文件中定義的最低配置關鍵字:
· clientPort:監聽客戶端連接的端口；也就是客戶端試圖連接的端口。
· 安全客戶端端口:使用SSL監聽安全客戶端連接的端口。clientPort指定明文連接的端口安全客戶端端口指定SSL連接的端口。指定兩者都啓用混合模式，而忽略其中一個將禁用該模式。請注意，當用戶將zoo keeper . ServerCnXnfactory . zoo keeper . ClientCnXnSocket作爲Netty插入時，將啓用SSL功能。
· 數據目錄:ZooKeeper將存儲內存中數據庫快照的位置，以及數據庫更新的事務日誌，除非另有指定。
注意
請小心放置事務日誌的位置。專用事務日誌設備是保持良好性能的關鍵。將日誌放在繁忙的設備上會對性能產生負面影響。
· tickTime:單個刻度的長度，它是ZooKeeper使用的基本時間單位，以毫秒爲單位。它用於調節心跳和超時。例如，最小會話超時將是兩個刻度。
高級配置
部分中的配置設置是可選的。您可以使用它們來進一步微調ZooKeeper服務器的行爲。有些也可以使用Java系統屬性來設置，通常是以下形式zookeeper .關鍵字。準確的系統屬性(如果可用)如下所示。
· 數據日誌目錄:(無Java系統屬性)此選項將指示計算機將事務日誌寫入數據日誌目錄而不是數據目錄。這允許使用專用日誌設備，並有助於避免日誌記錄和快照之間的競爭。
注意
擁有專用日誌設備對吞吐量和穩定延遲有很大影響。強烈建議使用專用的日誌設備和設置數據日誌目錄指向該設備上的目錄，然後確保指向數據目錄到目錄不駐留在那個設備上。
· globalOutstandingLimit:(Java系統屬性:zookeeper。)客戶提交請求的速度比ZooKeeper處理請求的速度快，尤其是在有很多客戶的情況下。爲了防止ZooKeeper因排隊請求而耗盡內存，ZooKeeper將限制客戶端，以便系統中沒有超過globalOutstandingLimit的未決請求。默認限制爲1，000。
· 預分配大小:(Java系統屬性:zookeeper.預分配大小)爲了避免查找，ZooKeeper在事務日誌文件中以預分配大小爲千字節的塊來分配空間。默認塊大小爲64M。更改數據塊大小的一個原因是，如果更頻繁地拍攝快照，可以減小數據塊大小。(另請參見快照計數)。
· 快照計數:(Java系統屬性:zookeeper。快照)ZooKeeper使用快照和事務日誌(想想預寫日誌)記錄它的事務。在拍攝快照(和滾動事務日誌)之前，事務日誌中記錄的事務數由快照計數決定。爲了防止仲裁中的所有機器同時拍攝快照，當事務日誌中的事務數量達到[快照計數/2+1，快照計數]範圍內運行時生成的隨機值時，每個ZooKeeper服務器將拍攝快照。默認快照計數爲100，000。
· maxClientCnxns:(無Java系統屬性)限制單個客戶端(通過IP地址標識)可以與ZooKeeper集合的單個成員建立的併發連接數(在套接字級別)。這用於防止特定類別的DoS攻擊，包括文件描述符耗盡。默認值爲60。將此設置爲0將完全取消對併發連接的限制。
· 客戶端端口地址：3.3.0中的新功能:偵聽客戶端連接的地址(ipv4、ipv6或主機名);也就是客戶端試圖連接的地址。這是可選的，默認情況下，我們以這樣的方式綁定clientPort對於服務器上的任何地址/接口/nic，都將被接受。
· minSessionTimeout:(沒有Java系統屬性)3.3.0中的新功能:服務器允許客戶端協商的最小會話超時時間(毫秒)。默認爲的2倍tickTime。
· maxSessionTimeout:(沒有Java系統屬性)3.3.0中的新功能:服務器允許客戶端協商的最大會話超時時間(毫秒)。默認爲的20倍tickTime。
· fsync.warningthresholdms:(Java系統屬性:zoo keeper . fsync . warningthresholdms)3.3.4中的新功能:每當事務日誌(WAL)中的fsync花費的時間超過該值時，就會向日志輸出一條警告消息。這些值以毫秒爲單位指定，默認值爲1000。該值只能設置爲系統屬性。
· autopurge.snapRetainCount:(沒有Java系統屬性)3.4.0中的新增功能:啓用後，ZooKeeper自動清除功能將保留autopurge.snapRetainCount中最近的快照和相應的事務日誌數據目錄和數據日誌目錄並刪除其餘部分。默認值爲3。最小值爲3。
· autopurge.purgeInterval:(沒有Java系統屬性)3.4.0中的新增功能:必須觸發清除任務的時間間隔(小時)。設置爲正整數(1及以上)以啓用自動清除。默認值爲0。
· 同步已啓用:(Java系統屬性:zookeeper.observer.syncEnabled)3.4.6、3.5.0中的新增功能:觀察者現在像參與者一樣默認記錄事務並將快照寫入磁盤。這減少了重啓時觀察器的恢復時間。設置爲“假”禁用此功能。默認值爲“真”
· zookeeper.extendedTypesEnabled:(僅限於Java系統屬性:zookeeper.extendedTypesEnabled)3.5.4中的新增功能:定義爲“真”，以啓用擴展功能，如創建TTL節點。默認情況下，它們是禁用的。重要提示:當啓用時，由於內部限制，服務器標識必須小於255。
· zoo keeper . simulate 353 tlnodes:(僅限於Java系統屬性:zoo keeper . simulate 353 tlnodes)3.5.4中的新功能:由於ZOOKEERE-3 . 5 . 3版中創建的2901 TTL節點在3.5.4/3.6.0中不受支持。但是，通過zoo keeper . simulate 353 tlnodes系統屬性提供了一種解決方法。如果您在ZooKeeper 3.5.3中使用了TTL節點，並且需要維護兼容性集zoo keeper . simulate 353 tlnodes除了“真”zookeeper.extendedTypesEnabled。注意:由於這個錯誤，服務器標識必須是127或更少。此外，最大支持TTL值爲1099511627775，小於3.5.3中允許的值(1152921504606846975)
· 服務器工廠:(Java系統屬性:zoo keeper . ServerCNxNFfactory)指定服務器工廠實現。這應該設置爲NettyServerCnxnFactory以便使用基於TLS的服務器通信。默認值爲NIOServerCnxnFactory。
集羣選項
本節中的選項設計用於服務器集成，即部署服務器集羣時。
· 選舉g:(沒有Java系統屬性)選擇要使用的實現。值“1”對應於快速領導者選舉的非認證的基於UDP的版本，“2”對應於快速領導者選舉的認證的基於UDP的版本，“3”對應於快速領導者選舉的基於TCP的版本。目前，算法3是默認的。
注意
領導者選舉1和2的實現現在是反對。我們打算在下一個版本中刪除它們，到那時只有FastLeaderElection可用。
· 極限極限:(無Java系統屬性)時間量，以刻度爲單位(請參見tickTime)，允許追隨者連接並同步到領導者。如果ZooKeeper管理的數據量很大，則根據需要增加該值。
· 領導服務:(Java系統屬性:zookeeper。**領導者服務* *)領導者接受客戶連接。默認值爲“是”。引導機協調更新。爲了以讀吞吐量爲代價獲得更高的更新吞吐量，可以將領導者配置爲不接受客戶端，而專注於協調。此選項的默認值爲“是”，這意味着領導者將接受客戶連接。
注意
當您在一個集合中有三個以上的ZooKeeper服務器時，強烈建議啓用領導者選擇。
· 服務器. x =[主機名]:[:等等:(沒有Java系統屬性)組成zookeeper集合的服務器。當服務器啓動時，它通過查找文件來確定它是哪個服務器myid在數據目錄中。該文件包含服務器號，以ASCII表示，並且應該匹配x在server.x在這個設置的左邊。客戶端使用的組成ZooKeeper服務器的服務器列表必須與每個ZooKeeper服務器擁有的ZooKeeper服務器列表相匹配。有兩個端口號nnnnn。第一個跟隨者用於連接到領導者，第二個用於領導者選舉。如果您想在一臺機器上測試多臺服務器，那麼每臺服務器可以使用不同的端口。
· 同步限制:(無Java系統屬性)時間量，以刻度爲單位(請參見tickTime)，允許追隨者與ZooKeeper同步。如果追隨者遠遠落後於領導者，他們就會被拋棄。
· [:nnnnn n]:(無Java系統屬性)啓用分層仲裁構造。“x”是組標識符,“=”符號後面的數字對應於服務器標識符。分配的左側是一個以冒號分隔的服務器標識符列表。請注意，組必須是不相交的，並且所有組的並集必須是ZooKeeper集合。你會找到一個例子這裏
· weight.x=nnnnn:(無Java系統屬性)與“組”一起使用，它在形成quorums時爲服務器分配一個權重。這樣的值對應於投票時服務器的重量。ZooKeeper有幾個部分需要投票，比如領導者選舉和原子廣播協議。默認情況下，服務器的重量爲1。如果配置定義了組，但沒有定義權重，則值1將分配給所有服務器。你會找到一個例子這裏
· cnxTimeout:(Java系統屬性:zookeeper。**cnxTimeout**)設置爲領導人選舉通知打開連接的超時值。僅適用於您正在使用第三代電子郵件的情況。
注意
默認值爲5秒。
· standaloneEnabled:(沒有Java系統屬性)3.5.0中的新功能:當設置爲false時，可以在複製模式下啓動單個服務器，一個單獨的參與者可以與觀察者一起運行，集羣可以向下重新配置到一個節點，從一個節點向上重新配置。對於向後兼容性，默認值爲真。可以使用QuorumPeerConfig的setStandaloneEnabled方法或通過在服務器的配置文件中添加“standaloneEnabled=false”或“standaloneEnabled=true”來設置。
· 重新配置已啓用:(沒有Java系統屬性)3.5.3中的新增功能:這控制的啓用或禁用動態重構特色。啓用該功能後，用戶可以通過ZooKeeper客戶端應用程序接口或ZooKeeper命令行工具執行重新配置操作，前提是用戶被授權執行此類操作。當該功能被禁用時，任何用戶(包括超級用戶)都不能執行重新配置。任何重新配置的嘗試都會返回一個錯誤。"重新配置已啓用"選項可以設置爲"重新配置啓用=假"或者"重新配置啓用=真"或者使用QuorumPeerConfig的setReconfigEnabled方法。默認值爲假。如果存在，該值應該在整個集合中的每臺服務器上保持一致。在某些服務器上將該值設置爲真，而在其他服務器上將該值設置爲假將導致不一致的行爲，具體取決於哪個服務器被選爲領導者。如果領導者的設置爲"重新配置啓用=真"，則集合將啓用重新配置功能。如果領導者的設置爲"重新配置啓用=假"，則集合將禁用重新配置功能。因此，建議具有一致的值"重新配置已啓用"集合中的服務器。
· 4lw.commands .白名單:(Java系統屬性:zookeeper.4lw.commands .白名單)3.5.3中的新增功能:逗號分隔的列表四個字母單詞用戶想要使用的命令。必須將有效的四個字母單詞命令放在該列表中，否則ZooKeeper服務器將不會啓用該命令。默認情況下，白名單隻包含zkServer.sh使用的“srvr”命令。默認情況下，其餘四個字母單詞命令被禁用。下面是一個配置示例，它啓用stat、ruok、conf和isro命令，同時禁用其餘的四個字母單詞命令:
4lw.commands.whitelist=stat, ruok, conf, isro
如果您真的需要在默認情況下啓用所有四個字母的word命令，您可以使用星號選項，這樣您就不必在列表中逐個包含每個命令。例如，這將啓用所有四個字母的單詞命令:
4lw.commands.whitelist=*
· tcpKeepAlive:(Java系統屬性:zookeeper.tcpKeepAlive)3.5.4中的新功能:將該值設置爲true會在法定成員用來執行選舉的套接字上設置TCP keepAlive標誌。這將允許法定成員之間的連接在網絡基礎設施中斷時保持正常。對於長時間運行或空閒的連接，一些網絡終端和防火牆可能會終止或失去狀態。啓用此選項依賴於操作系統級別設置才能正常工作，有關更多信息，請檢查您的操作系統中有關TCP保持活動的選項。默認爲錯誤的。
加密、身份驗證、授權選項
本節中的選項允許控制服務執行的加密/身份驗證/授權。
· digestauthenticationprovider . superdigest:(Java系統屬性:zookeeper。digestauthenticationprovider . super digest)默認情況下，此功能爲有缺陷的 3.2中的新功能:允許ZooKeeper集合管理員以“超級”用戶的身份訪問znode層次結構。特別是，對於被認證爲超級用戶的用戶，不會進行ACL檢查。org . Apache . zoo keeper . server . auth. DigestAuthenticationProvider可用於生成超級摘要，用一個參數“super:“。提供生成的"超級:"作爲系統屬性值。向ZooKeeper服務器(從ZooKeeper客戶端)進行身份驗證時，傳遞“摘要”方案和“超級:“。請注意，摘要式身份驗證以明文形式將身份驗證數據傳遞給服務器，謹慎的做法是僅在本地主機(而不是通過網絡)或加密連接上使用此身份驗證方法。
· X509AuthenticationProvider .超級用戶:(Java系統屬性:zookeeper。X509AuthenticationProvider .超級用戶)支持SSL的方式，使ZooKeeper集成管理員能夠作爲“超級”用戶訪問znode層次結構。當此參數設置爲X500主體名稱時，只有具有該主體的經過身份驗證的客戶端才能繞過ACL檢查，並對所有節點擁有完全權限。
· zookeeper .超級用戶:(Java系統屬性:zookeeper .超級用戶)類似於zookeeper。X509AuthenticationProvider .超級用戶但是對於基於SASL的登錄是通用的。它存儲可以作爲“超級”用戶訪問znode層次結構的用戶名。
· ssl.authProvider:(Java系統屬性:zookeeper.ssl.authProvider)指定的子類org . Apache . zoo keeper . auth . x509 authenticationprovider用於安全客戶端身份驗證。這在不使用JKS的證書密鑰基礎結構中很有用。可能有必要延長javax.net.ssl.X509KeyManager和javax.net.ssl.X509TrustManager從SSL堆棧中獲取所需的行爲。要將ZooKeeper服務器配置爲使用自定義提供程序進行身份驗證，請爲自定義身份驗證提供程序選擇一個方案名稱，並設置屬性zookeeper.授權提供商.[計劃]自定義實現的完全限定類名。這將把提供程序加載到提供程序註冊表中。然後設置這個屬性zookeeper. SSL . AuthProvider =[方案]該提供商將用於安全認證。
· sslQuorum:(Java系統屬性:zookeeper.sslQuorum)3.5.5中的新功能:啓用加密的法定通信。默認值爲錯誤的。
· ssl.keyStore.location和ssl.keyStore.password和ssl.quorum.keyStore.location和ssl.quorum.keyStore.password:(Java系統屬性:zoo keeper . SSL . KeyStore . location和zoo keeper . SSL . KeyStore . password和zoo keeper . SSL . quorum . KeyStore . location和zoo keeper . SSL . quorum . KeyStore . password)3.5.5中的新功能:指定包含用於客戶端和法定TLS連接的本地憑據的Java密鑰庫的文件路徑，以及解鎖文件的密碼。
· ssl.keyStore.type和ssl.quorum.keyStore.type:(Java系統屬性:zookeeper.ssl.keyStore.type和zoo keeper . SSL . quorum . KeyStore . type)3.5.5中的新功能:指定客戶端和仲裁密鑰庫的文件格式。值:JKS、PEM或空(通過文件名檢測)。默認值:空
· ssl.trustStore.location和ssl.trustStore.password和ssl.quorum.trustStore.location和ssl.quorum.trustStore.password:(Java系統屬性:zoo keeper . SSL . TrustStore . location和zoo keeper . SSL . TrustStore . password和zoo keeper . SSL . quorum . TrustStore . location和zoo keeper . SSL . quorum . TrustStore . password)3.5.5中的新功能:指定指向包含用於客戶端和法定TLS連接的遠程憑據的Java信任庫的文件路徑，以及解鎖文件的密碼。
· ssl.trustStore.type和ssl.quorum.trustStore.type:(Java系統屬性:zookeeper.ssl.trustStore.type和zoo keeper . SSL . quorum . TrustStore . type)3.5.5中的新功能:指定客戶端和法定信任庫的文件格式。值:JKS、PEM或空(通過文件名檢測)。默認值:空
· ssl.protocol和ssl.quorum.protocol:(Java系統屬性:zookeeper.ssl.protocol和zookeeper.ssl.quorum.protocol)3.5.5中的新功能:指定要在客戶端和法定TLS協商中使用的協議。默認值:TLSv1.2
· ssl.enabledProtocols和ssl.quorum.enabledProtocols:(Java系統屬性:zookeeper.ssl.enabledProtocols和zoo keeper . SSL . quorum . enabledprotocols)3.5.5中的新功能:指定在客戶端和法定TLS協商中啓用的協議。默認值:的值草案財產
· ssl .密碼套件和ssl.quorum .密碼套件:(Java系統屬性:zookeeper.ssl .密碼套件和zookeeper.ssl.quorum .密碼套件)3.5.5中的新功能:指定要在客戶端和法定TLS協商中使用的已啓用密碼套件。默認:啓用的密碼套件取決於使用的Java運行時版本。
· ssl.context.supplier.class和SSL . quorum . context . supplier . class:(Java系統屬性:zoo keeper . SSL . context . supplier . class和zoo keeper . SSL . quorum . context . supplier . class)3.5.5中的新功能:指定用於在客戶端和仲裁SSL通信中創建SSL上下文的類。這允許您使用自定義的SSL上下文並實現以下場景:
1. 使用硬件密鑰庫，使用PKCS11或類似工具加載。
2. 您沒有訪問軟件密鑰庫的權限，但是可以從它們的容器中檢索已經構建好的SSLContext。默認值:空
· SSL . hostname驗證和SSL . quorum . hostname驗證:(Java系統屬性:zoo keeper . SSL . hostname驗證和zoo keeper . SSL . quorum . hostname驗證)3.5.5中的新功能:指定在客戶端和法定TLS協商過程中是否啓用主機名驗證。僅出於測試目的，建議禁用它。默認值:真
· ssl.crl和ssl.quorum.crl:(Java系統屬性:zookeeper.ssl.crl和zookeeper.ssl.quorum.crl)3.5.5中的新功能:指定是否在客戶端和法定TLS協議中啓用證書吊銷列表。默認值:false
· ssl.ocsp和ssl.quorum.ocsp:(Java系統屬性:zookeeper.ssl.ocsp和zookeeper.ssl.quorum.ocsp)3.5.5中的新功能:指定是否在客戶端和法定TLS協議中啓用在線證書狀態協議。默認值:false
· ssl.clientAuth和ssl.quorum.clientAuth:(Java系統屬性:zookeeper.ssl.clientAuth和zoo keeper . SSL . quorum . ClientAuth)3.5.5中的新功能:TBD
· SSL . handshakedetectiontimeoutmillis和SSL . quorum . handshakedetectiontimeoutmillis:(Java系統屬性:zoo keeper . SSL . handshakedetetectontimeoutmillis和zoo keeper . SSL . quorum . handshakedetectureontimeoutmillis)3.5.5中的新功能:TBD
實驗選項/功能
目前被認爲是實驗性的新特性。
· 只讀模式服務器:(Java系統屬性:readonlymode.enabled)3.4.0中的新增功能:將此值設置爲true將啓用只讀模式服務器支持(默認情況下禁用)。只讀存儲器允許請求只讀存儲器支持的客戶端會話連接到服務器，即使服務器可能與法定人數相分離。在這種模式下，只讀存儲器客戶端仍然可以從ZK服務中讀取值，但不能寫入值和查看其他客戶端的更改。詳見ZOOKEEER-784。
不安全選項
以下選項可能有用，但在使用時要小心。每個變量的風險都和變量的作用一起被解釋。
· forceSync:(Java系統屬性:zookeeper.forceSync)要求在完成更新處理之前，將更新同步到事務日誌的媒體。如果此選項設置爲否，ZooKeeper將不要求更新同步到媒體。
· jute.maxbuffer::(Java系統屬性:**jute.maxbuffer**)此選項只能設置爲Java系統屬性。上面沒有zookeeper的前綴。它指定了一個znode中可以存儲的數據的最大大小。默認值爲0xfffff，或略低於1M。如果更改了此選項，則必須在所有服務器和客戶端上設置系統屬性，否則會出現問題。這真是一次明智的檢查。ZooKeeper被設計成以千字節爲單位存儲數據。
· skipACL:(Java系統屬性:zookeeper.skipACL)跳過ACL檢查。這提高了吞吐量，但也向每個人開放了對數據樹的完全訪問。
· quorumListenOnAllIPs:當設置爲真時，ZooKeeper服務器將偵聽所有可用的IP地址上來自其對等方的連接，而不僅僅是配置文件的服務器列表中配置的地址。它會影響處理ZAB協議和快速領導者選舉協議的連接。默認值爲錯誤的。
禁用數據目錄自動創建
3.5中的新功能:ZooKeeper服務器的默認行爲是在啓動時自動創建數據目錄(在配置文件中指定)，如果該目錄不存在的話。這可能不方便，在某些情況下甚至是危險的。以對正在運行的服務器進行配置更改的情況爲例，其中數據目錄參數被意外更改。當ZooKeeper服務器重新啓動時，它將創建這個不存在的目錄，並開始提供服務——使用一個空的znode命名空間。這種情況會導致有效的“大腦分裂”情況(即新的無效目錄和原始有效數據存儲中的數據)。因此，最好有一個選項來關閉這種自動創建行爲。一般來說，對於生產環境來說，這是應該做的，但是不幸的是，默認的遺留行爲此時不能被改變，因此這必須在個案的基礎上進行。這是留給用戶和ZooKeeper發行版的打包者的。
跑步時zkServer.sh通過設置環境變量可以禁用自動創建動物園_數據目錄_自動創建_禁用到1。當直接從類文件運行ZooKeeper服務器時，這可以通過設置來實現zoo keeper . datadir . autocreate = false在java命令行上，即-Dzookeeper . data dir . auto create = false
當此功能被禁用，並且ZooKeeper服務器確定所需的目錄不存在時，它將生成一個錯誤並拒絕啓動。
新劇本zkServer-initialize.sh來支持這一新功能。如果自動創建被禁用，用戶必須首先安裝ZooKeeper，然後創建數據目錄(可能還有txnlog目錄)，然後啓動服務器。否則，如前一段所述，服務器將不會啓動。運轉zkServer-initialize.sh將創建所需的目錄，並可選地設置myid文件(可選的命令行參數)。即使不使用autocreate特性本身，也可以使用該腳本，並且該腳本可能對用戶有用，因爲這(設置，包括創建myid文件)在過去一直是用戶的問題。請注意，該腳本確保數據目錄只存在，它不創建配置文件，而是要求配置文件可用才能執行。
性能調整選項
3.5.0中的新功能:爲了提高讀取吞吐量，已經對幾個子系統進行了改造。這包括NIO通信子系統和請求處理管道(提交處理器)的多線程。NIO是默認的客戶機/服務器通信子系統。它的線程模型包括1個接受者線程、1-N選擇器線程和0-M套接字輸入/輸出工作線程。在請求處理流水線中，系統可以被配置成一次處理多個讀請求，同時保持相同的一致性保證(相同會話寫後讀)。提交處理器線程模型包括1個主線程和0-N個工作線程。
默認值旨在最大化專用ZooKeeper機器上的讀取吞吐量。兩個子系統都需要有足夠數量的線程來實現峯值讀取吞吐量。
· zoo keeper . nio . numselectorthreads:(僅限於Java系統屬性:zoo keeper . nio . numselectorthreads)3.5.0中的新功能:NIO選擇器線程的數量。至少需要一個選擇器線程。對於大量客戶端連接，建議使用多個選擇器。默認值爲sqrt(CPU內核數/ 2)。
· zookeeper.nio.numWorkerThreads:(僅限於Java系統屬性:zookeeper.nio.numWorkerThreads)3.5.0中的新功能:NIO工作線程的數量。如果配置了0個工作線程，選擇器線程直接執行套接字輸入/輸出。默認值是cpu內核數量的2倍。
· zoo keeper . commitprocessor .numworkerThreads:(僅限於Java系統屬性:zoo keeper . commitprocessor .numworkerThreads)3.5.0中的新功能:提交處理器工作線程的數量。如果配置了0個工作線程，主線程將直接處理請求。默認值是cpu內核的數量。
· znode . container . CheckInterval:(僅限於Java系統屬性)3.5.1中的新功能:候選容器和ttl節點的每次檢查的時間間隔(毫秒)。默認值爲“60000”。
· znode.container.maxPerMinute:(僅限於Java系統屬性)3.5.1中的新功能:每分鐘可以刪除的最大容器和ttl節點數。這防止了容器刪除過程中的羊羣行爲。默認值爲“10000”。
管理服務器配置
3.5.0中的新功能:以下選項用於配置管理服務器。
· admin.enableServer:(Java系統屬性:zookeeper.admin.enableServer)設置爲“假”以禁用管理服務器。默認情況下，管理服務器處於啓用狀態。
· admin.serverAddress:(Java系統屬性:zookeeper.admin.serverAddress)嵌入式Jetty服務器監聽的地址。默認值爲0.0.0.0。
· admin.serverPort:(Java系統屬性:zookeeper.admin.serverPort)嵌入式Jetty服務器監聽的端口。默認值爲8080。
· admin.idleTimeout:(Java系統屬性:zookeeper.admin.idleTimeout)設置連接在發送或接收數據之前可以等待的最大空閒時間(以毫秒爲單位)。默認值爲30000毫秒
· admin.commandURL:(Java系統屬性:zookeeper.admin.commandURL)相對於根網址列出和發出命令的網址。默認爲"/命令"。
使用Netty框架進行溝通
內蒂是一個基於NIO的客戶機/服務器通信框架，它簡化了(通過NIO直接使用)java應用程序網絡級通信的許多複雜性。此外，Netty框架內置了對加密(SSL)和身份驗證(證書)的支持。這些是可選功能，可以單獨打開或關閉。
在3.5+版本中，ZooKeeper服務器可以通過設置環境變量來使用Netty而不是NIO(默認選項)zoo keeper . ServerCNxNFfactory到org . Apache . zoo keeper . server . NettyservercnxFactory；對於客戶端，設置zookeeper.clientCnxnSocket到org . Apache . zoo keeper . clientcnxnsocketnetty。
TBD-netty的調整選項-目前沒有netty特定的選項，但是我們應該添加一些。特別是在netty創建的讀者工作線程數上限附近。
法定人數
3.5.5中的新功能
基於網絡框架，zookeeper集合可以被設置爲在其通信信道中使用TLS加密。本節介紹如何在法定通信上設置加密。
請注意，法定TLS封裝了對領導者選舉和法定通信協議的保護。
1. 創建SSL密鑰庫JKS以存儲本地憑據
應爲每個ZK實例創建一個密鑰庫。
在本例中，我們生成一個自簽名證書，並將其與私鑰一起存儲在中keystore.jks。這適用於測試目的，但是您可能需要一個官方證書來在生產環境中籤署您的密鑰。
請注意別名(-別名)和可分辨名稱(-域名)必須與關聯的計算機的主機名匹配，否則主機名驗證將不起作用。
keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
1. 從密鑰庫中提取簽名的公鑰(證書)
這一步可能僅適用於自簽名證書。
keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
1. 創建包含所有zookeeper實例的證書的SSL信任庫JKS
同一個信任庫(存儲所有接受的證書)應該在集合的參與者之間共享。您需要使用不同的別名將多個證書存儲在同一個信任存儲中。化名的名字並不重要。
keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
1. 你需要使用NettyServerCnxnFactory因爲不支持SSL。將以下配置設置添加到zoo.cfg配置文件:
sslQuorum=true
serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
ssl.quorum.keyStore.location=/path/to/keystore.jks
ssl.quorum.keyStore.password=password
ssl.quorum.trustStore.location=/path/to/truststore.jks
ssl.quorum.trustStore.password=password
1. 在日誌中驗證您的集成正在TLS上運行:
INFO [main:QuorumPeer@1789] - Using TLS encrypted quorum communication
INFO [main:QuorumPeer@1797] - Port unification disabled
...
INFO [QuorumPeerListener:QuorumCnxManager$Listener@877] - Creating TLS-only quorum server socket
在不停機的情況下升級現有的非TLS羣集
3.5.5中的新功能
以下是利用端口統一功能將已經運行的ZooKeeper集成升級到TLS而不停機所需的步驟。
1. 如前一節所述，爲所有ZK參與者創建必要的密鑰庫和信任庫
2. 添加以下配置設置並重新啓動第一個節點
sslQuorum=false
portUnification=true
serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
ssl.quorum.keyStore.location=/path/to/keystore.jks
ssl.quorum.keyStore.password=password
ssl.quorum.trustStore.location=/path/to/truststore.jks
ssl.quorum.trustStore.password=password
請注意，TLS尚未啓用，但我們打開了端口統一。
1. 在其餘節點上重複步驟2。驗證您在日誌中是否看到以下條目:
INFO [main:QuorumPeer@1791] - Using insecure (non-TLS) quorum communication
INFO [main:QuorumPeer@1797] - Port unification enabled
...
INFO [QuorumPeerListener:QuorumCnxManager$Listener@874] - Creating TLS-enabled quorum server socket
在每個節點重新啓動後，您還應該再次檢查仲裁是否恢復正常。
1. 在每個節點上啓用法定TLS並執行滾動重啓:
SSL quorum =True
Portionalization = true
1. 一旦您驗證了您的整個系綜在TLS上運行，您就可以禁用端口統一併進行另一次滾動重啓
SSL quorum =True
Portionalization = false
zookeeper命令
四個字母單詞
zookeeper對一小部分命令做出響應。每個命令由四個字母組成。您可以在客戶端通過telnet或nc向ZooKeeper發出命令。
三個更有趣的命令:“stat”給出了一些關於服務器和連接的客戶端的一般信息，而“srvr”和“cons”分別給出了關於服務器和連接的詳細信息。
3.5.3中的新增功能:四個字母單詞在使用前需要被明確地白色列出。請參考4lw.commands .白名單如中所述集羣配置部分詳情。向前看，四個字母單詞將被否決，請使用管理服務器相反。
· conf：3.3.0中的新功能:打印服務配置的詳細信息。
· 騙局：3.3.0中的新功能:列出連接到此服務器的所有客戶端的完整連接/會話詳細信息。包括關於接收/發送的分組數量、會話id、操作等待時間、最後執行的操作等的信息...
· crst：3.3.0中的新功能:重置所有連接的連接/會話統計。
· 傾銷:列出未完成的會話和臨時節點。這隻對領導者有效。
· envirosphere company 環球公司:打印服務環境的詳細信息
· ruok:測試服務器是否在非錯誤狀態下運行。如果正在運行，服務器將使用imok進行響應。否則它根本不會迴應。“imok”的響應不一定表示服務器已加入仲裁，而只是表示服務器進程處於活動狀態並綁定到指定的客戶端端口。有關狀態wrt仲裁和客戶端連接信息的詳細信息，請使用“stat”。
· srst:重置服務器統計信息。
· srvr：3.3.0中的新功能:列出服務器的全部詳細信息。
· 斯達:列出服務器和連接的客戶端的簡要詳細信息。
· wchs：3.3.0中的新功能:列出服務器監視的簡要信息。
· wchc：3.3.0中的新功能:按會話列出服務器監視的詳細信息。這將輸出一個會話(連接)列表以及相關的觀察(路徑)。請注意，根據手錶的數量，這個操作可能很昂貴(即影響服務器性能)，請小心使用。
· dirs：3.5.1中的新功能:以字節顯示快照和日誌文件的總大小
· wchp：3.3.0中的新功能:按路徑列出服務器監視的詳細信息。這將輸出帶有關聯會話的路徑列表(znodes)。請注意，根據手錶的數量，這個操作可能很昂貴(即影響服務器性能)，請小心使用。
· mntr：3.4.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_num_alive_connections 1
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
zk_last_proposal_size 23
zk_min_proposal_size 23
輸出與java屬性格式兼容，內容可能會隨着時間而變化(添加了新的鍵)。您的腳本應該會有變化。注意:有些密鑰是特定於平臺的，有些密鑰僅由領導者導出。輸出包含多行，格式如下:
key \t value
· 以色羅：3.4.0中的新增功能:測試服務器是否以只讀模式運行。如果處於只讀模式，服務器將以“ro”響應，如果不處於只讀模式，則以“rw”響應。
· gtmk:以十進制格式的64位帶符號長值獲取當前跟蹤掩碼。看見stmk有關可能值的解釋。
· stmk:設置當前跟蹤掩碼。跟蹤掩碼爲64位，其中每一位啓用或禁用服務器上特定類別的跟蹤日誌記錄。Log4J必須配置爲啓用微量級別，以便查看跟蹤日誌消息。跟蹤掩碼的位對應於以下跟蹤日誌記錄類別。
跟蹤掩碼位值 | |
0b0000000000 | 未使用，保留供將來使用。 |
0b0000000010 | 記錄客戶端請求，不包括ping請求。 |
0b0000000100 | 未使用，保留供將來使用。 |
0b0000001000 | 記錄客戶端ping請求。 |
0b0000010000 | 記錄從當前領導的法定對等方接收的數據包，不包括ping請求。 |
0b0000100000 | 記錄客戶端會話的添加、刪除和驗證。 |
0b0001000000 | 記錄監視事件到客戶端會話的傳遞。 |
0b0010000000 | 記錄從當前領導的法定對等方接收的ping數據包。 |
0b0100000000 | 未使用，保留供將來使用。 |
0b1000000000 | 未使用，保留供將來使用。 |
· 64位值中的所有剩餘位都是未使用的，保留供將來使用。通過計算記錄值的位或來指定多個跟蹤日誌記錄類別。默認跟蹤掩碼是0b0100110010。因此，默認情況下，跟蹤日誌記錄包括客戶端請求、從領導者接收的數據包和會話。若要設置不同的跟蹤掩碼，請發送一個包含stmk四個字母的單詞，後面是跟蹤掩碼，表示爲64位有符號長值。這個例子使用了Perl包裝函數來構造一個跟蹤掩碼，該掩碼啓用上述所有跟蹤日誌記錄類別，並將其轉換爲具有大字節順序的64位有符號長值。結果被附加到stmk並使用netcat發送到服務器。服務器用十進制格式的新跟蹤掩碼進行響應。
$ perl -e "print'stmk，pack('q%3E '，0b 0011111010)" | NC localhost 2181
250
這裏有一個例子ruok命令:
$ echo ruok | nc127.0.0.1 5111 imok
管理服務器
3.5.0中的新功能:管理服務器是一個嵌入式Jetty服務器，它爲四個字母的單詞命令提供了一個HTTP接口。默認情況下，服務器在端口8080上啓動，通過轉到“網址”/“命令/[命令名”發出命令，例如，http://localhost:8080/commands/stat。命令響應作爲JSON返回。與原始協議不同，命令不限於四個字母的名稱，命令可以有多個名稱；例如，“stmk”也可以稱爲“set_trace_mask”。要查看所有可用命令的列表，請將瀏覽器指向網址/命令(例如，http://localhost:8080/commands)。看到了嗎管理服務器配置選項瞭解如何更改端口和網址。
默認情況下，管理服務器處於啓用狀態，但可以通過以下方式禁用:
· 將zookeeper.admin.enableServer系統屬性設置爲false。
· 從類路徑中刪除Jetty。(如果您想要覆蓋ZooKeeper的碼頭依賴性，此選項很有用。)
請注意，如果管理員服務器被禁用，則四個字母的TCP字接口仍然可用。
數據文件管理
ZooKeeper將其數據存儲在數據目錄中，其事務日誌存儲在事務日誌目錄中。默認情況下，這兩個目錄是相同的。服務器可以(也應該)配置爲將事務日誌文件存儲在與數據文件不同的目錄中。當事務日誌駐留在專用日誌設備上時，吞吐量增加，延遲減少。
數據目錄
這個目錄中有兩三個文件:
· myid-在人類可讀的ASCII文本中包含代表服務器id的單個整數。
· 初始化-存在表示預計缺少數據樹。創建數據樹後清理。
· 快照。-保存數據樹的模糊快照。
每個ZooKeeper服務器都有一個唯一的id。該id用於兩個地方:一個是myid文件和配置文件。這myid文件標識對應於給定數據目錄的服務器。配置文件列出了由服務器id標識的每臺服務器的聯繫信息。當ZooKeeper服務器實例啓動時，它從myid文件，然後使用該id讀取配置文件，查找它應該偵聽的端口。
這快照存儲在數據目錄中的文件是模糊快照，也就是說，在ZooKeeper服務器拍攝快照的過程中，數據樹會發生更新。的後綴快照文件名是zxid快照開始時最後提交的事務的ZooKeeper事務id。因此，快照包括在快照過程中發生的數據樹更新的子集。因此，快照可能不對應於任何實際存在的數據樹，因此我們將其稱爲模糊快照。不過，ZooKeeper可以使用這個快照進行恢復，因爲它利用了更新的冪等性。通過對模糊快照重放事務日誌，ZooKeeper在日誌末尾獲得系統狀態。
日誌目錄
日誌目錄包含ZooKeeper事務日誌。在任何更新發生之前，ZooKeeper確保代表更新的事務被寫入非易失性存儲。當寫入當前日誌文件的事務數量達到(可變)閾值時，將啓動新的日誌文件。使用影響快照頻率的相同參數計算閾值(參見上面的快照計數)。日誌文件的後綴是寫入該日誌的第一個zxid。
文件管理
快照和日誌文件的格式在獨立的ZooKeeper服務器和複製的ZooKeeper服務器的不同配置之間不會改變。因此，您可以將這些文件從正在運行的複製的ZooKeeper服務器拉到具有獨立ZooKeeper服務器的開發機器上，以便進行故障排除。
使用舊的日誌和快照文件，您可以查看ZooKeeper服務器的先前狀態，甚至可以恢復該狀態。日誌格式器類允許管理員查看日誌中的事務。
ZooKeeper服務器創建快照和日誌文件，但從不刪除它們。數據和日誌文件的保留策略在ZooKeeper服務器之外實現。服務器本身只需要最新的完整的模糊快照，所有的日誌文件在它之後，最後一個日誌文件在它之前。後一個要求是必要的，以包括在該快照啓動後發生的更新，但當時已進入現有的日誌文件。這是可能的，因爲在ZooKeeper中，對日誌的快照和滾動是獨立進行的。看到了嗎保持有關設置保留策略和維護ZooKeeper存儲的更多詳細信息，請參見本文檔的。
注意
存儲在這些文件中的數據沒有加密。在ZooKeeper中存儲敏感數據的情況下，需要採取必要的措施來防止未經授權的訪問。此類措施在ZooKeeper之外(例如，控制對文件的訪問)，並取決於部署它的各個設置。
恢復- TxnLogToolkit
TxnLogToolkit是ZooKeeper附帶的命令行工具，它能夠恢復帶有損壞的循環冗餘校驗的事務日誌條目。
不使用任何命令行參數或使用-h-救命參數，它輸出以下幫助頁面:
$ bin/zkTxnLogToolkit.sh
usage: TxnLogToolkit [-dhrv] txn_log_file_name
-d,--dump Dump mode. Dump all entries of the log file. (this is the default)
-h,--help Print help message
-r,--recover Recovery mode. Re-calculate CRC for broken entries.
-v,--verbose Be verbose in recovery mode: print all entries, not just fixed ones.
-y,--yes Non-interactive mode: repair all CRC errors without asking
默認行爲是安全的:它將給定事務日誌文件的條目轉儲到屏幕上:(與使用相同-d-轉儲參數)
$ bin/zkTxnLogToolkit.sh log.100000001
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
4/5/18 2:15:58 PM CEST session 0x16295bafcc40000 cxid 0x0 zxid 0x100000001 createSession 30000
CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
4/5/18 2:16:12 PM CEST session 0x26295bafcc90000 cxid 0x0 zxid 0x100000003 createSession 30000
4/5/18 2:17:34 PM CEST session 0x26295bafcc90000 cxid 0x0 zxid 0x200000001 closeSession null
4/5/18 2:17:34 PM CEST session 0x16295bd23720000 cxid 0x0 zxid 0x200000002 createSession 30000
4/5/18 2:18:02 PM CEST session 0x16295bd23720000 cxid 0x2 zxid 0x200000003 create '/andor,#626262,v{s{31,s{'world,'anyone}}},F,1
EOF reached after 6 txns.
在上述事務日誌文件的第二個條目中有一個循環冗餘校驗錯誤。在傾銷模式下，工具包只將這些信息打印到屏幕上，而不觸及原始文件。在恢復模式(-r-恢復標誌)原始文件仍然保持不變，所有事務都將被複制到一個新的txn日誌文件中。固定後綴。它會重新計算循環冗餘校驗值，並複製計算出的值，如果它不匹配原始的文本條目。默認情況下，該工具以交互方式工作:每當遇到CRC錯誤時，它都會要求確認。
$ bin/zkTxnLogToolkit.sh -r log.100000001
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
Would you like to fix it (Yes/No/Abort) ?
應答是意味着新計算的循環冗餘校驗值將輸出到新文件。不意味着原始的循環冗餘校驗值將被複制。流產將中止整個操作並退出。(在這種情況下爲“.“fixed”不會被刪除並處於半完成狀態:僅包含已經處理過的條目，或者如果操作在第一個條目處中止，則僅包含標題。)
$ bin/zkTxnLogToolkit.sh -r log.100000001
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
Would you like to fix it (Yes/No/Abort) ? y
EOF reached after 6 txns.
Recovery file log.100000001.fixed has been written with 1 fixed CRC error(s)
恢復的默認行爲是保持沉默:只有出現循環冗餘校驗錯誤的條目纔會被打印到屏幕上。可以使用打開詳細模式-v-冗長參數查看所有記錄。可以使用關閉交互模式-是的-是的參數。在這種情況下，所有的循環冗餘校驗錯誤都將在新的事務文件中修復。
需要避免的事情
通過正確配置ZooKeeper，您可以避免以下一些常見問題:
· 服務器列表不一致:客戶端使用的ZooKeeper服務器列表必須與每個ZooKeeper服務器擁有的ZooKeeper服務器列表相匹配。如果客戶端列表是真實列表的一個子集，事情就可以正常工作，但是如果客戶端有一個位於不同ZooKeeper集羣中的ZooKeeper服務器列表，事情就會變得很奇怪。此外，每個zookeeper服務器配置文件中的服務器列表應該彼此一致。
· 事務日誌的放置不正確:ZooKeeper最關鍵的性能部分是事務日誌。ZooKeeper在返回響應之前將事務同步到媒體。專用事務日誌設備是保持良好性能的關鍵。將日誌放在繁忙的設備上會對性能產生負面影響。如果您只有一個存儲設備，請將跟蹤文件放在NFS，並增加快照數量；這並不能消除問題，但應該可以緩解問題。
· 不正確的Java堆大小:您應該特別注意正確設置您的Java最大堆大小。特別是，您不應該創建ZooKeeper交換到磁盤的情況。這個圓盤對zookeeper來說是致命的。一切都是有序的，所以如果處理一個請求交換磁盤，所有其他排隊的請求可能也會這樣做。磁盤。不要交換。保守估計:如果你有4G的內存，不要將最大堆大小設置爲6G甚至4G。例如，您更有可能將3G堆用於4G機器，因爲操作系統和緩存也需要內存。評估系統所需堆大小的最佳且唯一推薦的做法是運行負載測試，然後確保您遠遠低於導致系統交換的使用限制。
· 可公開訪問的部署:ZooKeeper集合預計將在可信的計算環境中運行。因此，建議在防火牆後部署ZooKeeper。
最佳實踐
爲了獲得最佳效果，請注意以下良好的zookeeper實踐列表:
有關多租戶安裝，請參見部分詳述ZooKeeper的“chroot”支持，這在部署許多應用程序/服務接口到一個ZooKeeper集羣時非常有用。