zookeeper默認配置文件爲zoo.cfg，如果我們要使用zoo1.cfg作爲配置文件時使用命令：zkServer.sh start zoo1.cfg
接下來我們將說明zookeeper中較爲重要的一些配置，其中主要內容根據《從 Paxos 到 ZooKeeper 分佈式一致性原理與實踐》和《ZooKeeper-分佈式過程協同技術》得來：
1，zoo.cfg默認帶的參數：
| 參數名 | 說明 | |
|---|---|---|
| tickTime | 用於配置 ZooKeeper 中最小時間單位的長度，很多運行時的時間間隔都是使用 tickTime 的倍數來表示的。例如，ZooKeeper 中會話的最小超時時間默認是 2*tickTime；單位爲毫秒，默認配置2000。 | |
| initLimit | 該參數有默認值: 10，即表示是參數 tickTime 值得10倍，必須配置，且需要配置一個正整數，不支持系統屬性方式配置。該參數用於配置 Leader 服務器等待 Follower 啓動，並完成數據同步的時間。Follwer 服務器再啓動過程中，會與 Leader 建立連接並完成對數據的同步，從而確定自己對外提供服務的其實狀態。Leader 服務器允許 Follower 在 initLimit 時間內完成這個工作。 通常情況下，運維人員不用太在意這個參數的配置，使用默認值即可。但如果隨着 ZooKeeper 集羣管理的數據量增大，Follower 服務器再啓動的時候，從 Leader 上進行同步數據的時間也會相應變長，於是無法在較短的時間完成數據同步。因此，在這種情況下，有必要適當調大這個參數。 | |
| syncLimit | 該參數有默認值: 5，即表示參數 tickTime 值得5倍，必須配置，且需要配置一個正整數，不支持系統屬性配置。該參數用於配置 Leader 服務器和 Follower 服務器之間進行心跳檢測的最大延時時間。在 ZooKeeper 集羣運行過程中，Leader 服務器會與所有的 Follower 進行心跳檢測來確定該服務器是否存活。如果 Leader 服務器再 syncLimit 時間內無法獲取到 Follower 的心跳檢測響應，那麼 Leader 就會認爲該 Follower 已經脫離了和自己的同步。通常情況下，運維人員使用該參數的默認值即可，但如果部署ZooKeeper 集羣的網絡環境質量較低（例如網絡延時較大或丟包嚴重），那麼可以適當調大這個參數。 | |
| dataDir | 用於配置 ZooKeeper 服務器存儲快照文件的目錄。默認情況下，如果沒有配置參數 dataLogDir，那麼事務日誌也會存儲在這個目錄中。考慮到事務日誌的寫性能直接影響 ZooKeeper 整體的服務能力，因此建議同時通過參數 dataLogDir 來配置 ZooKeeper 事務日誌的存儲目錄。如果某個服務器爲集羣中的一臺，id文件也保存在該目錄下。該參數無默認值，必須配置。 | |
| clientPort | 用於配置當前服務器對外的服務端口，客戶端會通過該端口和 ZooKeeper 服務器創建連接，一般設置爲2181。每臺 ZooKeeper 都可以配置任意可用的端口，同時集羣中的所有服務器不需要保持 clientPort 端口一致。該參數無默認值，必須配置。 |
2，其他較重要配置
| 參數名 | 說明 |
|---|---|
| dataLogDir | 該參數有默認值: dataDir，可以不配置，不支持系統屬性方式配置。參數 dataLogDir 用於配置 ZooKeeper 服務器存儲事務日誌文件的目錄。默認情況下，ZooKeeper 會將事務日誌文件和快照數據存儲在同一目錄中，應該儘量將這兩者的牧區區分開來。另外，如果條件允許，可以將事務日誌的存儲位置配置在一個單獨的磁盤上。事務日誌記錄對於磁盤的性能要求非常高，爲了保證數據的一致性，ZooKeeper 在返回客戶端事務請求相應之前，必須將本次請求對應的事務日誌寫入到磁盤中。因此，事務日誌寫入的性能直接決定了 ZooKeeper 在處理事務請求時的吞吐。針對同一塊磁盤的其他併發讀寫操作（例如 ZooKeeper 運行時日誌輸出和操作系統自身的讀寫等），尤其是數據快照操作，會極大地影響事務日誌的寫性能。因此儘量給事務日誌的輸出配置一個單獨的磁盤或掛載點，將極大地提升 ZooKeeper 的整體性能。 |
| snapCount | 指定每次快照之間的事務數（zookeeper.snapCount）。當Zookeeper服務器重啓後需要恢復其狀態，恢復時兩大時間因素分別是爲恢復狀態而讀取快照的時間以及快照啓動後所發生的事務的執行時間。執行快照可以減少讀入快照文件後需要應用的事務數量，但是進行快照時也會影響服務器性能，即便是通過後臺線程的方式進行寫入操作。snapCount的默認值爲100000，因爲進行快照時會影響性能，所以集羣中所有服務器最好不要在同一時間進行快照操作，只要仲裁服務器不會一同進行快照，處理時間就不會受影響，因此每次快照中實際的事務數爲一個接近snapCount值的隨機數。注意，如果snapCount數已經達到，但前一個快照正在進行中，新的快照將不會開始，服務器也將繼續等到下一個snapCount數量的事務後再開啓一個新的快照。 |
| preAllocSize | 用於設置預分配的事務日誌文件（zookeeper.preAllocSize）的大小值，以KB爲單位。當寫入事務日誌文件時，服務端每次會分配preAllocSize值的KB的存儲大小，通過這種方式可以分攤文件系統將磁盤分配存儲空間和更新元數據的開銷，更重要的是，該方式也減少了文件尋址操作的次數。默認情況下preAllocSize的值爲64MB，縮小該值的一個原因是事務日誌永遠不會達到這麼大，因爲每次快照後都會重新啓動一個新的事務日誌，如果每次快照之間的日誌數量很小，而且每個事務本身也很小，64MB的默認值顯然就太大了。例如，如果我們每1000個事務進行一次快照，每個事務的平均大小爲100字節，那麼100KB的preAllocSize值則更加合適。默認的preAllocSize值的設置適用於默認的snapCount值和平均事務超過512字節的情況。 |
| minSessionTimeout | 最小會話超時時間，單位爲毫秒。當客戶端建立一個連接後就會請求一個明確的超時值，而客戶端實際獲得的超時值不會低於minSessionTimeout的值。ZooKeeper開發人員很想立刻且準確地檢測出客戶端故障發生的情況，遺憾的是，系統不可能實時處理這種情況，而是通過心跳和超時來處理。超時取決於ZooKeeper客戶端與服務器之間的響應能力，更重要的是兩者之間的網絡延時和可靠性。超時時間允許的最小值爲客戶端與服務器之間網絡的環回時間，但偶爾還是可能發生丟包現象，當這種情況發生時，因爲重傳超時導致接收響應時間的增加，並會導致接收重發包的延時。minSessionTimeout的默認值爲tickTime值的兩倍。配置該參數值過低可能會導致錯誤的客戶端故障檢測，配置該參數值過高會延遲客戶端故障的檢測時間 。 |
| maxSessionTimeout | 會話的最大超時時間值，單位爲毫秒。當客戶端建立一個連接後就會請求一個明確的超時值，而客戶端實際獲得的超時值不會高於maxSessionTimeout的值。雖然該參數並不會影響系統的性能，但卻可以限制一個客戶端消耗系統資源的時間，默認情況下maxSessionTimeout的時間爲tickTime的20倍。 |
| maxClientCnxns | 允許每個IP地址的併發socket連接的最大數量。Zookeeper通過流量控制和限制值來避免過載情況的發生。一個連接的建立所使用的資源遠遠高於正常操作請求所使用的資源。我們曾看到過某些錯誤的客戶端每秒創建很多ZooKeeper連接，最後導致拒絕服務（DoS），爲了解決這個問題，我們添加了這個選項，通過設置該值，可以在某個IP地址已經有maxClientCnxns個連接時拒絕該IP地址新的連接。該選項的默認值爲60個併發連接。注意，每個服務器維護着這個連接的數量，如果我們有一個5個服務器的集羣，並且使用默認的併發連接數60，一個欺詐性的客戶端會隨機連接到這5個不同的服務器，正常情況下，該客戶端幾乎可以從單個IP地址上建立300個連接，之後纔會觸發某個服務器的限制。 |
| globalOutstandingLimit | ZooKeeper中待處理請求的最大值（zookeeper.globalOutstandingLimit）。ZooKeeper客戶端提交請求比ZooKeeper服務端處理請求要快很多，服務端將會對接收到的請求隊列化，最終（也許幾秒之內）可能導致服務端的內存溢出。爲了防止發生這個問題，ZooKeeper服務端中如果待處理請求達到globalOutstandingLimit值就會限制客戶端的請求。但是globalOutstandingLimit值並不是硬限制，因爲每個客戶端至少有一個待處理請求，否則會導致客戶端超時，因此，當達到globalOutstandingLimit值後，服務端還會繼續接收客戶端連接中的請求，條件是這個客戶端在服務器中沒有任何待處理的請求。爲了確定某個服務器的全侷限制值，我們只是簡單地將該參數值除以服務器的數量，目前還沒有更智能的方式去實現全局待處理操作數量的計算，並強制採用該參數所指定的限制值，因此，該限制值爲待處理請求的上限值，事實上，服務器之間完美的負載均衡解決方案還無法實現，所以某些服務器運行得稍緩慢一點，或者處於更高的負載中，即使最終沒有達到全侷限制值也可能被限制住吞吐量。該參數的默認值爲1000個請求，你可能並不會修改該參數值，但如果你有很多客戶端發送大數據包請求可能就需要降低這個參數值，但我們在實踐中還未遇到需要修改這個參數的情況。 |
| clientPortAddress | 限制客戶端連接到指定的接收信息的地址上。默認情況下，一個ZooKeeper服務器會監聽在所有的網絡接口地址上等待客戶端的連接。有些服務器配置了多個網絡接口，其中一個網絡接口用於內網通信，另一個網絡接口用於公網通信，如果你並不希望服務器在公網接口接受客戶端的連接，只需要設置clientPortAddress選項爲內網接口的地址。 |
| leaderServes | 配置值爲“yes”或“no”標誌，指示羣首服務器是否爲客戶端提供服務（zookeeper.leaderServes）。擔任羣首的ZooKeeper服務器需要做很多工作，它需要與所有追隨者進行通信並會執行所有的變更操作，也就意味着羣首的負載會比追隨者的負載高，如果羣首過載，整個系統可能都會受到影響。該標誌位如果設置爲“no”就可以使羣首除去服務客戶端連接的負擔，使羣首將所有資源用於處理追隨者發送給它的變更操作請求，這樣可以提高系統狀態變更操作的吞吐能力。換句話說，如果羣首不處理任何與其直連的客戶端連接，追隨者就會有更多的客戶端，因爲連接到羣首的客戶端將會分散到追隨者上，尤其注意在集羣中服務器數量比較少的時候。默認情況下，leaderServes的值爲“yes”。 |
| server.x=[hostname]：n：n[：observer] | 服務器x的配置參數。ZooKeeper服務器需要知道它們如何通信，配置文件中該形式的配置項就指定了服務器x的配置信息，其中x爲服務器的ID值（一個整數）。當一個服務器啓動後，就會讀取data目錄下myid文件中的值，之後服務器就會使用這個值作爲查找server.x項，通過該項中的數據配置服務器自己。如果需要連接到另一個服務器y，就會使用server.y項的配置信息來與這個服務器進行通信。其中hostname爲服務器在網絡n中的名稱，同時後面跟了兩個TCP的端口號，第一個端口用於事務的發送，第二個端口用於羣首選舉，典型的端口號配置爲2888：3888。如果最後一個字段標記了observer屬性，服務器就會進入觀察者模式。注意，所有的服務器使用相同的server.x配置信息，這一點非常重要，否則的話，因服務器之間可能無法正確建立連接而導致整個集羣無法正常工作。 |
| cnxTimeout | 在羣首選舉打開一個新的連接的超時值（zookeeper.cnxTimeout）。ZooKeeper服務器在進行羣首選舉時互相之間會建立連接，該選項值確定了一個服務器在進行重試前會等待連接成功建立的時間爲多久。默認的超時時間爲5秒，該值足夠大，也許你並不需要修改。 |
| autopurge.snapRetainCount | 當進行清理數據操作時，需要保留在快照數量和對應的事務日誌文件數量。ZooKeeper將會定期對快照和事務日誌進行垃圾回收操作，autopurge.snapRetainCount值指定了垃圾回收時需要保留的快照數，顯然，並不是所有的快照都可以被刪除，因爲那樣就不可能進行服務器的恢復操作。autopurge.snapRetainCount的最小值爲3，也是默認值的大小。 |
| autopurge.purgeInterval | 對快照和日誌進行垃圾回收（清理）操作的時間間隔的小時數。如果設置爲一個非0的數字，autopurge.purgeInterval指定了垃圾回收週期的時間間隔，如果設置爲0，默認情況下，垃圾回收不會自動執行，而需要通過ZooKeeper發行包中的zkCleanup.sh腳本手動運行。 |
| fsync.warningthresholdms | 觸發警告的存儲同步時間閥值（fsync.warningthresholdms），以毫秒爲單位。ZooKeeper服務器在應答變化消息前會同步變化情況到存儲中。如果同步系統調用消耗了太長時間，系統性能就會受到嚴重影響，服務器會跟蹤同步調用的持續時間，如果超過fsync.warningthresholdms只就會產生一個警告消息。默認情況下，該值爲1000毫秒。 |
| weight.x=n | 該選項常常以一組參數進行配置，該選項指定組成一個仲裁機構的某個服務器的權重爲n，其權重n值指示了該服務器在進行投票時的權重值。在ZooKeeper中一些部件需要投票值，比如羣首選舉中和原子廣播協議中。默認情況下，一個服務器的權重值爲1，如果定義的一組服務器沒有指定權重，所有服務器的權重值將默認分配爲1。 |
| traceFile | 持續跟蹤ZooKeeper的操作，並將操作記錄到跟蹤日誌中，跟蹤日誌的文件名爲traceFile.year.month.day。除非設置了該選項（requestTraceFile），否則跟蹤功能將不會啓用。該選項用來提供ZooKeeper所進行的操作的詳細視圖。不過，要想記錄這些日誌，ZooKeeper服務器必須序列化操作，並將操作寫入磁盤，這將爭用CPU和磁盤的時間。如果你使用了該選項，請確保不要將跟蹤文件放到日誌文件的存儲設備中。我們還需要知道，跟蹤選項還可能影響系統運行，甚至可能會很難重現跟蹤選項關閉時發生的問題。另外還有個有趣的問題，traceFile選項的Java系統屬性配置中不含有zookeeper前綴，而且系統屬性的名稱也與配置選項名稱不同，這一點請小心。 |