Zookeeper是一個分布式協(xié)調(diào)框架，有不錯的性能产上，也經(jīng)過許多公司的驗證棵磷，所以在很多場景都有使用。大家一般用Zookeeper來實現(xiàn)服務(wù)發(fā)現(xiàn)(類似DNS)晋涣，配置管理仪媒，分布式鎖，leader選舉等谢鹊。在這些場景中算吩，Zookeeper成為了一個被依賴的核心組件，Zookeeper的穩(wěn)定性是需要特別關(guān)注的佃扼。
去哪兒網(wǎng)也在很多場景依賴Zookeeper偎巢，所以我們也一直在摸索怎么更好的運維穩(wěn)定的Zookeeper集群。在過去的幾年我們也踩過一些坑兼耀，也因為Zookeeper導(dǎo)致了故障⊙怪纾現(xiàn)在將我們運維Zookeeper集群的一些經(jīng)驗分享，也歡迎大家提供更好的建議瘤运。
那么在打算運維一套Zookeeper集群之前巢音，我們先了解一些Zookeeper的基本原理。
集群里分三種角色: Leader, Follower和Observer尽超。Leader和Follower參與投票，Observer只會『聽』投票的結(jié)果梧躺，不參與投票似谁。
投票集群里的節(jié)點數(shù)要求是奇數(shù)
一個集群容忍掛掉的節(jié)點數(shù)的等式為 N = 2F + 1，N為投票集群節(jié)點數(shù)掠哥，F(xiàn)為能同時容忍失敗節(jié)點數(shù)巩踏。比如一個三節(jié)點集群，可以掛掉一個節(jié)點续搀，5節(jié)點集群可以掛掉兩個...
一個寫操作需要半數(shù)以上的節(jié)點ack塞琼，所以集群節(jié)點數(shù)越多，整個集群可以抗掛點的節(jié)點數(shù)越多(越可靠)禁舷，但是吞吐量越差彪杉。
Zookeeper里所有節(jié)點以及節(jié)點的數(shù)據(jù)都會放在內(nèi)存里毅往，形成一棵樹的數(shù)據(jù)結(jié)構(gòu)。并且定時的dump snapshot到磁盤派近。
Zookeeper的Client與Zookeeper之間維持的是長連接攀唯，并且保持心跳，Client會與Zookeeper之間協(xié)商出一個Session超時時間出來(其實就是Zookeeper Server里配置了最小值渴丸，最大值侯嘀，如果client的值在這兩個值之間則采用client的，小于最小值就是最小值谱轨，大于最大值就用最大值)戒幔，如果在Session超時時間內(nèi)沒有收到心跳，則該Session過期土童。
Client可以watch Zookeeper那個樹形數(shù)據(jù)結(jié)構(gòu)里的某個節(jié)點或數(shù)據(jù)诗茎，當有變化的時候會得到通知。
有了這些了解后娜扇，那么我們心里其實有底了错沃。
1. 最小生產(chǎn)集群
要確保Zookeeper能夠穩(wěn)定運行，那么就需要確保投票能夠正常進行雀瓢，最好不要掛一個節(jié)點整個就不work了枢析，所以我們一般要求最少5個節(jié)點部署。
2. 網(wǎng)絡(luò)
除了節(jié)點外刃麸，我們還要看不能一臺物理機器醒叁，一個機柜或一個交換機掛掉然后影響了整個集群，所以節(jié)點的網(wǎng)絡(luò)結(jié)構(gòu)也要考慮泊业。這個可能就比很多應(yīng)用服務(wù)器的要求更加嚴格把沼。
3. 分Group，保護核心Group
要確保Zookeeper整個集群可靠運行吁伺，就是要確保投票集群可靠饮睬。那在我們這里，將一個Zookeeper集群劃分為多個小的Group篮奄，我們稱Leader+Follower為核心Group捆愁，核心Group我們一般是不向外提供服務(wù)的，然后我們會根據(jù)不同的業(yè)務(wù)再加一些Observer窟却，比如一個Zookeeper集群為服務(wù)發(fā)現(xiàn)昼丑，消息，定時任務(wù)三個不同的組件提供服務(wù)夸赫，那么我們?yōu)榻⑷齻€Observer Group菩帝，分別給這三個組件使用，而Client只會連接分配給它的Observer Group，不去連接核心Group呼奢。這樣核心Group就不會給Client提供長連接服務(wù)宜雀，也不負責長連接的心跳，這大大的減輕了核心Group的壓力控妻，因為在實際環(huán)境中州袒，一個Zookeeper集群要為上萬臺機器提供服務(wù)，維持長連接和心跳還是要消耗一定的資源的弓候。因為Observer是不參與投票的所以加Observer并不會降低整體的吞吐量郎哭，而且Observer掛掉不會影響整個集群的健康。
但是這里要注意的是菇存，分Observer Group只能解決部分問題夸研，因為畢竟所有的寫入還是要交給核心Group來處理的，所以對于寫入量特別大的應(yīng)用來說依鸥，還是需要進行集群上的隔離亥至，比如Storm和Kafka就對Zookeeper壓力比較大，你就不能將其與服務(wù)發(fā)現(xiàn)的集群放在一起贱迟。
4. 內(nèi)存
因為Zookeeper將所有數(shù)據(jù)都放在內(nèi)存里姐扮，所以對JVM以及機器的內(nèi)存也要預(yù)先計劃，如果出現(xiàn)Swap那將嚴重的影響Zookeeper集群的性能衣吠，所以我一般不怎么推薦將Zookeeper用作通用的配置管理服務(wù)茶敏。因為一般配置數(shù)據(jù)還是挺大的，這些全部放在內(nèi)存里不太可控缚俏。
5. 日志清理
因為Zookeeper要頻繁的寫txlog(Zookeeper寫的一種順序日志)以及定期dump內(nèi)存snapshot到磁盤惊搏，這樣磁盤占用就越來越大，所以Zookeeper提供了清理這些文件的機制忧换，但是這種機制并不太合理恬惯，它只能設(shè)置間隔多久清理，而不能設(shè)置具體的時間段亚茬。那么就有可能碰到高峰期間清理酪耳，所以建議將其關(guān)閉:autopurge.purgeInterval=0。然后使用crontab等機制刹缝，在業(yè)務(wù)低谷的時候清理葡兑。
6. 日志，jvm配置
從官網(wǎng)直接下載的包如果直接啟動運行是很糟糕的赞草，這個包默認的配置日志是不會輪轉(zhuǎn)的，而且是直接輸出到終端吆鹤。我們最開始并不了解這點厨疙，然后運行一段時間后發(fā)現(xiàn)生成一個龐大的zookeeper.out的日志文件。除此之外疑务，這個默認配置還沒有設(shè)置任何jvm相關(guān)的參數(shù)(所以堆大小是個默認值)沾凄，這也是不可取的梗醇。那么有的同學(xué)說那我去修改Zookeeper的啟動腳本吧。最好不要這樣做撒蟀，Zookeeper會加載conf文件夾下一個名為zookeeper-env.sh的腳本叙谨，所以你可以將一些定制化的配置寫在這里，而不是直接去修改Zookeeper自帶的腳本保屯。
" # !/usr/bin/env bash "
JAVA_HOME= #java home
ZOO_LOG_DIR= #日志文件放置的路徑
ZOO_LOG4J_PROP="INFO,ROLLINGFILE" #設(shè)置日志輪轉(zhuǎn)
JVMFLAGS="jvm的一些設(shè)置手负，比如堆大小，開gc log等"
7. 地址
在實際環(huán)境中姑尺，我們可能因為各種原因比如機器過保竟终，硬件故障等需要遷移Zookeeper集群，所以Zookeeper的地址是一個很頭痛的事情切蟋。這個地址有兩方面统捶，第一個是提供給Client的地址，建議這個地址通過配置的方式下發(fā)柄粹，不要讓使用方直接使用喘鸟，這一點我們前期做的不好。另外一個是集群配置里驻右，集群之間需要通訊什黑，也需要地址。我們的處理方式是設(shè)置hosts:
192.168.1.20 zk1
192.168.1.21 zk2
192.168.1.22 zk3
在配置里:
server.1=zk1:2081:3801
server.2=zk2:2801:3801
server.3=zk3:2801:3801
這樣在需要遷移的時候旺入，我們停老的節(jié)點兑凿，起新的節(jié)點只需要修改hosts映射就可以了。比如現(xiàn)在server.3需要遷移茵瘾，那我們在hosts里將zk3映射到新的ip地址礼华。但是對于java有一個問題是，java默認會永久緩存DNS cache拗秘，即使你將zk3映射到別的ip圣絮，如果并不重啟server.1, server.2，它是不會解析到新的ip的雕旨，這個需要修改$JAVA_HOME/jre/lib/security/java.security文件里的networkaddress.cache.ttl=60扮匠，將其修改為一個比較小的數(shù)。
對于這個遷移的問題凡涩，我們還遇到一個比較尷尬的情況棒搜，在最后的坑里會有提及。
8. 日志位置
Zookeeper主要產(chǎn)生三種IO: txlog(每個寫操作活箕，包括新Session都會記錄一條log)力麸，Snapshot以及運行的應(yīng)用日志。一般建議將這三個IO分散到三個不同的盤上。不過我們倒是一直沒有這么實驗過克蚂，我們的Zookeeper也是運行在虛擬機(一般認為虛擬機IO較差)上闺鲸。
9. 監(jiān)控
我們對Zookeeper做了這樣一些監(jiān)控:
a. 是否可寫。 就是一個定時任務(wù)定時的去創(chuàng)建節(jié)點埃叭，刪節(jié)點等操作摸恍。這里要注意的是Zookeeper是一個集群，我們監(jiān)控的時候我還是希望對單個節(jié)點做監(jiān)控赤屋，所以這些操作的時候不要連接整個集群立镶，而是直接去連接單個節(jié)點。
b. 監(jiān)控watcher數(shù)和連接數(shù) 特別是這兩個數(shù)據(jù)有較大波動的時候益缎，可以發(fā)現(xiàn)使用方是否有誤用的情況
c. 網(wǎng)絡(luò)流量以及client ip 這個會記錄到監(jiān)控系統(tǒng)里谜慌，這樣很快能發(fā)現(xiàn)『害群之馬』
10. 一些使用建議
a. 不要強依賴Zookeeper，也就是Zookeeper出現(xiàn)問題業(yè)務(wù)已然可以正常運行莺奔。Zookeeper是一個分布式的協(xié)調(diào)框架欣范，主要做的事情就是分布式環(huán)境的一致性。這是一個非沉钣矗苛刻的事情恼琼，所以它的穩(wěn)定性受很多方面的影響。比如我們常常使用Zookeeper做服務(wù)發(fā)現(xiàn)屏富，那么服務(wù)發(fā)現(xiàn)其實是不需要嚴格的一致性的晴竞，我們可以緩存server list，當Zookeeper出現(xiàn)問題的時候已然可以正常工作狠半，在這方面etcd要做的更好一些噩死，Zookeeper如果出現(xiàn)分區(qū)，少數(shù)派是不能提供任何服務(wù)的神年，讀都不可以已维，而etcd的少數(shù)派仍然可以提供讀服務(wù)，這在服務(wù)發(fā)現(xiàn)的時候還是不錯的已日。
b. 不要將很多東西塞到Zookeeper里垛耳，這個上面已經(jīng)提到過。
c. 不要使用Zookeeper做細粒度鎖飘千，比如很多業(yè)務(wù)在訂單這個粒度上使用Zookeeper做分布式鎖堂鲜，這會頻繁的和Zookeeper交互，對Zookeeper壓力較大护奈，而且一旦出現(xiàn)問題影響面廣缔莲。但是可以使用粗粒度的鎖(其實leader選舉也是一種鎖)。
d. 不建議做通用配置的第二個理由是霉旗，通用配置要提供給特別多特別多系統(tǒng)使用酌予，而且一些公共配置甚至所有系統(tǒng)都會使用磺箕，一旦這樣的配置發(fā)生變更，Zookeeper會廣播給所有的watcher抛虫，然后所有Client都來拉取，瞬間造成非常大的網(wǎng)絡(luò)流量简僧，引起所謂的『驚群』脸甘。而自己實現(xiàn)通用配置系統(tǒng)的時候咧欣，一般會對這種配置采取排隊或分批通知的方式。
11. 一些坑
a. zookeeper client 3.4.5 ping時間間隔算法有問題，在遇到網(wǎng)絡(luò)抖動等原因?qū)е乱淮蝡ing失敗后會斷開連接绩脆。3.4.6解決了這個問題 Bug1751。
b. zookeeper client如果因為網(wǎng)絡(luò)抖動斷開了連接百姓，如果后來又重連上了楣颠，zookeeper client會自動的將之前訂閱的watcher等又全部訂閱一遍，而Zookeeper默認對單個數(shù)據(jù)包的大小有個1M的限制夏志，這往往就會超限乃坤，最后導(dǎo)致一直不斷地的重試。這個問題在較新的版本得到了修復(fù)沟蔑。Bug706
c. 拋出UnresolvedAddressException異常導(dǎo)致Zookeeper選舉線程退出湿诊，整個集群無法再選舉，處于崩潰的邊緣瘦材。這個問題是厅须，某次OPS遷移機器，將老的機器回收了食棕，所以老的機器的IP和機器名不復(fù)存在朗和，最后拋出UnresolvedAddressException這個異常，而Zookeeper的選舉線程(QuorumCnxManager類里的Listener)只捕獲了IOException簿晓，導(dǎo)致該線程退出眶拉，該線程一旦退出只要現(xiàn)在的leader出現(xiàn)問題，需要重新選舉抢蚀，則不會選出新的leader來镀层，整個集群就會崩潰。Bug2319(PS皿曲，這個bug是我report的)
