參數名html |
說明java |
clientPort算法 |
客戶端鏈接server的端口,即對外服務端口,通常設置爲2181吧。apache |
dataDir服務器 |
存儲快照文件snapshot的目錄。默認狀況下,事務日誌也會存儲在這裏。建議同時配置參數dataLogDir, 事務日誌的寫性能直接影響zk性能。session |
tickTimeide |
ZK中的一個時間單元。ZK中全部時間都是以這個時間單元爲基礎,進行整數倍配置的。例如,session的最小超時時間是2*tickTime。性能 |
dataLogDir大數據 |
事務日誌輸出目錄。儘可能給事務日誌的輸出配置單獨的磁盤或是掛載點,這將極大的提高ZK性能。 spa (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 ) |
tickTime=2000
initLimit=10
syncLimit=5
clientPort=2181
dataDir=/Users/nick/software/zookeeper-3.4.10/data
tickTime=2000
initLimit=10
syncLimit=5
clientPort=2181
# 數據目錄
dataDir=/Users/nick/software/zookeeper-3.4.10/data
# 集羣信息 server.X=IP:端口:端口
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2887:3887
server.3=127.0.0.1:2889:3889
在data目錄下新增文本 myid 內容寫上響應的機器ID