Zookeeper和分布式環(huán)境中的假死腦裂問題 ?

最近和同事聊天無意間發(fā)現(xiàn)他們的系統(tǒng)也存在腦裂的問題。想想當(dāng)初在我們的系統(tǒng)中為了解決腦裂花了非常大的功夫，現(xiàn)在和大家一起討論下腦裂，假死等等這些問題和解決的方法。 在一個(gè)大集群中往往會有一個(gè)master存在，在長期運(yùn)行過程中不可避免的會出現(xiàn)宕機(jī)等問題導(dǎo)致master不可用，在出現(xiàn)這樣的情況以后往往會對系統(tǒng)產(chǎn)生很大的影響，所以一般的分布式集群中的master都采用了高可用的解決方案來避免這樣的情況發(fā)生。 master-slaver方式，存在一個(gè)master節(jié)點(diǎn)，平時(shí)對外服務(wù)，同時(shí)有一個(gè)slaver節(jié)點(diǎn)，監(jiān)控著master，同時(shí)有某種方式來進(jìn)行數(shù)據(jù)的同步。如果在master掛掉以后slaver能很快獲知并迅速切換成為新的master。在以往master-slaver的監(jiān)控切換是個(gè)很大的難題，但是現(xiàn)在有了Zookeeper的話能比較優(yōu)雅的解決這一類問題。 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?master-slaver結(jié)構(gòu) master-slaver實(shí)現(xiàn)起來非常簡單，而且在master上面的各種操作效率要較其他HA解決方案要高，早期的時(shí)候監(jiān)控和切換很難控制，但是后來zookeeper出現(xiàn)了，他的watch和分布式鎖機(jī)制很好的解決了這一類問題。 我們的系統(tǒng)和同事的系統(tǒng)都是這種模式，但是后來都發(fā)現(xiàn)由于ZooKeeper使用上的問題存在腦裂的問題。 記得很久以前參加一個(gè)大牛的技術(shù)交流會他就提到過在集群中假死問題是一個(gè)非常讓人頭痛的問題，假死也是導(dǎo)致腦裂的根源。 根據(jù)一個(gè)什么樣的情況能判斷一個(gè)節(jié)點(diǎn)死亡了down掉了，人可能很容易判斷，但是對于在分布式系統(tǒng)中這些是有監(jiān)控者來判斷的，對于監(jiān)控者來說很難判定其他的節(jié)點(diǎn)的狀態(tài)，唯一可靠點(diǎn)途徑的就是心跳，包括ZooKeeper就是使用心跳來判斷客戶端是否仍然活著的，使用ZooKeeper來做master HA基本都是同樣的方式，每個(gè)節(jié)點(diǎn)都嘗試注冊一個(gè)象征master的臨時(shí)節(jié)點(diǎn)其他沒有注冊成功的則成為slaver，并且通過watch機(jī)制監(jiān)控著master所創(chuàng)建的臨時(shí)節(jié)點(diǎn)，Zookeeper通過內(nèi)部心跳機(jī)制來確定master的狀態(tài)，一旦master出現(xiàn)意外Zookeeper能很快獲悉并且通知其他的slaver，其他slaver在之后作出相關(guān)反應(yīng)。這樣就完成了一個(gè)切換。這種模式也是比較通用的模式，基本大部分都是這樣實(shí)現(xiàn)的，但是這里面有個(gè)很嚴(yán)重的問題，如果注意不到會導(dǎo)致短暫的時(shí)間內(nèi)系統(tǒng)出現(xiàn)腦裂，因?yàn)樾奶霈F(xiàn)超時(shí)可能是master掛了，但是也可能是master，zookeeper之間網(wǎng)絡(luò)出現(xiàn)了問題，也同樣可能導(dǎo)致。這種情況就是假死，master并未死掉，但是與ZooKeeper之間的網(wǎng)絡(luò)出現(xiàn)問題導(dǎo)致Zookeeper認(rèn)為其掛掉了然后通知其他節(jié)點(diǎn)進(jìn)行切換，這樣slaver中就有一個(gè)成為了master，但是原本的master并未死掉，這時(shí)候client也獲得master切換的消息，但是仍然會有一些延時(shí)，zookeeper需要通訊需要一個(gè)一個(gè)通知，這時(shí)候整個(gè)系統(tǒng)就很混亂可能有一部分client已經(jīng)通知到了連接到新的master上去了，有的client仍然連接在老的master上如果同時(shí)有兩個(gè)client需要對master的同一個(gè)數(shù)據(jù)更新并且剛好這兩個(gè)client此刻分別連接在新老的master上，就會出現(xiàn)很嚴(yán)重問題。 出現(xiàn)這種情況的主要原因在與Zookeeper集群和Zookeeperclient判斷超時(shí)并不能做到完全同步（這些還依賴于操作系統(tǒng)調(diào)度等，很難保證），也就是說可能一前一后，如果是集群先于client發(fā)現(xiàn)那就會出現(xiàn)上面的情況了。同時(shí)在發(fā)現(xiàn)并切換后通知各個(gè)客戶端也有先后快慢。出現(xiàn)這種情況的幾率很小，需要master與zookeeper集群網(wǎng)絡(luò)斷開但是與其他集群角色之間的網(wǎng)絡(luò)沒有問題，還要滿足上面那些條件，但是一旦出現(xiàn)就會引發(fā)很嚴(yán)重的后果，數(shù)據(jù)不一致了。 避免這種情況其實(shí)也很簡單，在slaver切換的時(shí)候不在檢查到老的master出現(xiàn)問題后馬上切換，而是在休眠一段足夠的時(shí)間，確保老的master已經(jīng)獲知變更并且做了相關(guān)的shutdown清理工作了然后再注冊成為master就能避免這類問題了，這個(gè)休眠時(shí)間一般定義為與zookeeper定義的超時(shí)時(shí)間就夠了，但是這段時(shí)間內(nèi)系統(tǒng)可能是不可用的，但是相對于數(shù)據(jù)不一致的后果我想還是值得的。 當(dāng)然最徹底的解決這類問題的方案是將master HA集群做成peer2peer的，屏蔽掉外部Zookeeper的依賴。每個(gè)節(jié)點(diǎn)都是對等的沒有主次，這樣就不會存在腦裂的問題，但是這種ha解決方案需要使用兩階段，paxos這類數(shù)據(jù)一致性保證協(xié)議來實(shí)現(xiàn)，不可避免的會降低系統(tǒng)數(shù)據(jù)變更的系統(tǒng)，如果系統(tǒng)中主要是對master的讀取操作很少更新就很適合了。 原文地址：http://backend.blog.163.com/blog/static/20229412620128911939110/

轉(zhuǎn)載于:https://www.cnblogs.com/rainy-shurun/p/5414110.html

總結(jié)

以上是生活随笔為你收集整理的Zookeeper和分布式环境中的假死脑裂问题(转)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。