文章目錄

• 版本宣告
• JMX
• 叢集高可用
• 水平擴容
• 磁碟管理

版本宣告

1. Zookeeper版本3.4.6

配置檔案詳解

1. 單擊配置

   引數名	預設值	描述
   clientPort	無預設值，必須配置	服務的監聽埠，一般設定2181，叢集中不同機器的埠可以不同
   dataDir	無預設值，必須配置	用於存放記憶體資料快照的資料夾，同時叢集的myid檔案也存在這個資料夾裡
   dataLogDir	預設與dataDir目錄相同	事務日誌寫入目錄，儘量不要與dataDir同一個目錄，甚至不要在一塊磁碟上，避免事務日誌與快照資料對磁碟的競爭
   tickTime	2000	Zookeeper的時間單元。Zookeeper中所有時間都是以這個時間單元的整數倍去配置的。例如，session的最小超時時間是2*tickTime。（單位：毫秒）
   globalOutstandingLimit	1000	最大請求堆積數。預設是1000。Zookeeper執行過程中，儘管Server沒有空閒來處理更多的客戶端請求了，但是還是允許客戶端將請求提交到伺服器上來，以提高吞吐效能。當然，為了防止Server記憶體溢位，這個請求堆積數還是需要限制下的。
   preAllocSize	65535KB	預先開闢磁碟空間，用於後續寫入事務日誌。預設是64M，每個事務日誌大小就是64M。如果ZK的快照頻率較大的話，建議適當減小這個引數。
   snapCount	100,000	每進行snapCount次事務日誌輸出後，觸發一次快照， 此時，Zookeeper會生成一個snapshot.檔案，同時建立一個新的事務日誌檔案log. 。預設是100,000.
   traceFile	用於記錄所有請求的log，一般除錯過程中可以使用，但是生產環境不建議使用，會嚴重影響效能。
   maxClientCnxns	60	單個客戶端與單個伺服器之間的最大併發連線數，預設值是60(3.4.0版本開始)，設定為0是不加限制
   clientPortAddress	對於多網絡卡的機器，可以為每個IP指定不同的監聽埠。預設情況是所有IP都監聽 clientPort 指定的埠
   minSessionTimeout/maxSessionTimeout	Session超時時間限制，如果客戶端設定的超時時間不在這個範圍，那麼會被強制設定為最大或最小時間。預設的Session超時時間是在2 *  tickTime ~ 20 * tickTime 這個範圍
   fsync.warningthresholdms	10000	事務日誌輸出時，如果呼叫fsync方法超過指定的超時時間，那麼會在日誌中輸出警告資訊。預設是1000ms。
   autopurge.snapRetainCount	引數指定了需要保留的事務日誌和快照檔案的數目。預設是保留3個。和autopurge.purgeInterval搭配使用
   autopurge.purgeInterval	在3.4.0及之後版本，Zookeeper提供了自動清理事務日誌和快照檔案的功能，這個引數指定了清理頻率，單位是小時，需要配置一個1或更大的整數，預設是0，表示不開啟自動清理功能
   syncEnabled	true	Observer寫入日誌和生成快照，這樣可以減少Observer的恢復時間。預設為true。

2. 叢集主要選項

   引數名	預設值	描述
   initLimit	10	表示tickTime值的多少倍，該引數用於配置Leader伺服器等待Follower啟動，並完成資料同步的時間。Follower伺服器在啟動過程中，會與Leader建立連線並完成對資料的同步，從而確定自己對外提供服務的起始狀態。Leader伺服器允許Follower在initLimit*tickTime時間內完成這個工作。如果同步的資料量很大，可以把這個值設定的大一些
   leaderServes	yes	預設情況下，Leader是會接受客戶端連線，並提供正常的讀寫服務。但是，如果你想讓Leader專注於叢集中機器的協調，那麼可以將這個引數設定為 no，這樣一來，會大大提高寫操作的效能。一般機器數比較多的情況下可以設定為no，讓Leader不接受客戶端的連線。預設為yes
   syncLimit	5	表示tickTime值的5倍，用於配置Leader伺服器和Follower之間進行心跳檢測的最大延遲時間。在zk叢集執行過程中，Leader伺服器會與所有的Follower伺服器進行心跳檢測來確定伺服器是否存活，如果Leader伺服器在syncLimit* tickTime時間內無法獲取到Follower的心跳檢測響應，那麼Leader就會認為該Follower已經脫離了和自己的同步
   cnxTimeout	5000ms	Leader選舉過程各伺服器之間進行TCP連線建立的超時時間
   standaloneEnabled	當設定為false時，伺服器在複製模式下啟動

JMX

1. 有時我們不希望在伺服器之間配置ssh，或者管理各種密碼公鑰，但是又需要管控Zookeeper,此時可以開啟JMX功能

2. Zookeeper預設開啟了JMX功能，但是卻僅限本地連線，無法通過遠端連線。可以修改zkServer.sh,找到如下ZOOMAIN配置

       ZOOMAIN="-Dcom.sun.management.jmxremote  
       -Dcom.sun.management.jmxremote.local.only=false  
       -Djava.rmi.server.hostname=0.0.0.0
       -Dcom.sun.management.jmxremote.port=10999
       -Dcom.sun.management.jmxremote.ssl=true
       -Dcom.sun.management.jmxremote.authenticate=true
       -Dcom.sun.management.jmxremote.access.file=/root/jmx/jmxremote.access 
       -Dcom.sun.management.jmxremote.password.file=/root/jmx/jmxremote.password 
       -Dzookeeper.jmx.log4j.disable=true 
       org.apache.zookeeper.server.quorum.QuorumPeerMain"
   
   

3. 新建兩個檔案/root/jmx/jmxremote.access(訪問使用者角色和相關聯的許可權資訊)和/root/jmxjmxremote.password(指定每個角色的密碼)。這兩個檔案的設定可以參考$JAVA_HOME/jre/lib/management裡的模板檔案

   • jmxremote.access 檔案內容

       monitorRole   readonly
       controlRole   readwrite \
       create javax.management.monitor.*,javax.management.timer.* \
               unregister
     

   • jmxremote.password檔案內容

     monitorRole  123456
     controlRole   abcdefg
     

叢集高可用

1. 一個Zookeeper叢集入股要對外提供可用的服務，那麼叢集中必須要有過半的機器正常工作並且彼此之間能夠正常通訊。基於這點，如果想要搭建一個能夠允許N臺機器宕機的叢集，那麼就要部署一個由2N+1臺伺服器構成的叢集。從這個公式來看，一個由5臺機器構成的叢集和一個由6臺機器構成的叢集容災能力是一樣的，所以Zookeeper叢集通常設計部署成奇數臺伺服器
2. Zookeeper基於過半的設計原則:在執行期間，叢集中至少有過半的機器儲存了最新的資料，整個叢集就能夠對外提供服務。從這點來看Zookeeper叢集本身就解決了單點問題。
3. 三機房容災部署方案
   • 前置條件,設叢集總機器數為N，三個機房部署的Zookeeper伺服器數量分別為N1,N2,N3,
   • 計算N1: N1=(N-1)/2 向下取整。如果N為7或者8，則N1=3
   • 計算N2: N2的取值範圍為1~(N-N1)/2
   • 計算N3，同時確定N2: N3=N-N1-N2並且N3<N1+N2
   • 假設N=7，則最終部署方案為(N1=3,N2=1,N3=3) 和(N1=3,N2=2,N3=2)。這樣就保證了任意一個機房宕機，剩下兩個機房的機器總數一定是過半的。
4. 雙機房容災部署方案
   • 理論上沒有好的辦法，因為無論哪個機房發生問題，都可能使得Zookeeper叢集中可用的機器無法超過半數。
   • 儘量在主要機房部署更多的機器，比如N=7，N1=4(主機房)，N2=3

水平擴容

1. Zookeeper在水平擴容方面做的不是很好(一般情況下叢集數量也不能太多(3~5個例項即可)，所以這個也不是什麼問題)，需要進行整個叢集的重啟(因為叢集的配置檔案zoo.cfg要修改)。重啟有兩種方式:
   • 叢集整體全部重啟:重啟過程中，所有客戶端都無法連線上叢集，重啟完成之後，客戶端會自動連線上————在整體重啟期間花費的時間將不計入Sesssion超時(會話超時)時間的計算。對於Zookeeper不是核心元件的應用而言，可以選擇這種方式
   • 逐臺機器重啟:每次僅僅重啟叢集中的一臺機器，然後逐臺對整個叢集中的機器進行重啟操作

磁碟管理

1. Zookeeper對於磁碟的依賴非常嚴重，所有資料狀態的變數都會以事務日誌的形式寫入磁碟，並且只有當叢集中過半的伺服器都記錄了該事務日誌後，伺服器才會給予客戶端響應。Zookeeper還會定時將記憶體資料庫中的所有資料和所有客戶端的會話資訊記錄進行快照，並儲存在磁碟上的資料快照檔案中去。所以磁碟的I/O效能直接制約Zookeeper每個更新操作的處理速度。
2. 為了儘量減少 Zookeeper在讀寫磁碟上的效能損失
   • 使用單獨的磁碟作為事務日誌的輸出目錄。事務日誌的寫效能對Zookeeper處理客戶端請求，尤其是更新操作的處理效能影響很大。 Zookeeper的事務日誌輸出是一個順序寫檔案的過程，本身的效能很高，儘量保證事務日誌與快照資料分別配置在兩塊單獨掛載的磁碟上，避免對事務日誌與快照資料對磁碟的競爭。
   • 儘量避免記憶體與磁碟空間的swap。如果希望 Zookeeper能夠提供完全實時的服務，就不能出現記憶體與磁碟空間的swap現象。因此在分配JVM堆大小的時候一定要非常小心