zookeeper存在不穩(wěn)定的情況，偶爾會出現(xiàn)集群掛掉，服務(wù)不可用的情況。近期對zookeeper容易掛掉的原因做了分析，現(xiàn)在將結(jié)果分享給大家。
zookeeper是Apache一個開源的分布式協(xié)調(diào)服務(wù)，提供的功能包括：
配置管理；
分布式同步；
分布式鎖；
當(dāng)然，zookeeper還提供其它一些功能，我們一般用的最多的是上面三種，所以其它的我們不再贅述。
下面首先簡單介紹一下普通zookeeper集群的結(jié)構(gòu)和選舉機制，zookeeper server集群的模型如下（下面原理性介紹，部分引用自：參考1和參考2，其它zk相關(guān)原理，也可以參考這篇文章）：
從圖中可以看出，在一個zookeeper服務(wù)模型中，由若干臺機器（一般是奇數(shù)臺）組成一個zookeeper集群，其中一臺機器擔(dān)任leader，用戶分布式集群中的機器，均勻的選擇zookeeper集群中的集群進行連接和信息同步。
而集群中的機器，則都保持與leader的數(shù)據(jù)同步，這就需要選舉zookeeper集群的leader，選取leader的過程如下：
（下面介紹的是zookeeper默認的FastLeaderElection算法，這個算法適用于leader重新選舉或集群掛掉后恢復(fù)選舉，這個算法與我們后面描述的問題直接相關(guān)，對于新集群的選舉，有興趣的可以研究一下zookeeper的 basic paxos 算法）：
首先進入數(shù)據(jù)（快照）恢復(fù)階段，每個zookeeper server讀取本地保存的快照數(shù)據(jù)，數(shù)據(jù)中有個對應(yīng)的zxid，zxid越大，表示該server保存的數(shù)據(jù)越新（也就越應(yīng)該被選為leader）；
讀完數(shù)據(jù)后，每個zookeeper server向集群中廣播自己選出的leader的id（有興趣的可以了解概念“原子廣播”），如果是首次選舉，則每個server都發(fā)送自己的id，也就是選自己為leader。
一個server廣播的數(shù)據(jù)包括4個部分：
自己所選取的leader的id：首次選舉的話，這個id就是自己的id；
當(dāng)前server保存的數(shù)據(jù)的zxid：越新就越應(yīng)該被其它server選為leader，保證數(shù)據(jù)的最新
邏輯時鐘：也就是這是第幾次選舉，越大表示這是越新的選舉；
本機狀態(tài)：LOOKING,FOLLOWING,OBSERVING,LEADING幾種；
每個server收到其它server發(fā)來的值后，進行判斷，選擇所保存的數(shù)據(jù)最新（zxid最大）、邏輯時鐘最大，且在選舉狀態(tài)的id作為leader（當(dāng)然，還有其它條件，邏輯比較復(fù)雜，這里不再贅述），并重新廣播。來來回回幾次之后，系統(tǒng)達成一致，得票多的為leader，leader被選出。
現(xiàn)在leader被選出，但這并不意味著它能坐穩(wěn)leader的位置，因為接下來，leader要向所有的follower同步自己所保存的數(shù)據(jù)（多寫問題）。如果這個過程出錯或超時，則又需要重新選舉leader；
另一個問題，從上面的選舉過程中，我們可以看出，為了保證選舉過程最后能選出leader，就一定不能出現(xiàn)兩臺機器得票相同的僵局，所以一般的，要求zk集群的server數(shù)量一定要是奇數(shù)，也就是2n+1臺，并且，如果集群出現(xiàn)問題，其中存活的機器必須大于n+1臺，否則leader無法獲得多數(shù)server的支持，系統(tǒng)就自動掛掉。
對zookeeper集群而言，還有個很重要的問題是磁盤io問題，一般，zookeeper集群中，有若干次次寫入更新，就會觸發(fā)一次數(shù)據(jù)快照保存（在阿里的公共zk機器，有十萬次寫入，就會觸發(fā)一次保存）。如果有頻繁寫入，則這個快照保存會十分頻繁，從而造成IO壓力很大，所以現(xiàn)在zookeeper一般都是直接使用物理機，獨占磁盤。
從上面的探究中，我們概況了下面的點：
1. zk集群要求集群的機器數(shù)為奇數(shù)（2n+1），并且任何時刻，存活的機器必須大于n+1，否則集群掛掉；
2. zk集群選舉后，要進行數(shù)據(jù)同步，如果同步失敗，重新選舉。
一般一個zookeeper集群的機器數(shù)為3或5臺，不會更多，因為更多的話，在數(shù)據(jù)同步的時候出現(xiàn)多寫問題，造成的系統(tǒng)壓力會更大。
那么一般造成zookeeper集群掛掉的原因是什么呢？歸根到底一句話：要同步的數(shù)據(jù)太大！多大？500M
zookeeper集群中l(wèi)eader和follower同步數(shù)據(jù)的極限值是500M，這500M的數(shù)據(jù)，加載到內(nèi)存中，大約占用3個G的內(nèi)存。數(shù)據(jù)過大，在每次選舉之后，需要從server同步到follower，容易造成下面2個問題：
網(wǎng)絡(luò)傳輸超時，因為文件過大，傳輸超過最大超時時間，造成TimeoutException，從而引起重新選舉。
如果調(diào)大這個超時值，則很可能達到磁盤讀寫的上限，目前，每像精衛(wèi)、tbschedule3等，都有大量的zk寫入，這些會觸發(fā)頻繁的磁盤寫操作，一旦達到io上限值，就會導(dǎo)致超時，進而觸發(fā)重新選舉或直接導(dǎo)致系統(tǒng)崩潰。
所以，上面兩個問題，都可能導(dǎo)致zookeeper集群一直在選舉和數(shù)據(jù)同步之間陷入死循環(huán)。
上面的問題在阿里是普遍的，下面看兩個例子：
去年tbschedule 3有個bug，是ACL list只會增加不會減少，導(dǎo)致存儲的ACL數(shù)據(jù)過大，進而導(dǎo)致選舉后數(shù)據(jù)同步失敗，又重新選舉的死循環(huán)。導(dǎo)致zk服務(wù)器一直起不來，進而導(dǎo)致物流寶調(diào)度任務(wù)不執(zhí)行，系統(tǒng)掛掉的時間超過1個小時。
事實上，tbschedule 3還存在寫入過于頻繁的問題，如果寫入頻繁，就會頻繁觸發(fā)zookeeper保存快照，進而導(dǎo)致IO壓力大。
今年近期，匯金平臺所在的公共zk集群因為精衛(wèi)數(shù)據(jù)過多而掛掉。像精衛(wèi)這種應(yīng)用，在zookeeper集群上的節(jié)點非常多，存儲的數(shù)據(jù)有200M左右，很容易導(dǎo)致數(shù)據(jù)量過大。這次zookeeper停止服務(wù)的時間長達一個小時。
下面就針對上面的問題分析一下可能的解決方案：
加zookeeper server機器提高性能：注意，加zookeeper server機器提高的只是讀性能，但機器越多，多寫問題就越嚴重，系統(tǒng)也越容易掛掉。所以不可行！
冗余一個集群，作為當(dāng)前集群的備份：冗余出來的集群可以比較小，平時并不服務(wù)，只有當(dāng)主集群掛掉時，再自動切換提供服務(wù)。這種集群級別的冗余貌似可行，其實也有問題，導(dǎo)致這種方案可行性也不高，關(guān)鍵問題就在于，需要將數(shù)據(jù)從主集群的leader實時同步到備份集群，這就存在一個IO問題，如果數(shù)據(jù)量大，異常存在網(wǎng)絡(luò)超時和IO壓力大問題，如果單獨提供一個方案實現(xiàn)從主集群leader到備份集群的高速同步，那就可以直接用于解決主集群之間掛掉的問題了，更不需要備份集群了。另外，冗余物理機作為備份，絕大多數(shù)情況下，這個物理機都可能是不提供服務(wù)的，所以有資源浪費的問題。
細化zk集群：也就是說，為防止其它業(yè)務(wù)的影響。如果你的應(yīng)用強依賴zookeeper，則應(yīng)該申請機器資源，單獨配置zookeeper服務(wù)器，防止其他應(yīng)用的影響。這是目前比較可行的解決方案。
多機房分布：zookeeper存在一個要求，必須有多于n+1臺機器存活，否則整個集群掛掉（zookeeper通過這種方式，犧牲了穩(wěn)定性，但保證了數(shù)據(jù)一致性）。在目前阿里的雙機房策略下，無論兩個機房怎么分配，2n+1臺機器在兩個機房中，都會存在一個機房的機器數(shù)大于n+1的問題，如果這個機房掛掉或機房切換，都可能導(dǎo)致整個zk集群掛掉。如果想要保住zk集群穩(wěn)定性，就必須至少有3個機房，這樣一個機房掛掉時，可以保證仍然有n+1臺機器存活。這種方案在以后單元化推廣開之后還有可能，在目前雙機房情況下，無解。
最后，提供給大家一些使用zookeeper時的注意事項：
能不用zookeeper，就不用zookeeper，如果一定要用，盡量不要強依賴zookeeper；
如果你要用到分布式鎖，zookeeper是個不錯的選擇，如果不需要分布式鎖，你應(yīng)該優(yōu)先考慮不用zookeeper；
采用監(jiān)聽方式，而不是主動查詢方式，相信zookeeper的監(jiān)聽推送吧，只要你實現(xiàn)的代碼沒問題，它還是很穩(wěn)定的；
不要對zookeeper頻繁寫入，它只應(yīng)該存儲控制信息和配置信息，也就是說，它更多應(yīng)該用來做讀操作。
不要把zookeeper作為數(shù)據(jù)存儲器。
不要與那些大應(yīng)用共用一個zookeeper集群，你可能會被它拖掛的。
