Valentine 轉(zhuǎn)載請(qǐng)標(biāo)明出處。
Zookeeper的由來
1复哆、各個(gè)節(jié)點(diǎn)的數(shù)據(jù)一致性绝页；
2、怎么保證任務(wù)只在一個(gè)節(jié)點(diǎn)上執(zhí)行寂恬；
3续誉、如果service1掛了，其他節(jié)點(diǎn)如何發(fā)現(xiàn)并接替任務(wù)初肉；
4酷鸦、存在共享資源，互斥性牙咏、安全性臼隔。
Zookeeper的前世今生
從上面的案例可以看出，分布式系統(tǒng)的很多難題妄壶，都是由于缺少協(xié)調(diào)機(jī)制造成的摔握，在分布式協(xié)調(diào)這塊做得比較好的有Google的Chubby以及Apache的Zookeeper。
Google Chubby是一個(gè)分布式鎖服務(wù)丁寄，通過Google Chubby來解決分布式協(xié)作氨淌、Master選舉與分布式鎖服務(wù)相關(guān)的問題。
Zookeeper也是類似伊磺，因?yàn)楫?dāng)時(shí)在雅虎內(nèi)部的很多系統(tǒng)都需要一個(gè)系統(tǒng)來進(jìn)行分布式協(xié)調(diào)盛正，但是谷歌的Chubby是不開源的，所以后來雅虎基于Chubby的思想開發(fā)了Zookeeper屑埋，并捐贈(zèng)給了Apache豪筝。
在上面這個(gè)架構(gòu)下Zookeeper可以用來解決task執(zhí)行問題，各個(gè)服務(wù)先去zookeeper上注冊(cè)節(jié)點(diǎn)，然后獲得權(quán)限以后再來訪問task续崖。
Zookeeper的設(shè)計(jì)猜想
Zookeeper主要是解決分布式環(huán)境下的服務(wù)協(xié)調(diào)問題而產(chǎn)生的敲街，如果我們要去實(shí)現(xiàn)一個(gè)Zookeeper這樣的中間件，我們需要做什么严望？
1多艇、防止單點(diǎn)故障
如果要防止Zookeeper這個(gè)中間件的單點(diǎn)故障，那就要做集群著蟹，而且這個(gè)集群如果要滿足高性能要求的話墩蔓，還的是個(gè)高性能高可用的集群。高性能意味著這個(gè)集群能夠分擔(dān)客戶端的請(qǐng)求流量萧豆，高可用意味著集群中的某一個(gè)節(jié)點(diǎn)宕機(jī)以后奸披，不影響整個(gè)集群的數(shù)據(jù)和繼續(xù)提供服務(wù)的可能性。
結(jié)論：所以這個(gè)中間件需要考慮到集群涮雷，而且這個(gè)集群還需要分?jǐn)偪蛻舳说恼?qǐng)求流量阵面。
2、接著上面那個(gè)結(jié)論再來思考洪鸭，如果要滿足這樣的一個(gè)高性能集群样刷，最直觀的想法應(yīng)該是每個(gè)節(jié)點(diǎn)都接收到請(qǐng)求，并且每個(gè)節(jié)點(diǎn)的數(shù)據(jù)都必須保持一致览爵。實(shí)現(xiàn)各個(gè)節(jié)點(diǎn)的數(shù)據(jù)一致性置鼻，那就要一個(gè)leader節(jié)點(diǎn)負(fù)責(zé)協(xié)調(diào)和數(shù)據(jù)同步操作，如果在這樣一個(gè)集群中沒有l(wèi)eader節(jié)點(diǎn)蜓竹，每個(gè)節(jié)點(diǎn)都可以接收到請(qǐng)求箕母，那么這個(gè)集群的數(shù)據(jù)同步的復(fù)雜度是非常大的。
結(jié)論：所以這個(gè)集群中涉及到數(shù)據(jù)同步以及會(huì)存在leader節(jié)點(diǎn)俱济。
3嘶是、繼續(xù)思考，如何在這些節(jié)點(diǎn)中選舉出leader節(jié)點(diǎn)蛛碌，以及l(fā)eader掛了以后聂喇，如何恢復(fù)？
結(jié)論：所以Zookeeper用了基于paxos理論所衍生出來的zab協(xié)議蔚携。
4希太、leader節(jié)點(diǎn)是如何和其他節(jié)點(diǎn)保證數(shù)據(jù)一致性，并且要求是強(qiáng)一致性的浮梢。在分布式系統(tǒng)中跛十，每一個(gè)機(jī)器節(jié)點(diǎn)雖然都能夠知道自己進(jìn)行的事務(wù)操作過程是成功或失敗。但是卻無法直接獲取其他分布式節(jié)點(diǎn)的操作結(jié)果秕硝。所以當(dāng)一個(gè)事務(wù)操作涉及到跨節(jié)點(diǎn)的時(shí)候，就需要用到分布式事務(wù)，分布式事務(wù)的數(shù)據(jù)一致性協(xié)議有2PC協(xié)議和3PC協(xié)議远豺。
基于這些猜想奈偏，基本上知道Zookeeper為什么要用到zab理論來做選舉，為什么要做集群躯护，為什么要用到分布式事務(wù)來實(shí)現(xiàn)數(shù)據(jù)一致性了惊来。接下來逐步去剖析Zookeeper里面的這些內(nèi)容。
關(guān)于2PC提交
（Two Phase Commitment Protocol）當(dāng)一個(gè)事務(wù)操作需要跨越多個(gè)分布式節(jié)點(diǎn)的時(shí)候棺滞，為了保持事務(wù)的ACID特性裁蚁，就需要引入一個(gè)“協(xié)調(diào)者”（TM（事務(wù)管理器））來統(tǒng)一調(diào)度所有分布式節(jié)點(diǎn)的執(zhí)行邏輯，這些被調(diào)度的分布式節(jié)點(diǎn)被成為AP（應(yīng)用程序）继准。TM負(fù)責(zé)調(diào)度AP的行為枉证，并最終決定這些AP是否要把事務(wù)真正進(jìn)行提交，因?yàn)檎麄€(gè)事務(wù)是分為兩個(gè)階段提交移必，所以叫2PC室谚。
階段一：提交事務(wù)請(qǐng)求（投票）
1、事務(wù)詢問
協(xié)調(diào)者向所有的參與者發(fā)送事務(wù)內(nèi)容崔泵，詢問是否可以執(zhí)行事務(wù)提交操作秒赤，并開始等待各參與者的響應(yīng)。
2憎瘸、執(zhí)行事務(wù)
各個(gè)參與者節(jié)點(diǎn)執(zhí)行事務(wù)操作入篮，并將Undo和Redo信息記錄到事務(wù)日志中，盡量把提交過程中所有消耗時(shí)間的操作和準(zhǔn)備都提前完成確保后面100%提交事務(wù)幌甘。
3潮售、各個(gè)參與者向協(xié)調(diào)者反饋事務(wù)詢問的響應(yīng)
如果各個(gè)參與這成功執(zhí)行了事務(wù)操作，那么就反饋給參與者yes的響應(yīng)含潘，表示事務(wù)可以執(zhí)行饲做，如果參與者沒有成功執(zhí)行事務(wù)，就反饋給協(xié)調(diào)者no的響應(yīng)遏弱，如果參與者沒有成功執(zhí)行事務(wù)盆均，就反饋給協(xié)調(diào)者no的響應(yīng)，表示事務(wù)不可以執(zhí)行漱逸，上面這個(gè)階段有點(diǎn)類似協(xié)調(diào)者組織各個(gè)參與者對(duì)一次事務(wù)操作的投票表態(tài)過程泪姨，因此2PC協(xié)議的第一個(gè)階段稱為“投票階段”，即各參與者投票表明是否需要繼續(xù)執(zhí)行接下去的事務(wù)提交操作饰抒。
階段二：執(zhí)行事務(wù)提交
在這個(gè)階段肮砾，協(xié)調(diào)者會(huì)根據(jù)各參與者的反饋情況來決定最終是否可以進(jìn)行事務(wù)提交操作，正常情況下包含兩種可能：執(zhí)行事務(wù)袋坑、中斷事務(wù)仗处。
Zookeeper的集群
在Zookeeper中，客戶端會(huì)隨機(jī)連接到Zookeeper集群中的一個(gè)節(jié)點(diǎn)，如果是讀請(qǐng)求婆誓，就直接從當(dāng)前節(jié)點(diǎn)中讀取數(shù)據(jù)吃环，如果是寫請(qǐng)求，那么請(qǐng)求會(huì)被轉(zhuǎn)發(fā)給leader提交事務(wù)洋幻，然后leader廣播事務(wù)郁轻，只要有超過半數(shù)節(jié)點(diǎn)寫入成功，那么請(qǐng)求就會(huì)被提交（類2PC事務(wù)）文留。
所有事務(wù)請(qǐng)求必須由一個(gè)全局唯一的服務(wù)器來協(xié)調(diào)處理好唯，這個(gè)服務(wù)器就是leader服務(wù)器，其他的服務(wù)器就是follower燥翅。leader服務(wù)器把客戶端的寫請(qǐng)求轉(zhuǎn)化成一個(gè)proposal（提議）并把這個(gè)proposal分發(fā)給集群中的所有follower服務(wù)器骑篙，之后leader服務(wù)器需要等待所有follower服務(wù)器的反饋，一旦超過半數(shù)的follower服務(wù)器進(jìn)行了正確的反饋权旷，那么leader就會(huì)再次向所有的follower服務(wù)器發(fā)送commit消息替蛉，要求各個(gè)follower節(jié)點(diǎn)對(duì)前面的一個(gè)proposal進(jìn)行提交。
集群角色
leader角色
leader服務(wù)器是整個(gè)Zookeeper集群的核心拄氯，主要的工作任務(wù)有兩項(xiàng)：
1躲查、事務(wù)請(qǐng)求的唯一調(diào)度和處理者，保證集群事務(wù)處理的順序性译柏；
2镣煮、集群內(nèi)部各服務(wù)器的調(diào)度者。
follower角色
follower角色的主要職責(zé)是：
1鄙麦、處理客戶端非事務(wù)請(qǐng)求典唇，轉(zhuǎn)發(fā)事務(wù)請(qǐng)求給leader服務(wù)器；
2胯府、參與事務(wù)請(qǐng)求proposal的投票（需要板書以上服務(wù)器通過才能通知leader commit數(shù)據(jù)介衔，leader發(fā)起的提案要follower投票）；
3骂因、參與leader選舉的投票炎咖。
observer角色
observer是zookeeper3.3開始引入的一個(gè)全新的服務(wù)器角色，從字面理解寒波，該角色充當(dāng)了觀察者的角色乘盼。觀察zookeeper集群中的最新狀態(tài)變化并將這些狀態(tài)變化同步到observer服務(wù)器上。observer的工作原理與follower角色基本一致俄烁，而它和follower角色唯一的不同在于observer不參與任何形式的投票绸栅，包括事務(wù)請(qǐng)求proposal和leader選舉。簡(jiǎn)單來說observer服務(wù)器只提供非事務(wù)請(qǐng)求服務(wù)页屠，通常在于不影響集群事務(wù)處理能力的前提下提升集群非事務(wù)處理的能力粹胯。
集群組成
通常zookeeper是由2n+1臺(tái)server組成蓖柔，每個(gè)server都知道彼此的存在，對(duì)于2n+1臺(tái)server矛双，只要有n+1臺(tái)（大多數(shù)）server可用渊抽，整個(gè)系統(tǒng)保持可用蟆豫。一個(gè)zookeeper集群如果要對(duì)外提供可用的服務(wù)议忽，那么集群中必須要有過半的機(jī)器正常工作并且彼此之間能夠正常通信，基于這個(gè)特性十减，如果想搭建一個(gè)能夠允許F臺(tái)機(jī)器down掉的集群栈幸，那么就要部署2*F+1臺(tái)服務(wù)器構(gòu)成的zookeeper集群。因此3臺(tái)機(jī)器構(gòu)成的zookeeper集群帮辟，能夠在掛掉一臺(tái)依然能正常工作速址，一個(gè)5臺(tái)機(jī)器集群的服務(wù)，能夠?qū)?臺(tái)機(jī)器掛掉的情況下進(jìn)行容災(zāi)由驹，如果一個(gè)6臺(tái)服務(wù)器構(gòu)成的集群芍锚，同樣只能掛掉2臺(tái)機(jī)器。所以5臺(tái)和6臺(tái)在容災(zāi)能力上并沒有明顯優(yōu)勢(shì)蔓榄，反而增加了網(wǎng)絡(luò)通信負(fù)擔(dān)并炮，系統(tǒng)啟動(dòng)時(shí)，集群中的server會(huì)選舉一臺(tái)server為leader甥郑，其他的就作為follower（先不考慮observer）逃魄。
之所以要滿足這樣一個(gè)燈飾，是因?yàn)橐粋€(gè)節(jié)點(diǎn)要成為集群中的leader澜搅，需要有超過集群中過半數(shù)的節(jié)點(diǎn)支持伍俘，這個(gè)涉及到leader選舉算法，同時(shí)也涉及到事務(wù)請(qǐng)求的提交投票勉躺。
例子：
3臺(tái)服務(wù)器癌瘾，至少2臺(tái)正常運(yùn)行才行（3的半數(shù)為1.5，半數(shù)以上最少為2）饵溅，正常運(yùn)行可以允許1臺(tái)服務(wù)器掛掉妨退。
4臺(tái)服務(wù)器，至少3臺(tái)正常運(yùn)行才行（4的半數(shù)為2概说，半數(shù)以上最少為3）碧注，正常運(yùn)行可以允許1臺(tái)服務(wù)器掛掉。
ZAB協(xié)議
ZAB（Zookeeper Atomic Broadcast）zookeeper原子廣播協(xié)議糖赔，協(xié)議是為分布式協(xié)調(diào)服務(wù)zookeeper專門設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議萍丐。在zookeeper中，主要依賴ZAB協(xié)議來實(shí)現(xiàn)分布式數(shù)據(jù)一致性放典，基于該協(xié)議逝变，zookeeper實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來保持集群中各個(gè)副本之間的數(shù)據(jù)一致性基茵。
ZAB協(xié)議介紹
ZAB協(xié)議包含兩種基本模式，分別是：
1壳影、崩潰恢復(fù)拱层；2、原子廣播宴咧。
當(dāng)整個(gè)集群在啟動(dòng)時(shí)根灯，或者當(dāng)leader節(jié)點(diǎn)出現(xiàn)網(wǎng)絡(luò)中斷、崩潰等情況掺栅，ZAB協(xié)議就會(huì)進(jìn)入恢復(fù)模式并選舉產(chǎn)生新的leader烙肺，當(dāng)leader服務(wù)器選舉出來后，并且集群中有過半的機(jī)器和該leader節(jié)點(diǎn)完成數(shù)據(jù)同步后（同步指的是數(shù)據(jù)同步氧卧，用來保證集群中過半的機(jī)器能夠和leader服務(wù)器的數(shù)據(jù)狀態(tài)保持一致）桃笙，ZAB協(xié)議就會(huì)退出恢復(fù)模式。
當(dāng)集群中已經(jīng)有過半的follower節(jié)點(diǎn)完成了和leader同步以后沙绝，那么整個(gè)集群就進(jìn)入了消息廣播模式搏明。這個(gè)時(shí)候，在leader節(jié)點(diǎn)正常工作時(shí)闪檬，啟動(dòng)一臺(tái)新的服務(wù)器加入到集群星著，那這個(gè)服務(wù)器會(huì)直接進(jìn)入數(shù)據(jù)恢復(fù)模式，和leader節(jié)點(diǎn)進(jìn)行數(shù)據(jù)同步谬以，同步完成后即可正常對(duì)外提供非事務(wù)請(qǐng)求的處理强饮。
消息廣播的實(shí)現(xiàn)原理
如果大家了解分布式事務(wù)的2pc、3pc協(xié)議的話为黎，消息廣播的過程實(shí)際上是一個(gè)簡(jiǎn)化版本的二階段提交過程邮丰。
1、leader接收到消息請(qǐng)求后铭乾，將消息賦予一個(gè)全局唯一的64位自增id剪廉，叫zxid，通過zxid的大小比較既可以實(shí)現(xiàn)因果有序的特征炕檩；
2斗蒋、leader為每個(gè)follower準(zhǔn)備了一個(gè)FIFO隊(duì)列（通過TCP協(xié)議來實(shí)現(xiàn)，以實(shí)現(xiàn)了全局有序這一特點(diǎn)）將帶有zxid的消息作為一個(gè)proposal分發(fā)給所有的follower笛质；
3泉沾、當(dāng)follower接收到proposal，先把proposal寫到磁盤妇押，寫入成功之后再向leader回復(fù)一個(gè)ack跷究；
4、當(dāng)leader接收到合法數(shù)量（超過半數(shù)幾點(diǎn)）的ack后敲霍，leader就會(huì)向這些follower發(fā)送commit命令俊马，同時(shí)會(huì)在本地執(zhí)行該消息丁存；
5、當(dāng)follower收到消息的commit命令以后柴我，會(huì)提交該消息解寝，leader的投票過程，不需要observer的ack艘儒，observer不參與投票過程聋伦，observer只同步leader的數(shù)據(jù)。
崩潰恢復(fù)（數(shù)據(jù)恢復(fù)）
ZAB協(xié)議的這個(gè)基于原子廣播協(xié)議的消息廣播過程彤悔，在正常情況下是沒有任何問題的嘉抓，但是一旦leader節(jié)點(diǎn)崩潰，或者由于網(wǎng)絡(luò)問題導(dǎo)致leader服務(wù)器失去了過半的follower節(jié)點(diǎn)的聯(lián)系（可能是leader節(jié)點(diǎn)和follower節(jié)點(diǎn)之間產(chǎn)生了網(wǎng)絡(luò)分區(qū)晕窑，那么此時(shí)的leader不再是合法的leader了），那么就會(huì)進(jìn)入到崩潰恢復(fù)模式卵佛。在ZAB協(xié)議中杨赤，為了保證程序的正確運(yùn)行，整個(gè)恢復(fù)過程結(jié)束后需要選舉出一個(gè)新的leader截汪，為了使leader掛了后系統(tǒng)能正常工作疾牲，需要解決兩個(gè)問題：
1、已經(jīng)被處理的消息不能丟失
當(dāng)leader收到合法數(shù)量follower的ack后衙解，就向各個(gè)follower廣播commit命令阳柔，同時(shí)也會(huì)在本地執(zhí)行commit并向連接的客戶端返回【成功】。但是如果在各個(gè)follower收到commit之前l(fā)eader就掛了蚓峦，導(dǎo)致剩下的服務(wù)器沒有執(zhí)行這條消息舌剂。
leader對(duì)事務(wù)消息發(fā)起commit操作，但是該消息在follower1上執(zhí)行了暑椰，但是follower2還沒有收到commit就已經(jīng)掛了霍转，而實(shí)際上客戶端已經(jīng)收到該事務(wù)消息處理成功的回執(zhí)了，所以在zab協(xié)議下需要保證所有機(jī)器都要執(zhí)行這個(gè)事務(wù)消息一汽。
2避消、被丟棄的消息不能再次出現(xiàn)
當(dāng)leader接收到消息請(qǐng)求生成proposal后就掛了，其他follower并沒有收到此proposal召夹，因此經(jīng)過恢復(fù)模式重新選了leader后岩喷，這條消息是被跳過的。此時(shí)监憎，之前掛了的leader重新啟動(dòng)并注冊(cè)成了follower疮装，他保留了被跳過消息的proposal狀態(tài)，與整個(gè)系統(tǒng)的狀態(tài)是不一致的各淀，需要將其刪除。
ZAB協(xié)議需要滿足上面兩種情況爬虱，就必須要設(shè)計(jì)一個(gè)leader選舉算法，能夠確保已經(jīng)被leader提交的事務(wù)proposal能夠提交腾它、同時(shí)丟棄已經(jīng)被跳過的事務(wù)proposal跑筝。
針對(duì)這個(gè)要求
1、如果leader選舉算法能夠保證新選舉出來的leader服務(wù)器擁有集群中所有機(jī)器最高編號(hào)（ZXID最大）的事務(wù)proposal瞒滴，那么就可以保證這個(gè)新選舉出來的leader一定具有已經(jīng)提交的提案曲梗。因?yàn)樗刑岚副籧ommit之前必須有超過半數(shù)的follower ack，即必須有超過半數(shù)節(jié)點(diǎn)的服務(wù)器的事務(wù)日志上有該提案的proposal妓忍，因此只要有合法數(shù)量的節(jié)點(diǎn)正常工作就必然有一個(gè)節(jié)點(diǎn)保存了所有被commit消息的proposal狀態(tài)虏两。還有，zxid是64位世剖，高32位是epoch編號(hào)定罢，每經(jīng)過一次leader選舉產(chǎn)生一個(gè)新的leader，新的leader會(huì)將epoch號(hào)+1旁瘫，低32位是消息計(jì)數(shù)器祖凫，每接收到一條消息，這個(gè)值+1酬凳，新leader選舉后這個(gè)值重置為0惠况。這樣設(shè)計(jì)的好處在于老的leader掛了以后重啟，它不會(huì)被選舉為leader宁仔，因此此時(shí)它的zxid肯定小于當(dāng)前新的leader稠屠。當(dāng)老的leader作為follower接入新的leader后，新的leader會(huì)讓它將所有擁有舊的epoch號(hào)的未被commit的proposal清除翎苫。
關(guān)于zxid
zxid权埠，也就是事務(wù)id，為了保證事務(wù)的順序一致性拉队，zookeeper采用了遞增的事務(wù)id（zxid）來標(biāo)識(shí)事務(wù)弊知，所有的提議（proposal）都在被提出的時(shí)候加上了zxid。實(shí)現(xiàn)中zxid是一個(gè)64位的數(shù)字粱快，它高32位是epoch（ZAB協(xié)議通過epoch編號(hào)來區(qū)分leader周期變化的策略）用來標(biāo)識(shí)leader關(guān)系是否改變秩彤，每次一個(gè)leader被選舉出來，它都會(huì)有一個(gè)新的epoch=（原來的epoch+1）事哭，標(biāo)識(shí)當(dāng)前屬于哪個(gè)leader的統(tǒng)治時(shí)期漫雷。低32位用于遞增計(jì)數(shù)。
epoch：可以理解為當(dāng)前集群所處的年代或者周期鳍咱，每個(gè)leader就像皇帝降盹，都有自己的年號(hào)，所以每次改朝換代谤辜，leader變更之后蓄坏，都會(huì)在前一個(gè)年代的基礎(chǔ)上加1价捧。這樣就算就得leader崩潰恢復(fù)后，也沒有人聽他的了涡戳，因?yàn)閒ollower只聽從當(dāng)前l(fā)eader的命令结蟋。
epoch的變化可以做一個(gè)簡(jiǎn)單的實(shí)驗(yàn)：
1、啟動(dòng)一個(gè)zookeeper集群渔彰；
2嵌屎、在/tmp/zookeeper/VERSION-2路徑下會(huì)看到一個(gè)currentEpoch文件，文件中顯示的是當(dāng)前的epoch恍涂；
3宝惰、把leader節(jié)點(diǎn)停機(jī)，這個(gè)時(shí)候在看currentEpoch會(huì)有變化再沧，隨著每次選舉新的leader尼夺，epoch都會(huì)發(fā)生變化。
leader選舉
leader選舉會(huì)分兩個(gè)過程
啟動(dòng)的時(shí)候leader選舉产园、leader崩潰的時(shí)候的選舉
服務(wù)器啟動(dòng)時(shí)的leader選舉
每個(gè)節(jié)點(diǎn)啟動(dòng)的時(shí)候狀態(tài)都是LOOKING汞斧，處于觀望狀態(tài)，接下來就開始進(jìn)行選主流程什燕。
進(jìn)行l(wèi)eader選舉，至少需要兩臺(tái)機(jī)器竞端，我們選取3臺(tái)機(jī)器的服務(wù)器集群為例屎即。在集群初始化階段，當(dāng)有一臺(tái)服務(wù)器server1啟動(dòng)時(shí)事富，它本身是無法進(jìn)行和完成leader選舉技俐，當(dāng)?shù)诙シ?wù)器server2啟動(dòng)時(shí)，這個(gè)時(shí)候機(jī)器可以互相通信统台，每臺(tái)機(jī)器都試圖找到leader雕擂，于是進(jìn)入leader選舉過程，選舉過程如下：
1贱勃、每個(gè)server發(fā)出一個(gè)投票井赌，由于是初始情況，server1和server2都會(huì)將自己作為leader服務(wù)器來進(jìn)行投票贵扰，每次投票都會(huì)包含所推舉的服務(wù)器的myid和zxid仇穗、epoch，使用（myid戚绕、zxid纹坐、epoch）來表示，此時(shí)server1的投票為（1舞丛，0）耘子，server2的投票為（2,0）果漾，然后各自將這個(gè)投票發(fā)給集群中其他機(jī)器。
2谷誓、接受來自各個(gè)服務(wù)器的投票绒障，集群的每個(gè)服務(wù)器收到投票后，首先判斷該投票的有效性片林，如檢查是否是本輪投票（epoch）端盆、是否來自LOOKING狀態(tài)的服務(wù)器。
3费封、處理投票焕妙，針對(duì)每一個(gè)投票，服務(wù)器都需要將別人的投票和自己的投票進(jìn)行PK弓摘，PK規(guī)則如下：
i焚鹊、優(yōu)先檢查zxid，zxid比較大的服務(wù)器優(yōu)先作為leader韧献；
ii末患、如果zxid相同，那么就比較myid锤窑，myid較大的服務(wù)器作為leader服務(wù)器璧针。對(duì)于server1而言，它的投票是（1渊啰，0）探橱，接受server2的投票為（2，0）绘证，首先會(huì)比較兩者的zxid隧膏，均為0，在比較myid嚷那，此時(shí)server2的myid最大胞枕，于是更新自己的投票為（2，0）魏宽，然后重新投票腐泻，對(duì)于server2而言，它不需要更新自己的投票湖员，只是再次向集群中所有機(jī)器發(fā)出上一次投票信息即可贫悄。
4、統(tǒng)計(jì)投票娘摔，每次投票后窄坦，服務(wù)器都會(huì)統(tǒng)計(jì)投票信息，判斷是否已經(jīng)有過半機(jī)器接受相同的投票信息，對(duì)于server1鸭津、server2而言彤侍，都統(tǒng)計(jì)出集群中已經(jīng)有兩臺(tái)機(jī)器接受了（2，0）的投票信息逆趋，此時(shí)便認(rèn)為已經(jīng)選出了leader盏阶。
5、改變服務(wù)器狀態(tài)闻书，一旦確定了leader名斟，每個(gè)服務(wù)器就會(huì)更新自己的狀態(tài)，如果是follower魄眉，那么就變更為FOLLOWING砰盐，如果是leader就變更為LEADING。
運(yùn)行過程中的leader選舉
當(dāng)集群中的leader服務(wù)器出現(xiàn)宕機(jī)或者不可用的情況時(shí)坑律，那么整個(gè)集群將無法對(duì)外提供服務(wù)岩梳，而是進(jìn)入新一輪的leader選舉，服務(wù)器運(yùn)行期間的leader選舉和啟動(dòng)時(shí)期的leader選舉基本過程是一致的晃择。
1冀值、變更狀態(tài)，leader掛后宫屠，余下的非observer服務(wù)器都會(huì)將自己的服務(wù)器狀態(tài)變更為LOOKING列疗，然后開始進(jìn)入leader選舉過程。
2浪蹂、每個(gè)server會(huì)發(fā)出一個(gè)投票作彤，在運(yùn)行期間，每個(gè)服務(wù)器上的zxid可能不同乌逐，此時(shí)假定server1的zxid為123，server3的zxid為122创葡，在第一輪投票中浙踢，server1和server3都會(huì)投自己，產(chǎn)生投票（1灿渴，123）洛波，（3，122）骚露，然后各自將投票發(fā)送給集群中所有機(jī)器蹬挤，接收來自各個(gè)服務(wù)器的投票，與啟動(dòng)時(shí)過程相同棘幸。
3焰扳、處理投票，與啟動(dòng)時(shí)過程相同，此時(shí)吨悍，server1將會(huì)成為leader扫茅。
4、統(tǒng)計(jì)投票育瓜，與啟動(dòng)時(shí)過程相同葫隙。
5、改變服務(wù)器的狀態(tài)躏仇，與啟動(dòng)時(shí)過程相同恋脚。
學(xué)習(xí)來源https://www.gupaoedu.com/
