前言
zookeeper相信大家都不陌生，很多分布式中間件都利用zk來提供分布式一致性協調的特性。dubbo官方推薦使用zk作為注冊中心，zk也是hadoop和Hbase的重要組件。其他知名的開源中間件中也都出現了zk的身影。
有很多童鞋認識zk很久了，知道其基本理念，知道如何使用。但當面試時問到集群zk之間的選舉和數據同步機制時，就陷入了盲區。
其實很多的分布式中間件的選舉和同步，都和zk有異曲同工之妙。這篇文章我就來重點聊下關於zk集群之間的選舉和同步機制。
ZK集群的部署
首先我們來看下半數運行機制：
集群至少需要三台服務器，且官方文檔強烈建議使用奇數個服務器，因為zookeeper是通過判斷大多數節點的的存活來判斷整個服務集群是否可用的，比如3個節點，它的一半是1.5，向上取整就是2。掛掉了2個就是表示整個集群掛掉。而用偶數4個的話，掛掉2個也表示不是大部分存活，因此也會掛掉。所以用4台服務器的話 ，從使用資源上來說，並不划算。
配置語法：
server.<節點ID>=<IP>:<數據同步端口>:<選舉端口>
- 節點ID：為1到125之間的數字，寫到對應服務節點的{dataDir}/myid文件中。
- IP地址：節點的遠程IP地址，可以相同，生產環境建議用不同的機器，否則無法達到容錯的目的。
- 數據同步端口：主從同步時數據復制端口。
- 選舉端口：主從節點選舉端口。
假設現在有3個zookeeper節點，我們要為其編寫config配置，也要編寫3份，分別放在不同的服務器上，其配置如下：
initLimit=10
syncLimit=5
dataDir=/data/zk_data
clientPort=2181
# 集群配置
server.1=192.168.1.1:2888:3888
server.2=192.168.1.2:2888:3888
server.3=192.168.1.3:2888:3888
其中dataDir參數指定的是一個目錄，用來存放zk的數據，里面有個文件myid，3台機器上myid文件里面分別存放1,2,3。對應各自節點ID。
配置好3個配置文件后，分別啟動，這樣我們一個3個節點的集群zookeeper就搭建好了。
./bin/zkServer.sh start conf/zoo.cfg
ZK集群中的角色
zookeeper集群中公共有三種角色，分別是leader，follower，observer。
| 角色 | 描述 |
|---|---|
| leader | 主節點，又名領導者。用於寫入數據，通過選舉產生，如果宕機將會選舉新的主節點。 |
| follower | 子節點，又名追隨者。用於實現數據的讀取。同時他也是主節點的備選節點，並擁有投票權。 |
| observer | 次級子節點，又名觀察者。用於讀取數據，與follower區別在於沒有投票權，不能被選為主節點。並且在計算集群可用狀態時不會將observer計算入內。 |
關於observer的配置：
只要在集群配置中加上observer后綴即可，示例如下：
server.3=127.0.0.1:2883:3883:observer
其中leader只有一個，剩下的都是follower和observer，但是我們一般生產上不會配置observer，因為observer並沒有選舉權，可以理解為observer是一個臨時工，不是正式員工，沒法獲得晉升。除此之外，它和follower的功能是一樣的。
什么時候需要用到observer呢，因為zk一般讀的請求會大於寫。當整個集群壓力過大時，我們可以增加幾個臨時工observer來獲得性能的提升。在不需要的時候的時候，可以隨時撤掉observer。
zk進行連接時，一般我們都會把zk所有的節點都配置上去，用逗號分隔。其實連接集群中的任意一個或者多個都是可以的。只是如果只連一個節點，當這個節點宕機的時候，我們就斷開了連接。所以還是推薦配置多個節點進行連接。
如何查看ZK集群中的角色
我們可以利用以下命令來查看zk集群中的角色
./bin/zkServer.sh status conf/zoo.cfg
我在自己機器上搭建了3個節點的偽集群(共用一台機器)，配置文件分別命名為zoo1.cfg，zoo2.cfg，zoo3.cfg。使用以上命令查看的結果為：
可以看到，其中節點2為leader，其他的為follower。但是如果你按照zoo1.cfg，zoo2.cfg，zoo3.cfg的順序啟動，無論你啟動多少遍，節點2總是leader，而這時如果把節點2關掉，進行查看角色，發現節點3成了leader。
以上這些現象都和zookeeper的選舉機制有關
ZK集群的選舉機制
我們就拿3個節點的zk作一個簡單選舉的說明
zk會進行多輪的投票，直到某一個節點的票數大於或等於半數以上，在3個節點中，總共會進行2輪的投票：
- 第一輪，每個節點啟動時投票給自己，那這樣zk1，zk2，zk3各有一票。
- 第二輪，每個節點投票給大於自己myid，那這樣zk2啟動時又獲得一票。加上自己給自己投的那一票。總共有2票。2票大於了當前節點總數的半數，所以投票終止。zk2當選leader。
有的童鞋會問，zk3呢，因為zk2已經當選了，投票終止了。所以zk2也不會投票給zk3了。
當然這是一個比較簡單版的選舉，其實真正的選舉還要比較zxid，這個后面會講到。
zk選舉什么時候會被觸發呢？一是啟動時會被觸發，二是leader宕機時會被觸發。上面的例子中，如果節點2宕機，根據規則，那獲得leader的就應該是zk3了。
ZK集群的數據同步機制
zookeeper的數據同步是為了保證每個節點的數據一致性，大致分為2個流程，一個是正常的客戶端數據提交流程，二是集群中某個節點宕機后數據恢復流程。
正常客戶端數據提交流程
客戶端寫入數據提交流程大致為：leader接受到客戶端的寫請求，然后同步給各個子節點：
但是有童鞋就產生疑惑了，客戶端一般連接的是所有節點，客戶端並不知道哪個是leader呀。
的確，客戶端會和所有的節點建立鏈接，並且發起寫入請求是挨個遍歷節點進行的，比如第一次是節點1，第二次是節點2。以此類推。
如果客戶端正好鏈接的節點的角色是leader，那就按照上面的流程走。那如果鏈接的節點不是leader，是follower呢，則有以下流程：
如果Client選擇鏈接的節點是Follower的話，這個Follower會把請求轉給當前Leader，然后Leader會走藍色的線把請求廣播給所有的Follower，每個節點同步完數據后會走綠色的線告訴Leader數據已經同步完成（但是還未提交），當Leader收到半數以上的節點ACK確認消息后，那么Leader就認為這個數據可以提交了，會廣播給所有的Follower節點，所有的節點就可以提交數據。整個同步工作就結束了。
那我們再來說說節點宕機后的數據同步流程
當zookeeper集群中的Leader宕機后，會觸發新的選舉，選舉期間，整個集群是沒法對外提供服務的。直到選出新的Leader之后，才能重新提供服務。
我們重新回到3個節點的例子，zk1，zk2，zk3，其中z2為Leader，z1，z3為Follower，假設zk2宕機后，觸發了重新選舉，按照選舉規則，z3當選Leader。這時整個集群只整下z1和z3，如果這時整個集群又創建了一個節點數據，接着z2重啟。這時z2的數據肯定比z1和z3要舊，那這時該如何同步數據呢。
zookeeper是通過ZXID事務ID來確認的，ZXID是一個長度為64位的數字，其中低32位是按照數字來遞增，任何數據的變更都會導致低32位數字簡單加1。高32位是leader周期編號，每當選舉出一個新的Leader時，新的Leader就從本地事務日志中取出ZXID，然后解析出高32位的周期編號，進行加1，再將低32位的全部設置為0。這樣就保證了每次選舉新的Leader后，保證了ZXID的唯一性而且是保證遞增的。
查看某個數據節點的ZXID的命令為：
先進入zk client命令行
./bin/zkCli.sh -server 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183
stat加上數據節點名稱
stat /test
執行結果為：
可以看到，有3個ZXID，這3個ZXID各自代表：
cZxid：該節點創建時的事務ID
mZxid：該節點最近一次更新時的事務ID
pZxid：該節點的子節點的最新一次創建/更新/刪除的事務ID
查看節點最新ZXID的命令為：
echo stat|nc 127.0.0.1 2181
這個命令需提前在cfg文件后追加：4lw.commands.whitelist=*，然后重啟
這里的ZXID就是當前節點最后一次事務的ID。
如果整個集群數據為一致的，那么所有節點的ZXID應該一樣。所以zookeeper就通過這個有序的ZXID來確保各個節點之間的數據的一致性，帶着之前的問題，如果Leader宕機之后，再重啟后，會去和目前的Leader去比較最新的ZXID，如果節點的ZXID比最新Leader里的ZXID要小，那么就會去同步數據。
再看ZK中的選舉
我們帶着ZXID的概念再來看ZK中的選舉機制。
假設還是有一個3個節點的集群，zk2為Leader，這時候如果zk2掛了。zk3當選Leader，zk1為Follower。這時候如果更新集群中的一個數據。然后把zk1和zk3都關閉。然后挨個再重啟zk1，zk2，zk3。這時候啟動后，zk2還能當選為Leader嗎？
其實這個問題，換句話說就是：在挨個啟動zk節點的時候，zk1和zk3的數據為最新，而zk2的數據不是最新的，按照之前的選舉規則的話，zk2是否能順利當選Leader？
答案為否，最后當選的為zk1。
這是為什么呢。
因為zk2的最新ZXID已經不是最新了，zk的選舉過程會優先考慮ZXID大的節點。這時ZXID最大的有zk1和zk3，選舉只會在這2個節點中產生，根據之前說的選舉規則。在第一輪投票的時候，zk1只要獲得1票，就能達到半數了，就能順利當選為Leader了。
最后
其實zk的選舉和同步並不復雜，如果能試着在本地去搭建3個節點的偽集群，去試着跑一下上面的案例。應該就能明白整個過程。zk作為老牌的一致性協調中間件，也是諸多面試的頻次很高的問點。如果你能理解本篇的核心內容，再次碰到這類問題的時候，這將不會是你的盲區。最后，喜歡本篇內容的朋友希望點贊，關注，轉發。
