云計(jì)算大數(shù)據(jù)培訓(xùn)之Hadoop組件：zookeeper（3）

鼻祖級應(yīng)用，ResourceManager在整個(gè)hadoop中算是單點(diǎn)，為了實(shí)現(xiàn)其高可用，分為主備ResourceManager，zookeeper在其中管理整個(gè)ResourceManager。

可以想象，主備ResourceManager最初是主RM提供服務(wù)，如果一切安好，則zookeeper無用武之地。然而，總歸會出現(xiàn)主RM提供不了服務(wù)的情況。于是會出現(xiàn)主備切換的情況，而zookeeper正是為主備切換保駕護(hù)航。

先來推理一下，主備切換會出現(xiàn)什么問題。傳統(tǒng)的主備切換，可以讓主備之間維持心跳連接，一旦備機(jī)發(fā)現(xiàn)主機(jī)心跳檢測不到了，則自己切換為主機(jī)，原來的主機(jī)等待救援。這種方式有兩個(gè)問題，一是由于網(wǎng)絡(luò)抖動，負(fù)載過大等問題，備機(jī)檢測不到心跳并不能說明主機(jī)一定掛了，有可能一定時(shí)間后主機(jī)或網(wǎng)絡(luò)恢復(fù)，這時(shí)候主機(jī)并不知道備機(jī)已經(jīng)切換為主機(jī)，2臺主機(jī)互相爭用，可能造成腦裂；二是如果一些數(shù)據(jù)集中在主機(jī)上面，則備機(jī)切換時(shí)由于同步延時(shí)勢必會損失掉一部分的數(shù)據(jù)。

如何解決這些問題？早期的方式提供了不少解決方案，比如備機(jī)一旦切換為主機(jī)，則通過電源控制直接切斷主機(jī)電源，簡單粗暴，但是此刻備機(jī)已經(jīng)是單點(diǎn)，如果主機(jī)是因?yàn)榱繐尾蛔《鴴欤莻錂C(jī)有可能會重蹈覆轍，最終導(dǎo)致整個(gè)服務(wù)不可用。

zookeeper又是如何解決這個(gè)問題的呢？

zookeeper作為第三方集群參與到主備節(jié)點(diǎn)中去，當(dāng)主備啟動時(shí)會在zookeeper上競爭創(chuàng)建一個(gè)臨時(shí)鎖節(jié)點(diǎn)，爭用成功者則充當(dāng)主機(jī)，其余備機(jī)；

所有備機(jī)會監(jiān)聽該臨時(shí)鎖節(jié)點(diǎn)，一旦主機(jī)與zookeeper間session失效，則臨時(shí)節(jié)點(diǎn)被刪除；

一旦臨時(shí)節(jié)點(diǎn)被刪除，備機(jī)開始重新申請創(chuàng)建臨時(shí)鎖節(jié)點(diǎn)，重新爭用為主機(jī)；

用zookeeper如何解決腦裂？實(shí)際上主機(jī)爭用到節(jié)點(diǎn)后通過對根節(jié)點(diǎn)做一個(gè)ACL權(quán)限控制，則其他搶占的機(jī)器由于無法更新臨時(shí)鎖節(jié)點(diǎn)，只有放棄成為備機(jī)。

zookeeper使用了非常簡單又現(xiàn)成的方式來解決的這個(gè)問題，比起其他方案方便不少，這也是為啥zookeeper流行的原因。說白了，就是把復(fù)雜操作封裝化精簡化。