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