簡介
ZooKeeper是用于分布式應(yīng)用程序的分布式答憔，開放源代碼協(xié)調(diào)服務(wù)。它公開了一組簡單的原語幽纷，分布式應(yīng)用程序可以基于這些原語來實(shí)現(xiàn)用于同步涂屁，配置維護(hù)以及組和命名的更高級別的服務(wù)。
詳見：https://zookeeper.apache.org/doc/current/zookeeperOver.html
可快速恢復(fù)leader
1甘穿，leader肯定會掛
2腮恩，服務(wù)不可用
3，不可靠的集群
4温兼，事實(shí)秸滴，zk集群及其高可用
5，如果有一種方式可以快速的恢復(fù)出一個(gè)leader
zookeeper有2中運(yùn)行狀態(tài)
1募判，可用狀態(tài)
2荡含，不可用狀態(tài)
3，不可用狀態(tài)恢復(fù)到可用狀態(tài)應(yīng)該越快越好
特征&保障
paxos協(xié)議
是一個(gè)基于消息傳遞的一致性算法届垫，Leslie Lamport在1990年提出释液，近幾年被廣泛應(yīng)用于分布式計(jì)算中，Google的Chubby装处，Apache的Zookeeper都是基于它的理論來實(shí)現(xiàn)的误债，Paxos還被認(rèn)為是到目前為止唯一的分布式一致性算法，其它的算法都是Paxos的改進(jìn)或簡化妄迁。有個(gè)問題要提一下寝蹈，Paxos有一個(gè)前提：沒有拜占庭將軍問題。就是說Paxos只有在一個(gè)可信的計(jì)算環(huán)境中才能成立登淘，這個(gè)環(huán)境是不會被入侵所破壞的箫老。
詳見：https://www.douban.com/note/208430424
擴(kuò)展 & 可靠性
ZAB（Zookeeper Atomic Broadcast）
所有的Zookeeper處理的事物請求必須僅有一個(gè)機(jī)器來協(xié)調(diào)處理，這樣的機(jī)器被稱之為Leader服務(wù)器黔州，而剩下的其他Zookeeper則稱之為Follower耍鬓，而Leader服務(wù)器則是會將客戶端的事物請求發(fā)給所有的Follwer服務(wù)器，等待所有的Follwer服務(wù)器的反饋流妻，一旦接受到了超過半數(shù)的Follwer服務(wù)器的正常完成事物處理的反饋后界斜，Leader服務(wù)器就會再次發(fā)送一個(gè)Commit消息給所有的Follwer服務(wù)器，要求將剛剛的事物請求進(jìn)行提交合冀。
ZAB協(xié)議有兩種基本的模式各薇，分別為崩潰恢復(fù)和消息廣播。當(dāng)整個(gè)框架在運(yùn)行的過程中，或者是當(dāng)Leader出現(xiàn)網(wǎng)絡(luò)中斷峭判、崩潰重啟等異常的情況的時(shí)候开缎，ZAB協(xié)議就會進(jìn)入恢復(fù)模式，來重新選舉一個(gè)新的Leader服務(wù)器來處理事物請求林螃，當(dāng)新的Leader服務(wù)器選擇出來奕删，并且和過半以上的機(jī)器實(shí)現(xiàn)了狀態(tài)同步后，ZAB的恢復(fù)模式就結(jié)束了疗认。這個(gè)時(shí)候就可以進(jìn)行ZAB的消息廣播模式了完残，如果在這個(gè)過程中有一個(gè)新的Zookeeper加入了當(dāng)前的集群中，就會啟動恢復(fù)模式横漏，直到實(shí)現(xiàn)了和Leader的狀態(tài)同步為止谨设。
正如上述事物處理的過程一樣，Zookeeper中只有Leader可以協(xié)調(diào)處理事物請求缎浇，那么其他的Follower服務(wù)器是不是沒用了呢扎拣？當(dāng)然不是，在整個(gè)Zookeeper集群中素跺，所有的服務(wù)器都可以提供對外的請求處理二蓝，唯一的區(qū)別在于，當(dāng)Follower服務(wù)器接受到了事物請求以后指厌，會轉(zhuǎn)發(fā)給Leader刊愚，讓Leader進(jìn)行統(tǒng)一處理和協(xié)調(diào)而已。當(dāng)然在整個(gè)集群的運(yùn)行過程中會出現(xiàn)很多意外踩验，例如有半數(shù)以上的Follower服務(wù)器無法與Leader進(jìn)行正常通信百拓，就會從消息廣播模式進(jìn)入到崩潰恢復(fù)模式，從其他的機(jī)器中選舉一個(gè)新的Leader出來,同樣的一個(gè)Leader的選舉必須得到超過半數(shù)的機(jī)器的支持晰甚，所以當(dāng)整個(gè)集群的正常服務(wù)的機(jī)器超過半數(shù)，都可以不停的模式轉(zhuǎn)換决帖，保證集群服務(wù)的穩(wěn)定性厕九，一旦出現(xiàn)問題的機(jī)器數(shù)量超過了集群的半數(shù)，整個(gè)集群就不再對外提供事物請求的處理地回，進(jìn)入保護(hù)模式扁远，僅僅可讀。
消息廣播
原子：成功刻像、失敗畅买。沒有中間狀態(tài)（隊(duì)列+2PC）
廣播：分布式多節(jié)點(diǎn)的。全部知道细睡！(過半)
隊(duì)列：FIFO谷羞，順序性
zk的數(shù)據(jù)狀態(tài)在內(nèi)存
用磁盤保存日志
如上圖所示:
- 1, create(ooxx)
client端發(fā)送一個(gè)寫請求到Follower1 - 2, create(ooxx)
Follower1將此寫請求轉(zhuǎn)發(fā)Leader - 3, Zxid:8
Leader接收到寫請求,生成一個(gè)遞增的事務(wù)ID編號：8
并將Zxid:8 和 寫請求寫create(ooxx)入隊(duì)列 - 4-1, log
各Follower接收到請求，檢查本地的已生效或未生效的Zxid與接收到的Zxid:8比較，本地<=8 拒絕湃缎；否則接收犀填； - 4-1, ok
Follower回復(fù)Leader我接收此提議，并記錄到本地日志; - 4-2, write
Leader收集提議的投票數(shù)嗓违，過半則生效, 立即給所有Follower發(fā)通知提議生效九巡，各Follower收到生效的通知?jiǎng)t生成正式的法令； - 5蹂季，over-ok
Leader恢復(fù)Follower1,集群已執(zhí)行完寫請求 - 6冕广，ok
Follower再將Leader的寫成功消息轉(zhuǎn)發(fā)到Client；
即使Follower2由于網(wǎng)絡(luò)延遲未及時(shí)接收到寫請求偿洁，就在此時(shí)client發(fā)出get請求撒汉，有可能獲取到版本較老的數(shù)據(jù)，但可通過sync去向Leader同步數(shù)據(jù)父能，再回調(diào)client端注冊的get方法神凑，從而獲取到最新版本的數(shù)據(jù)
小結(jié)：ZAB協(xié)議中的消息廣播使用的是一個(gè)原子廣播協(xié)議，整體的過程可以看為是一個(gè)二階段提交的過程何吝「任客戶端的事物請求到來以后，Leader服務(wù)器會生成對應(yīng)的事物Proposal爱榕，并且將這個(gè)發(fā)送給當(dāng)前集群范圍內(nèi)的其余的所有的機(jī)器瓣喊，并且收集來自所有Follower機(jī)器的響應(yīng)選票信息，而二階段的過程的具體體現(xiàn)黔酥，移除了傳統(tǒng)二階段的中斷邏輯處理藻三，因此在收集所有Follower機(jī)器的響應(yīng)過程中，Leader不需要等待所有機(jī)器響應(yīng)后才執(zhí)行第二階段跪者，而是只需要等待半數(shù)以上的機(jī)器返回對應(yīng)的響應(yīng)棵帽，即可開啟第二階段。當(dāng)然在這種簡化的二階段過程中渣玲，有可能會因?yàn)長eader突然奔潰逗概，導(dǎo)致數(shù)據(jù)不一致的情況，當(dāng)然出現(xiàn)這種情況就需要啟動崩潰恢復(fù)機(jī)制來處理忘衍，并且所有的消息都是具有FIFO特性的TCP協(xié)議來進(jìn)行網(wǎng)絡(luò)通信的逾苫，從而保證消息廣播過程中的順序性。
而在第一階段枚钓，Leader機(jī)器會將事物消息生成對應(yīng)的Proposal進(jìn)行廣播铅搓，并且會生成一個(gè)單調(diào)遞增的ID，作為事物的ID(ZXID),由于ZAB協(xié)議需要保證事物嚴(yán)格的上下順序性搀捷，所以會嚴(yán)格按照ZXID的先后來處理對應(yīng)的消息星掰。而在消息廣播發(fā)起后，Leader會為每一個(gè)Follower服務(wù)器分配一個(gè)單獨(dú)的隊(duì)列，然后將需要廣播出去的事物Proposal依次存放進(jìn)這個(gè)FIFO的隊(duì)列中蹋偏，每個(gè)Follower機(jī)器收到事物消息后便斥，會按照事物日志的方式寫入，成功后反饋給Leader機(jī)器Ack響應(yīng)威始，當(dāng)收到半數(shù)以上的Ack響應(yīng)后枢纠，Leader就會發(fā)起第二階段的Commit消息給所有的Follower機(jī)器，并且這個(gè)時(shí)候Leader也會和Follower一樣進(jìn)行本地事物的提交操作黎棠，完成整個(gè)消息的傳遞和提交晋渺。
崩潰恢復(fù)
ZK選舉過程：
1, 通過3888端口號，完成兩兩通信脓斩！
2, 只要任何人投票木西，都會觸發(fā)那個(gè)準(zhǔn)leader發(fā)起自己的投票
3, 推選制：先比較zxid(<本地則拒絕投票)，如果zxid相同随静，再比較myid（比當(dāng)前myid大則投票+1）
小結(jié)：Leader中的已經(jīng)提交的事物完成同步了八千，那么未提交的廢棄事物怎么剔除呢？在ZAB協(xié)議的事物編號ZXID設(shè)計(jì)中燎猛，是一個(gè)64位的數(shù)字恋捆，整體分為低32位和高32位，低32位可以看成一個(gè)單調(diào)遞增的計(jì)數(shù)器重绷，每一個(gè)事物消息生成ID前沸停，低32位都會進(jìn)行原子的+1操作。而ZXID的高32位代表了epoch的編號昭卓，而epoch則是每一次選舉出新的Leader的過程中愤钾，會從所有的事物ZXID中獲取最大的，然后解析出對應(yīng)的高32位epoch的值候醒，然后將其+1能颁，代表了選舉的次數(shù)，即Leader的生命周期倒淫，并且每一次選舉后伙菊，epoch+1以后，會將低32位的值清零昌简，作為新的ZXID值。因此當(dāng)選舉觸發(fā)過程中绒怨，有部分機(jī)器的ZXID所代表的epoch值較低的時(shí)候纯赎，這些機(jī)器直接會成為Follower，只會有epoch最大并且一樣的機(jī)器之間進(jìn)行選舉出Leader南蹂，而當(dāng)Leader選舉出來以后犬金，所有的Follower連接上Leader以后,會和Leader比較當(dāng)前最大的Proposal，這個(gè)時(shí)候Leader根據(jù)比較情況要求回滾或者同步Proposal到當(dāng)前集群中過半機(jī)器都提交的最大事物Proposal，至此數(shù)據(jù)同步操作完成晚顷，崩潰恢復(fù)模式結(jié)束
- 參考文章
https://zookeeper.apache.org/doc/current/zookeeperOver.html
https://www.douban.com/note/208430424/
———————————————————
坐標(biāo)帝都峰伙，白天上班族，晚上是知識的分享者
如果讀完覺得有收獲的話该默，歡迎點(diǎn)贊加關(guān)注
