zookeeper存在不穩(wěn)定的情況嵌施，偶爾會(huì)出現(xiàn)集群掛掉，服務(wù)不可用的情況莽鸭。近期對(duì)zookeeper容易掛掉的原因做了分析吗伤，現(xiàn)在將結(jié)果分享給大家。
zookeeper是Apache一個(gè)開源的分布式協(xié)調(diào)服務(wù)硫眨，提供的功能包括：
配置管理足淆；
分布式同步；
分布式鎖礁阁；
當(dāng)然巧号，zookeeper還提供其它一些功能，我們一般用的最多的是上面三種姥闭，所以其它的我們不再贅述丹鸿。
下面首先簡(jiǎn)單介紹一下普通zookeeper集群的結(jié)構(gòu)和選舉機(jī)制，zookeeper server集群的模型如下（下面原理性介紹棚品，部分引用自：參考1和參考2靠欢，其它zk相關(guān)原理，也可以參考這篇文章）：
從圖中可以看出南片，在一個(gè)zookeeper服務(wù)模型中掺涛，由若干臺(tái)機(jī)器（一般是奇數(shù)臺(tái)）組成一個(gè)zookeeper集群，其中一臺(tái)機(jī)器擔(dān)任leader疼进，用戶分布式集群中的機(jī)器薪缆，均勻的選擇zookeeper集群中的集群進(jìn)行連接和信息同步。
而集群中的機(jī)器伞广，則都保持與leader的數(shù)據(jù)同步拣帽，這就需要選舉zookeeper集群的leader，選取leader的過程如下：
（下面介紹的是zookeeper默認(rèn)的FastLeaderElection算法嚼锄，這個(gè)算法適用于leader重新選舉或集群掛掉后恢復(fù)選舉减拭，這個(gè)算法與我們后面描述的問題直接相關(guān)，對(duì)于新集群的選舉区丑，有興趣的可以研究一下zookeeper的 basic paxos 算法）：
首先進(jìn)入數(shù)據(jù)（快照）恢復(fù)階段拧粪，每個(gè)zookeeper server讀取本地保存的快照數(shù)據(jù)，數(shù)據(jù)中有個(gè)對(duì)應(yīng)的zxid沧侥，zxid越大可霎，表示該server保存的數(shù)據(jù)越新（也就越應(yīng)該被選為leader）；
讀完數(shù)據(jù)后宴杀，每個(gè)zookeeper server向集群中廣播自己選出的leader的id（有興趣的可以了解概念“原子廣播”）癣朗，如果是首次選舉，則每個(gè)server都發(fā)送自己的id旺罢，也就是選自己為leader旷余。
一個(gè)server廣播的數(shù)據(jù)包括4個(gè)部分：
自己所選取的leader的id：首次選舉的話绢记，這個(gè)id就是自己的id；
當(dāng)前server保存的數(shù)據(jù)的zxid：越新就越應(yīng)該被其它server選為leader正卧，保證數(shù)據(jù)的最新
邏輯時(shí)鐘：也就是這是第幾次選舉蠢熄，越大表示這是越新的選舉；
本機(jī)狀態(tài)：LOOKING,FOLLOWING,OBSERVING,LEADING幾種炉旷；
每個(gè)server收到其它server發(fā)來的值后护赊，進(jìn)行判斷，選擇所保存的數(shù)據(jù)最新（zxid最大）砾跃、邏輯時(shí)鐘最大骏啰，且在選舉狀態(tài)的id作為leader（當(dāng)然，還有其它條件抽高，邏輯比較復(fù)雜判耕，這里不再贅述），并重新廣播翘骂。來來回回幾次之后壁熄，系統(tǒng)達(dá)成一致，得票多的為leader碳竟，leader被選出草丧。
現(xiàn)在leader被選出，但這并不意味著它能坐穩(wěn)leader的位置莹桅，因?yàn)榻酉聛聿矗琹eader要向所有的follower同步自己所保存的數(shù)據(jù)（多寫問題）。如果這個(gè)過程出錯(cuò)或超時(shí)诈泼，則又需要重新選舉leader懂拾；
另一個(gè)問題，從上面的選舉過程中铐达，我們可以看出岖赋，為了保證選舉過程最后能選出leader，就一定不能出現(xiàn)兩臺(tái)機(jī)器得票相同的僵局瓮孙，所以一般的唐断，要求zk集群的server數(shù)量一定要是奇數(shù)，也就是2n+1臺(tái)杭抠，并且脸甘，如果集群出現(xiàn)問題，其中存活的機(jī)器必須大于n+1臺(tái)祈争，否則leader無法獲得多數(shù)server的支持斤程，系統(tǒng)就自動(dòng)掛掉角寸。
對(duì)zookeeper集群而言菩混，還有個(gè)很重要的問題是磁盤io問題忿墅，一般，zookeeper集群中沮峡，有若干次次寫入更新疚脐，就會(huì)觸發(fā)一次數(shù)據(jù)快照保存（在阿里的公共zk機(jī)器，有十萬次寫入邢疙，就會(huì)觸發(fā)一次保存）棍弄。如果有頻繁寫入，則這個(gè)快照保存會(huì)十分頻繁疟游，從而造成IO壓力很大呼畸，所以現(xiàn)在zookeeper一般都是直接使用物理機(jī)，獨(dú)占磁盤颁虐。
從上面的探究中蛮原，我們概況了下面的點(diǎn)：
1. zk集群要求集群的機(jī)器數(shù)為奇數(shù)（2n+1），并且任何時(shí)刻另绩，存活的機(jī)器必須大于n+1儒陨，否則集群掛掉；
2. zk集群選舉后笋籽，要進(jìn)行數(shù)據(jù)同步蹦漠，如果同步失敗，重新選舉车海。
一般一個(gè)zookeeper集群的機(jī)器數(shù)為3或5臺(tái)笛园，不會(huì)更多，因?yàn)楦嗟脑捠讨ィ跀?shù)據(jù)同步的時(shí)候出現(xiàn)多寫問題喘沿，造成的系統(tǒng)壓力會(huì)更大。
那么一般造成zookeeper集群掛掉的原因是什么呢竭贩？歸根到底一句話：要同步的數(shù)據(jù)太大蚜印！多大？500M
zookeeper集群中l(wèi)eader和follower同步數(shù)據(jù)的極限值是500M留量，這500M的數(shù)據(jù)窄赋，加載到內(nèi)存中，大約占用3個(gè)G的內(nèi)存楼熄。數(shù)據(jù)過大忆绰，在每次選舉之后，需要從server同步到follower可岂，容易造成下面2個(gè)問題：
網(wǎng)絡(luò)傳輸超時(shí)错敢，因?yàn)槲募^大，傳輸超過最大超時(shí)時(shí)間，造成TimeoutException稚茅，從而引起重新選舉纸淮。
如果調(diào)大這個(gè)超時(shí)值，則很可能達(dá)到磁盤讀寫的上限亚享，目前咽块，每像精衛(wèi)、tbschedule3等欺税，都有大量的zk寫入侈沪，這些會(huì)觸發(fā)頻繁的磁盤寫操作，一旦達(dá)到io上限值晚凿，就會(huì)導(dǎo)致超時(shí)亭罪，進(jìn)而觸發(fā)重新選舉或直接導(dǎo)致系統(tǒng)崩潰。
所以歼秽，上面兩個(gè)問題皆撩，都可能導(dǎo)致zookeeper集群一直在選舉和數(shù)據(jù)同步之間陷入死循環(huán)。
上面的問題在阿里是普遍的哲银，下面看兩個(gè)例子：
去年tbschedule 3有個(gè)bug扛吞，是ACL list只會(huì)增加不會(huì)減少，導(dǎo)致存儲(chǔ)的ACL數(shù)據(jù)過大荆责，進(jìn)而導(dǎo)致選舉后數(shù)據(jù)同步失敗滥比，又重新選舉的死循環(huán)。導(dǎo)致zk服務(wù)器一直起不來做院，進(jìn)而導(dǎo)致物流寶調(diào)度任務(wù)不執(zhí)行盲泛，系統(tǒng)掛掉的時(shí)間超過1個(gè)小時(shí)。
事實(shí)上键耕，tbschedule 3還存在寫入過于頻繁的問題寺滚，如果寫入頻繁，就會(huì)頻繁觸發(fā)zookeeper保存快照屈雄，進(jìn)而導(dǎo)致IO壓力大村视。
今年近期，匯金平臺(tái)所在的公共zk集群因?yàn)榫l(wèi)數(shù)據(jù)過多而掛掉酒奶。像精衛(wèi)這種應(yīng)用蚁孔，在zookeeper集群上的節(jié)點(diǎn)非常多，存儲(chǔ)的數(shù)據(jù)有200M左右惋嚎，很容易導(dǎo)致數(shù)據(jù)量過大杠氢。這次zookeeper停止服務(wù)的時(shí)間長(zhǎng)達(dá)一個(gè)小時(shí)。
下面就針對(duì)上面的問題分析一下可能的解決方案：
加zookeeper server機(jī)器提高性能：注意另伍，加zookeeper server機(jī)器提高的只是讀性能鼻百，但機(jī)器越多，多寫問題就越嚴(yán)重，系統(tǒng)也越容易掛掉温艇。所以不可行因悲！
冗余一個(gè)集群，作為當(dāng)前集群的備份：冗余出來的集群可以比較小中贝，平時(shí)并不服務(wù)，只有當(dāng)主集群掛掉時(shí)臼朗，再自動(dòng)切換提供服務(wù)邻寿。這種集群級(jí)別的冗余貌似可行，其實(shí)也有問題视哑，導(dǎo)致這種方案可行性也不高绣否，關(guān)鍵問題就在于，需要將數(shù)據(jù)從主集群的leader實(shí)時(shí)同步到備份集群挡毅，這就存在一個(gè)IO問題蒜撮，如果數(shù)據(jù)量大，異常存在網(wǎng)絡(luò)超時(shí)和IO壓力大問題跪呈，如果單獨(dú)提供一個(gè)方案實(shí)現(xiàn)從主集群leader到備份集群的高速同步段磨，那就可以直接用于解決主集群之間掛掉的問題了，更不需要備份集群了耗绿。另外苹支，冗余物理機(jī)作為備份，絕大多數(shù)情況下误阻，這個(gè)物理機(jī)都可能是不提供服務(wù)的债蜜，所以有資源浪費(fèi)的問題。
細(xì)化zk集群：也就是說究反，為防止其它業(yè)務(wù)的影響寻定。如果你的應(yīng)用強(qiáng)依賴zookeeper，則應(yīng)該申請(qǐng)機(jī)器資源精耐，單獨(dú)配置zookeeper服務(wù)器狼速，防止其他應(yīng)用的影響。這是目前比較可行的解決方案卦停。
多機(jī)房分布：zookeeper存在一個(gè)要求唐含，必須有多于n+1臺(tái)機(jī)器存活，否則整個(gè)集群掛掉（zookeeper通過這種方式沫浆，犧牲了穩(wěn)定性捷枯，但保證了數(shù)據(jù)一致性）。在目前阿里的雙機(jī)房策略下专执，無論兩個(gè)機(jī)房怎么分配淮捆，2n+1臺(tái)機(jī)器在兩個(gè)機(jī)房中，都會(huì)存在一個(gè)機(jī)房的機(jī)器數(shù)大于n+1的問題，如果這個(gè)機(jī)房掛掉或機(jī)房切換攀痊，都可能導(dǎo)致整個(gè)zk集群掛掉桐腌。如果想要保住zk集群穩(wěn)定性，就必須至少有3個(gè)機(jī)房苟径，這樣一個(gè)機(jī)房掛掉時(shí)案站，可以保證仍然有n+1臺(tái)機(jī)器存活。這種方案在以后單元化推廣開之后還有可能棘街，在目前雙機(jī)房情況下蟆盐，無解。
最后遭殉，提供給大家一些使用zookeeper時(shí)的注意事項(xiàng)：
能不用zookeeper石挂，就不用zookeeper，如果一定要用险污，盡量不要強(qiáng)依賴zookeeper痹愚；
如果你要用到分布式鎖，zookeeper是個(gè)不錯(cuò)的選擇蛔糯，如果不需要分布式鎖拯腮，你應(yīng)該優(yōu)先考慮不用zookeeper；
采用監(jiān)聽方式蚁飒，而不是主動(dòng)查詢方式疾瓮，相信zookeeper的監(jiān)聽推送吧，只要你實(shí)現(xiàn)的代碼沒問題飒箭，它還是很穩(wěn)定的狼电；
不要對(duì)zookeeper頻繁寫入，它只應(yīng)該存儲(chǔ)控制信息和配置信息弦蹂，也就是說肩碟，它更多應(yīng)該用來做讀操作。
不要把zookeeper作為數(shù)據(jù)存儲(chǔ)器凸椿。
不要與那些大應(yīng)用共用一個(gè)zookeeper集群削祈，你可能會(huì)被它拖掛的。
