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

鼻祖級應用，ResourceManager在整個hadoop中算是單點，為了實現(xiàn)其高可用，分為主備ResourceManager，zookeeper在其中管理整個ResourceManager。

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

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

如何解決這些問題？早期的方式提供了不少解決方案，比如備機一旦切換為主機，則通過電源控制直接切斷主機電源，簡單粗暴，但是此刻備機已經是單點，如果主機是因為量撐不住而掛，那備機有可能會重蹈覆轍，最終導致整個服務不可用。

zookeeper又是如何解決這個問題的呢？

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

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

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

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

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