大數(shù)據(jù)之分布式協(xié)調(diào)神器：Zookeeper選舉
前言
分布式系統(tǒng)設(shè)計(jì)成主從節(jié)點(diǎn)主要是為了保障數(shù)據(jù)一致性，主從設(shè)計(jì)是一種最直觀的數(shù)據(jù)一致性保障機(jī)制。
比如主從復(fù)制，主節(jié)點(diǎn)負(fù)責(zé)寫，從節(jié)點(diǎn)負(fù)責(zé)讀，提高讀的性能。從節(jié)點(diǎn)定期通過心跳與主節(jié)點(diǎn)溝通，一旦主節(jié)點(diǎn)掛掉了，從節(jié)點(diǎn)馬上接手主節(jié)點(diǎn)的任務(wù)。
但是主節(jié)點(diǎn)暫時(shí)失去響應(yīng)，如瞬時(shí)負(fù)載過高，網(wǎng)絡(luò)擁塞或者其他原因?qū)е轮鞴?jié)點(diǎn)暫時(shí)失去響應(yīng)，超過響應(yīng)超時(shí)時(shí)間，這個(gè)時(shí)候從節(jié)點(diǎn)啟動(dòng)，承擔(dān)起leader的職責(zé)，但是原先的主節(jié)點(diǎn)又恢復(fù)了服務(wù)。這個(gè)時(shí)候，如果沒有選舉機(jī)制(不能僅僅自己宣告自己是leader，還要廣而告之，讓其他服務(wù)器或者客戶端知道自己是leader)，有可能會(huì)存在兩個(gè)leader節(jié)點(diǎn)，導(dǎo)致集群發(fā)生混亂。
所以有了以下關(guān)于大數(shù)據(jù)框架主從選舉的總結(jié)，趕快收藏吧!總有一個(gè)不經(jīng)意時(shí)刻你會(huì)用到。
Zookeeper選舉
Zookeeper介紹
Zookeeper從設(shè)計(jì)模式角度來理解，是一個(gè)基于觀察者模式設(shè)計(jì)的分布式服務(wù)管理框架，它負(fù)責(zé)存儲(chǔ)和管理大家都關(guān)心的數(shù)據(jù)，然后接受觀察者的注冊(cè)，一旦這些數(shù)據(jù)的狀態(tài)發(fā)生了變化，Zookeeper就負(fù)責(zé)通知已經(jīng)在Zookeeper上注冊(cè)的那些觀察者做出相應(yīng)的反應(yīng)。
Zookeeper特點(diǎn)
集群種只要有半數(shù)以上節(jié)點(diǎn)存活，Zookeeper集群就能正常提供服務(wù)。所以這就是選舉機(jī)制的奇數(shù)原則(Zookeeper適合安裝奇數(shù)臺(tái)服務(wù))。
一個(gè)領(lǐng)導(dǎo)者Leaders和多個(gè)跟隨者Follower組成的集群。
Zookeeper的選舉機(jī)制
全新集群選舉
假設(shè)有五臺(tái)服務(wù)器組成的Zookeeper集群，它們的id從Service1到Service5，同時(shí)它們都是最新啟動(dòng)的，也就是沒有歷史數(shù)據(jù)，在存放數(shù)據(jù)量這一點(diǎn)上，都是一樣的。假設(shè)這些服務(wù)器依序啟動(dòng)，來看看會(huì)發(fā)生什么。
- 服務(wù)器1啟動(dòng)，發(fā)起一次選舉。服務(wù)器1投自己一票。此時(shí)服務(wù)器1票數(shù)一票，不夠半數(shù)以上(3票)，選舉無法完成，服務(wù)器1狀態(tài)保持為L(zhǎng)OOKING;
- 服務(wù)器2啟動(dòng)，再發(fā)起一次選舉。服務(wù)器1和2分別投自己一票并交換選票信息：此時(shí)服務(wù)器1發(fā)現(xiàn)服務(wù)器2的ID比自己目前投票推舉的(服務(wù)器1)大，更改選票為推舉服務(wù)器2。此時(shí)服務(wù)器1票數(shù)0票，服務(wù)器2票數(shù)2票，沒有半數(shù)以上結(jié)果，選舉無法完成，服務(wù)器1，2狀態(tài)保持LOOKING。
- 服務(wù)器3啟動(dòng)，發(fā)起一次選舉。此時(shí)服務(wù)器1和2都會(huì)更改選票為服務(wù)器3。此次投票結(jié)果：服務(wù)器1為0票，服務(wù)器2為0票，服務(wù)器3為3票。此時(shí)服務(wù)器3的票數(shù)已經(jīng)超過半數(shù)，服務(wù)器3當(dāng)選Leader。服務(wù)器1，2更改狀態(tài)為FOLLOWING，服務(wù)器3更改狀態(tài)為L(zhǎng)EADING。
- 服務(wù)器4啟動(dòng)，發(fā)起一次選舉。此時(shí)服務(wù)器1，2，3已經(jīng)不是LOOKING狀態(tài)，不會(huì)更改選票信息。交換選票信息結(jié)果：服務(wù)器3為3票，服務(wù)器4為1票。此時(shí)服務(wù)器4服從多數(shù)，更改選票信息為服務(wù)器3，并更改狀態(tài)為FOLLOWING。
- 服務(wù)器5啟動(dòng)，同第4步一樣當(dāng)FOLLOWING。
非全新集群選舉
對(duì)于運(yùn)行正常的zookeeper集群，中途有機(jī)器down掉，需要重新選舉時(shí)，選舉過程就需要加入數(shù)據(jù)ID、服務(wù)器ID、和邏輯時(shí)鐘。
邏輯時(shí)鐘：這個(gè)值從0開始，每次選舉必須一致。小的選舉結(jié)果被忽略，重新投票(除去選舉次數(shù)不完整的服務(wù)器)。
數(shù)據(jù)id：數(shù)據(jù)新的version大，數(shù)據(jù)每次更新都會(huì)更新version。數(shù)據(jù)id大的勝出(選出數(shù)據(jù)最新的服務(wù)器)。
服務(wù)器id：即myid。數(shù)據(jù)id相同的情況下，服務(wù)器id大的勝出(數(shù)據(jù)相同的情況下，選擇服務(wù)器id最大，即權(quán)重最大的服務(wù)器)。
Kafka依賴Zookeeper的選舉
Kafka依賴ZK做了哪些事
ZooKeeper 作為給分布式系統(tǒng)提供協(xié)調(diào)服務(wù)的工具被 kafka 所依賴。在分布式系統(tǒng)中，消費(fèi)者需要知道有哪些生產(chǎn)者是可用的，而如果每次消費(fèi)者都需要和生產(chǎn)者建立連接并測(cè)試是否成功連接，那效率也太低了，顯然是不可取的。而通過使用 ZooKeeper 協(xié)調(diào)服務(wù)，Kafka 就能將 Producer，Consumer，Broker 等結(jié)合在一起，同時(shí)借助 ZooKeeper，Kafka 就能夠?qū)⑺薪M件在無狀態(tài)的條件下建立起生產(chǎn)者和消費(fèi)者的訂閱關(guān)系，實(shí)現(xiàn)負(fù)載均衡。
Kafka選舉
Leader維護(hù)了一個(gè)動(dòng)態(tài)的in-sync replica set (ISR)，意為和leader保持同步的follower集合。當(dāng)ISR中的follower完成數(shù)據(jù)的同步之后，leader就會(huì)給follower發(fā)送ack。如果follower長(zhǎng)時(shí)間未向leader同步數(shù)據(jù)，則該follower將被踢出ISR，該時(shí)間閾值由replica.lag.time.max.ms參數(shù)設(shè)定。Leader發(fā)生故障之后，就會(huì)從ISR中選舉新的leader。
因此這個(gè)集合中的任何一個(gè)節(jié)點(diǎn)隨時(shí)都可以被選為leader。ISR在ZooKeeper中維護(hù)。ISR中有f+1個(gè)節(jié)點(diǎn)(follow+leader)，就可以允許在f個(gè)節(jié)點(diǎn)down掉的情況下不會(huì)丟失消息并正常提供服。ISR的成員是動(dòng)態(tài)的，如果一個(gè)節(jié)點(diǎn)被淘汰了，當(dāng)它重新達(dá)到“同步中”的狀態(tài)時(shí)，他可以重新加入ISR。因此如果leader宕了，直接從ISR中選擇一個(gè)follower就行。
如果全掛呢?
一旦所有節(jié)點(diǎn)都down了，Kafka不會(huì)保證數(shù)據(jù)的不丟失。所以當(dāng)副本都down掉時(shí)，必須及時(shí)作出反應(yīng)。等待ISR中的任何一個(gè)節(jié)點(diǎn)恢復(fù)并擔(dān)任leader。
附：Kafka為什么要放棄ZK
本身就是一個(gè)分布式系統(tǒng)，但是需要另一個(gè)分布式系統(tǒng)來管理，復(fù)雜性無疑增加了。
部署的時(shí)候必須要部署兩套系統(tǒng)，的運(yùn)維人員必須要具備的運(yùn)維能力。
Controller故障處理：依賴一個(gè)單一節(jié)點(diǎn)跟進(jìn)行交互，如果這個(gè)節(jié)點(diǎn)發(fā)生了故障，就需要從中選擇新的，新的選舉成功后，會(huì)重新從拉取元數(shù)據(jù)進(jìn)行初始化，并且需要通知其他所有的更新。老的需要關(guān)閉監(jiān)聽、事件處理線程和定時(shí)任務(wù)。分區(qū)數(shù)非常多時(shí)，這個(gè)過程非常耗時(shí)，而且這個(gè)過程中集群是不能工作的。
當(dāng)分區(qū)數(shù)增加時(shí)，保存的元數(shù)據(jù)變多，集群壓力變大
基于ZooKeeper的Hadoop高可用
HDFS 高可用
介紹
一個(gè)典型的HA集群，NameNode會(huì)被配置在兩臺(tái)獨(dú)立的機(jī)器上，在任何時(shí)間上，一個(gè)NameNode處于活動(dòng)狀態(tài)，而另一個(gè)NameNode處于備份狀態(tài)，活動(dòng)狀態(tài)的NameNode會(huì)響應(yīng)集群中所有的客戶端，備份狀態(tài)的NameNode只是作為一個(gè)副本，保證在必要的時(shí)候提供一個(gè)快速的轉(zhuǎn)移。所以對(duì)于HDFS來說，高可用其實(shí)就是針對(duì)NameNode的高可用。因?yàn)镹ameNode保存著集群的元數(shù)據(jù)信息，一旦丟失整個(gè)集群將不復(fù)存在。
主備切換控制器 ZKFailoverController：ZKFC 作為獨(dú)立的進(jìn)程運(yùn)行，對(duì) NameNode 的主備切換進(jìn)行總體控制。ZKFailoverController 能及時(shí)檢測(cè)到 NameNode 的健康狀況，在主 NameNode 故障時(shí)借助 Zookeeper 實(shí)現(xiàn)自動(dòng)的主備選舉和切換，當(dāng)然 NameNode 目前也支持不依賴于 Zookeeper 的手動(dòng)主備切換。
原理
當(dāng)HDFS的兩臺(tái)NN啟動(dòng)時(shí)，ZKFC(Zookeeper FailoverController)也會(huì)啟動(dòng)，ZKFC會(huì)向ZK上寫一個(gè)臨時(shí)序列化的節(jié)點(diǎn)(默認(rèn)節(jié)點(diǎn)名是：/hadoop-ha)并取得和ZK的連接，一旦NN掛掉，那么ZKFC也會(huì)掛掉，該節(jié)點(diǎn)會(huì)被ZK自動(dòng)刪除掉，ZKFC有Watcher機(jī)制(當(dāng)子節(jié)點(diǎn)發(fā)生變化時(shí)觸動(dòng))，另一個(gè)伴隨著NN啟動(dòng)的ZKFC發(fā)現(xiàn)子節(jié)點(diǎn)變化了，是不是排在第一位，是，就通知第二臺(tái)NN開始接管，向JN同步數(shù)據(jù)(下載IDS文件并和FImage合并，并生成新的FImage)，將元數(shù)據(jù)都變成最新的，若是掛掉的NN重新啟動(dòng)，那么ZKFC還會(huì)向ZK寫個(gè)節(jié)點(diǎn)，等現(xiàn)接管的NN掛掉后再接管成為Master。
什么是ZKFC?
- ZKFC是一個(gè)Zookeeper的客戶端，它主要用來監(jiān)測(cè)和管理NameNodes的狀態(tài)，每個(gè)NameNode機(jī)器上都會(huì)運(yùn)行一個(gè)ZKFC程序，它的職責(zé)主要有：一是健康監(jiān)控。ZKFC間歇性的ping NameNode，得到NameNode返回狀態(tài)，如果NameNode失效或者不健康，那么ZKFS將會(huì)標(biāo)記其為不健康;
- Zookeeper會(huì)話管理。當(dāng)本地NaneNode運(yùn)行良好時(shí)，ZKFC將會(huì)持有一個(gè)Zookeeper session，如果本地NameNode為Active，它同時(shí)也持有一個(gè)“排他鎖”znode，如果session過期，那么次lock所對(duì)應(yīng)的znode也將被刪除;
- 選舉。當(dāng)集群中其中一個(gè)NameNode宕機(jī)，Zookeeper會(huì)自動(dòng)將另一個(gè)激活。
內(nèi)部操作與原理
HealthMonitor 初始化完成之后會(huì)啟動(dòng)內(nèi)部的線程來定時(shí)調(diào)用對(duì)應(yīng) NameNode 的 HAServiceProtocol RPC 接口的方法，對(duì) NameNode 的健康狀態(tài)進(jìn)行檢測(cè)。
HealthMonitor 如果檢測(cè)到 NameNode 的健康狀態(tài)發(fā)生變化，會(huì)回調(diào) ZKFailoverController 注冊(cè)的相應(yīng)方法進(jìn)行處理。
如果 ZKFailoverController 判斷需要進(jìn)行主備切換，會(huì)首先使用 ActiveStandbyElector 來進(jìn)行自動(dòng)的主備選舉。
ActiveStandbyElector 與 Zookeeper 進(jìn)行交互完成自動(dòng)的主備選舉。
ActiveStandbyElector 在主備選舉完成后，會(huì)回調(diào) ZKFailoverController 的相應(yīng)方法來通知當(dāng)前的 NameNode 成為主 NameNode 或備 NameNode。
ZKFailoverController 調(diào)用對(duì)應(yīng) NameNode 的 HAServiceProtocol RPC 接口的方法將 NameNode 轉(zhuǎn)換為 Active 狀態(tài)或 Standby 狀態(tài)。
幾句話描述就是：ZooKeeper提供了簡(jiǎn)單的機(jī)制來實(shí)現(xiàn)Acitve Node選舉，如果當(dāng)前Active失效，Standby將會(huì)獲取一個(gè)特定的排他鎖，那么獲取鎖的Node接下來將會(huì)成為Active。
Yarn高可用
介紹
YARN ResourceManager 的高可用與 HDFS NameNode 的高可用類似但是 ResourceManager 不像 NameNode ，沒有那么多的元數(shù)據(jù)信息需要維護(hù)，所以它的狀態(tài)信息可以直接寫到 Zookeeper 上，并依賴 Zookeeper 來進(jìn)行主備選舉。
內(nèi)部操作與原理
- 在ZooKeeper上會(huì)有一個(gè)/yarn-leader-election/yarn1的鎖節(jié)點(diǎn)，所有的ResourceManager在啟動(dòng)的時(shí)候，都會(huì)去競(jìng)爭(zhēng)寫一個(gè)Lock子節(jié)點(diǎn)：/yarn-leader-election/yarn1/ActiveBreadCrumb，該節(jié)點(diǎn)是臨時(shí)節(jié)點(diǎn)。ZooKeepr能夠保證最終只有一個(gè)ResourceManager能夠創(chuàng)建成功。創(chuàng)建成功的那個(gè)ResourceManager就切換為Active狀態(tài)，沒有成功的那些ResourceManager則切換為Standby狀態(tài)。
- RM會(huì)把job的信息存放在zookeeper的/rmstore目錄下，active RM會(huì)向這個(gè)目錄寫app的信息。當(dāng)active RM掛掉之后，standby RM會(huì)通過zkfc切換為active狀態(tài)，然后從zookeeper的/rmstore目錄下讀取相應(yīng)的作業(yè)信息。重新構(gòu)建作業(yè)的內(nèi)存信息，啟動(dòng)內(nèi)部服務(wù)，開始接受NM的心跳信息，構(gòu)建集群的資源信息，并且接受客戶端的作業(yè)提交請(qǐng)求。
其他與總結(jié)
在大數(shù)據(jù)領(lǐng)域，還有許多框架依賴與Zookeeper去選擇主從：比如Hbase集群，Kudu集群，Impala集群等等，最底層的原理大徑相同。
總結(jié)
選舉：Zookeeper能夠很容易的實(shí)現(xiàn)集群管理的功能，若有多臺(tái)Server組成一個(gè)服務(wù)集群，則必須要一個(gè)leader知道集群中每臺(tái)機(jī)器的服務(wù)狀態(tài)，從而做出調(diào)整重新分配服務(wù)策略。當(dāng)集群中增加一臺(tái)或多臺(tái)Server時(shí)，leader同樣需要知道。Zookeeper不僅能夠維護(hù)當(dāng)前的集群中機(jī)器的服務(wù)狀態(tài)，而且能夠選出一個(gè)leader來管理集群。
HA(分布式鎖的應(yīng)用)：Master掛掉之后迅速切換到slave節(jié)點(diǎn)。
