[前言:這是一次艱苦的旅行...]

一.初始ZK

 
1. 什麼是ZK：ZK是一個高效的分散式協調服務，它暴露了一些公用服務，比如命名/配置管理/同步控制/群組服務等。我們可以使用ZK來實現比如達成共識/集團管理/leader選舉等。關鍵詞：分散式協調  高效能
2. 設計目標：

• 簡單：ZK中的namespace組織結構類似與標準的檔案系統，通過這些共享的有層次的namespace來互相協調分散式中的多個程序，這些namespace由ZNodes組成，ZK資料被儲存在記憶體中，這也意味著ZK將可以達到較高的吞吐量/較低的延遲。ZK的核心目標就是高效能，高可用，嚴格有序存取。高效能標誌著ZK可以被使用在大規模分散式環境中，高可用標誌著ZK避免單點故障，具有較強的容錯能力；嚴格有序(strict ordering)意味著客戶端可以實現複雜的同步。
• 複製：ZK的資料將會在ZK Cluster中的每臺機器上協作複製(備份)，構成ZK服務的機器必須能夠互相感知對方。它們保持了一個記憶體檢視狀態（in-memory image of state）,同時伴隨這tnx log和snapshot的持久儲存。只要大部分server有效，那麼ZK 服務也是有效的。客戶端只與一個zk server建立連結，client通過建立的TCP連線來進行請求/響應/獲取事件/傳送心跳等。如果此TCP連線失效，client將會嘗試連線其他的ZK server。
• 全序性：對於每個update請求，ZK（leader）都會為其生成唯一的Zid來表示其事務的順序，接下來的操作可以使用zid的順序實現同步原語（佇列）。
• 高效快速：ZK在“讀主導”的應用中表現的非常的優秀。ZK應用可以執行在數臺機器上，並且在read遠大與write的場景中，是非常適合的，通常這個比例為10：1.

3. ZK server組成: ZK server根據其身份特性分為三種：leader，Follower，Observer，其中Follower和Observer又統稱Learner（學習者）。

• Leader：負責客戶端的writer型別請求
• Follower：負責客戶端的reader型別請求，參與leader選舉等
• Observer：特殊的“Follower”，其可以接受客戶端reader請求，單不參與選舉。（擴容系統支撐能力，提高了讀取速度。因為它不接受任何同步的寫入請求，只負責與leader同步資料）

4. zoo.cfg配置檔案詳解(參考原始碼:org.apache.zookeeper.server.quorum.QuorumPeerConfig)：
    //最小化配置

• tickTime=2000    //the length of single tick,it's the base time unit.(heartbeats,timeout,sessionTimeOut)
• clientPort=2181            //the port that client should connnect to.
• dataDir=        //the location :memory database snapshots
• dataLogDir=    //the location    :the txn log file,if not specified,it's the same as 'dataDir'

    //擴充套件配置

• globalOutstandingLimit(系統屬性：zookeeper.globalOutstandingLimit) //default 1000.如果有大量client，會造成ZK server對請求的處理速度小於client的提交請求的速度，會造成server端大量請求queue滯留而OOM，此引數控制server最大持有未處理請求的個數。
• preAllocSize(系統屬性：zookeeper.preAllocSize)    //為了避免大量磁碟檢索，ZK對txn log檔案進行空間預分配，預設為64M。每當剩餘空間小於4K時，將會再次“預分配”。你可以嘗試減小此值，比如當SNAP較為頻繁時(snapCount較小).
• snapCount(系統屬性：zookeeper.snapCount)    //預設為100000，在新增log（txn log）條數達到snapCount/2 + Random.nextInt(snapCount/2)時，將會對zkDatabase(記憶體資料庫)進行snapshot，將記憶體中DataTree反序為snapshot檔案資料，同時log計數置為0，以此迴圈。snapshot過程中，同時也伴隨txn log的新檔案建立（這也是snapCount與preAllocSize引數的互相協調原因）。snapshot時使用隨機數的原因：讓每個server snapshot的時機具有隨即且可控，避免所有的server同時snapshot（snapshot過程中將阻塞請求）。參見SyncRequestProcessor.run()
• traceFile(系統屬性：requestTraceFile)    //請求跟蹤檔案，如果設定了此引數，所有請求將會被記錄在traceFile.year.month.day，類似與nginx的request log，不過此引數的配置，會帶來一定的效能問題（Debug model）。
• maxClientCnxns=60    //default 60,一個client與server上最大的socket連結數（socket層），根據IP區分。設定為0，取消此限制。此值在一方面是為了避免DOS攻擊。
• ClientPortAddress    //new in 3.3.0,IP或者hostName，指定偵聽clientPort的address。此引數是可選的，預設是clientPort會繫結到所有的IP上，在物理server具有多個網路介面時，可以設定特定的IP。
• minSessionTimeout    //new in 3.3.0,default 2*tickTime,也是server允許的最小值，如果設定的值過小，將會採用預設值。
• maxSessionTimeout    //new in 3.3.0,default 20*tickTime,也是server允許的最大值。
• autopurge.snapRetainCount    //new in 3.4.0,zk server啟動時會開啟一個DatadirCleanupManager的執行緒，用於清理“過期”的snapshot檔案和其相應的txn log file，此引數用於設定需要被retain的檔案個數。（原始碼中關於清理機制，還有點意思）
• autopurge.purgeInterval    //new in 3.4.0,和上述引數配合，清理任務被處罰的時間間隔，單位：hours，實現原理為Timer.scheduleAtFixedRate(...)

    //cluster環境配置

• electionAlg=    //default 3.使用何種選舉方式，（0，1，2，3），“0”表示使用原生的UDP（LeaderElection），“1”表示使用非授權UDP，“2”表示授權UDP，“3”基於TCP的快速選舉（FastLeaderElection）。目前保留“3”，其他方式將在未來版本不予支援，參見QuorumPear.createElectionAlgorithm（int alg）
• initLimit=10    //Leader與Learner建立的連結中（終端為learner），sock通訊read所阻塞的時間(initLimit * tickTime)，此值為tick的倍數 ，如果Learner數量較多或者Leader的資料很大，建議增加此值。參見LearnerHandler.run()。
• SyncLimit=5    //Learner與Leader建立的連結中，sock通訊read阻塞的時間。其中包括資料同步/和資料提交操作等,此值為tick的倍數，參見learner.connectToLeader()/syncWithLeader().
• peerType    //ZK server型別：observer，participant
• leaderServes(系統屬性：zookeeper.leaderServes)    //leader是否接受client請求，預設為“yes”即leader可以接受client的連結。在ZK cluster環境中，當節點數量》3時，建議關閉。

//server列表
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890
server.4=127.0.0.1:2891:3891
server.5=127.0.0.1:2892:3892
//上述為ZK 節點列表，格式：server.sid = hostname:followingPort:electionPort,如果採用UDP方式，electionPort可以不用設定。
//Leader選舉成功之後,Follower可以在followingPort上與leader建立連結,以便此後進行各種通訊.比如server.1為Leader,那麼其他機器將會在127.0.0.1:2888上建立連結.
//electionPort為Leader選舉的埠,當叢集處於危險期時,每個server都會根據server列表中配置,和其他server的electionPoint建立連結,並在此後通過此連線傳送"選舉"資訊.

• cnxTimeout(系統屬性：zookeeper.cnxTimeout)    //leader選舉時，socket連結開啟的時長。只有在elctionArg為3時生效。

    //不安全配置（不建議修改部分）

• skipACL(系統屬性：zookeeper.skipACL)        //預設為no。是否忽略所有的ACL檢查。
• forceSync(系統屬性：zookeeper.forceSync)    //預設為yes。在update執行前，是否強制對操作立即持久寫入txn log檔案。關閉此選項，會造成服務失效後，尚未持久的資料丟失。
• Jute.maxbuffer(系統屬性：jute.maxbuffer)    //預設為1024，單位KB，即表示節點可掛載的data最大為1M。如果修改此值，請首先確保所有的server上一致。

4.  ZK Commands:
四字指令(指令為四個字元組成)，是方便我們獲取ZK cluster狀態資訊的簡單的方式，開發者可以使用"命令"的方式操作,其通過telnet或者nc的方式向ZK的clientPort傳送指令.(原始碼:FourLetterWordMain.java)
【$echo “cmd” | nc ip clientPost】,如下為”cmd”合法值列表:
    conf:列印server配置資訊
    cons:列舉出與server建立的所有連結/session詳情，包括資料接收/傳送量，sessionId，操作延遲等等。
    crst：reset關於連結/session的統計資訊。
    dump:列舉所有的session和臨時節點，只能在leader上生效。
    envi：列印server的環境
    ruok：檢測server是否正常，如果響應“imok”則表示正在執行。
    srst：重置server的統計資訊
    stat：列舉server主要的資訊。（比如可以獲取此server是否為Leader）
    mntr：輸出cluster的健康監控引數資料。


5. 其他;
    data被儲存在data資料夾，txn log被儲存在日至資料夾中，預設這兩個路徑一樣。對於每個ZK Server還需要一個myid的檔案，此檔案作為一個data檔案放置與data目錄下，用於標識此server的SID，cluster中sid用於區分通訊中server資訊，且不能有重複值(myid檔案中只包含一個Integer的數字)。snapshot檔案即為ZKDatabase的“快照”，其檔名稱格式為    snapshot.zid,其中zid為“快照”開始時最大的zid。