以下一次關(guān)于ZooKeeper為主的一次激烈的技術(shù)討論。

為什么說一套系統(tǒng)用了ZooKeeper，這個(gè)系統(tǒng)一定很low?

ZooKeeper = low?

提出此觀點(diǎn)的架構(gòu)師介紹其原因如下。

在Docker環(huán)境下，通常虛機(jī)會(huì)比較多，我們發(fā)現(xiàn)ZooKeeper不能承受太多節(jié)點(diǎn)。我們的游戲平臺(tái)是一個(gè)多租戶場景，需要頻繁進(jìn)行創(chuàng)建及刪除，在這種情況下如果超過3,000虛擬機(jī)，ZooKeeper就不行了。

當(dāng)ZooKeeper掛了后，meta數(shù)據(jù)也會(huì)跟著丟了。Meta數(shù)據(jù)和和監(jiān)控功能在ZooKeeper當(dāng)初設(shè)計(jì)時(shí)并沒有考慮的問題，因此后來我們打算自己造輪子，將這個(gè)需求實(shí)現(xiàn)。

我也并非說ZooKeeper一無是處，ZooKeeper有它適合使用的場景，比如Hadoop那種場景ZooKeeper就可以工作得很好，但并不是所有場景都適用。Tim說過一句經(jīng)典的話，Redis是把好錘子，但不能把所有存儲(chǔ)的問題都當(dāng)做釘子。ZooKeeper也是一樣，不是所有的配置的問題都適合拿它來解決。

其他一些網(wǎng)友的看法。

Z: 同意ZooKeeper是有很多運(yùn)維的問題，一個(gè)解決方法是自己實(shí)現(xiàn)一個(gè)single node all in memory的lock service，然后運(yùn)行在多個(gè)機(jī)器上，用ZooKeeper當(dāng)作一個(gè)distributed lock來選一個(gè)master，這樣ZooKeeper上的壓力就小多了，而且不會(huì)隨著集群大小增加而增加。

Y: Kafka里使用ZooKeeper的方式有好幾個(gè)地方可以借鑒。除了上面說的選一個(gè)master處理的方式外，為了避免訂閱大量節(jié)點(diǎn)，也可以單設(shè)置一個(gè)變更節(jié)點(diǎn)，然后只訂閱這個(gè)變更節(jié)點(diǎn)。

G: Kafka集群依賴于ZooKeeper，但ZooKeeper也是Kafka的瓶頸。

某知名大型互聯(lián)網(wǎng)公司方案

某知名大型互聯(lián)網(wǎng)公司的架構(gòu)師也基本認(rèn)可上述觀點(diǎn)，其新開發(fā)的服務(wù)框架中不再采用ZooKeeper作為注冊(cè)中心，主要說明如下

1. 隨著部署規(guī)模增大，客戶端增多，ZooKeeper服務(wù)器中節(jié)點(diǎn)數(shù)量大增，核心ZooKeeper集群5臺(tái)，每臺(tái)服務(wù)器1,5000左右的長鏈接，近43萬個(gè)節(jié)點(diǎn)，平均30余萬watch。每個(gè)上線日，ZooKeeper服務(wù)器的流量都能上200mb/s，通過mntr的觀察zk_outstanding_requests 經(jīng)常達(dá)到300M以上;

2. 有業(yè)務(wù)方報(bào)告，應(yīng)用啟動(dòng)后連上ZooKeeper但一直讀失敗(讀數(shù)據(jù)返回為null)，也就是取服務(wù)列表失敗，一段時(shí)間如半小時(shí)后自動(dòng)恢復(fù)，查看zk server端日志，只看到一堆session過期的警告，沒有其他異常;

3. 由于歷史原因，ZooKeeper服務(wù)器與其他應(yīng)用共用，40萬+節(jié)點(diǎn)中60%是我們的，其他應(yīng)用也是重度依賴zookeeper，互相之間有影響;

4. ZooKeeper推送的頻率、內(nèi)容，我們自己不能控制，比如一個(gè)600 provider，12000 consumer的服務(wù)，如果新增一個(gè)provider，其實(shí)并不是每個(gè)consumer都需要通知的，但目前的機(jī)制下consumer監(jiān)聽一個(gè)目錄，每個(gè)consumer都會(huì)得到一次provider列表推送;還有我們想在推送前根據(jù)一定的規(guī)則對(duì)provider列表做動(dòng)態(tài)過濾排序，這個(gè)需求在zookeeper服務(wù)端也沒法實(shí)現(xiàn)。

5. ZooKeeper客戶端使用的是 172.17.xx.yy,172.17.xx.yz:2181 這樣的ip串方式連接，后期想添加服務(wù)器分散主集群讀寫壓力，也不好實(shí)現(xiàn)，因?yàn)樾枰牡刂反?，需要update配置的客戶端太多了;

6. 跨機(jī)房容災(zāi)方面，一旦出現(xiàn)機(jī)房間通信問題，另一個(gè)機(jī)房的部署的Observer節(jié)點(diǎn)，就不可讀寫了;

7. provider約6萬實(shí)例，consumer22萬實(shí)例;

基于以上的原因，新的方案實(shí)現(xiàn)也很簡單，自己實(shí)現(xiàn)了一個(gè)服務(wù)用來做注冊(cè)中心的，實(shí)現(xiàn)的是服務(wù)注冊(cè)/訂閱方面的功能。它負(fù)責(zé)接收長鏈接并推送，數(shù)據(jù)存儲(chǔ)在MySQL。

Q：使用ZooKeeper主要是它實(shí)現(xiàn)了強(qiáng)一致性，你這個(gè)注冊(cè)中心是單點(diǎn)的吧?master election用ZooKeeper?注冊(cè)中心會(huì)成為新的瓶頸和故障點(diǎn)?

A：性能方面完全夠用，因?yàn)檫@個(gè)服務(wù)也是集群部署的，客戶端首先訪問一個(gè)http接口拿到所有服務(wù)器的地址，并優(yōu)先訪問本機(jī)房的注冊(cè)中心。注冊(cè)中心基本讀多寫少，內(nèi)存里面也緩存provider列表，不會(huì)有太大壓力到MySQL;存儲(chǔ)上通過MySQL實(shí)現(xiàn)一致性保證。

Q：跨機(jī)房容災(zāi)方面有什么優(yōu)化嗎?如果網(wǎng)絡(luò)沒有足夠的redundency，一旦出現(xiàn)network partiton，那么有一個(gè)機(jī)房就沒辦法到quorum了?

A：通過多機(jī)房部署，每個(gè)機(jī)房保證至少2個(gè)節(jié)點(diǎn)，本機(jī)房掛了還可以訪問其它機(jī)房，并且在客戶端本地還有緩存文件。

Q：當(dāng)配置變化，client以http輪詢方式去感知嗎?

A：Session過期那個(gè)，開始我們?cè)O(shè)的是很短，后來發(fā)現(xiàn)不對(duì)，網(wǎng)絡(luò)一閃斷，大量掉節(jié)點(diǎn)?，F(xiàn)在我們自己實(shí)現(xiàn)的服務(wù)，半分鐘一心跳，幾個(gè)心跳沒收到我才認(rèn)為下線了。如果provider列表發(fā)生變化，我這邊服務(wù)端會(huì)主動(dòng)推送的，因?yàn)橛玫氖荰CP長連接。

Q: Client有沒有主動(dòng)發(fā)現(xiàn)本地cache與服務(wù)端數(shù)據(jù)不一致的機(jī)制?例如當(dāng)provider列表發(fā)生變化且服務(wù)端通過TCP長連給client推送失敗的場景。

A：有，我們心跳帶本地版本號(hào)的，如果與服務(wù)端不一致的話，會(huì)觸發(fā)服務(wù)端再次推送;

另一知名大型互聯(lián)網(wǎng)公司ZooKeeper運(yùn)行現(xiàn)狀

而另外一知名大公司架構(gòu)師認(rèn)為如果consumer數(shù)量沒有那么多，用ZooKeeper也能較好滿足要求。其業(yè)務(wù)場景的ZooKeepr使用及運(yùn)行情況如下。

線上的單個(gè)ZooKeeper節(jié)點(diǎn)平均連接數(shù)是6K，watcher是30萬，netIO不高，ZooKeeper的機(jī)器配置比較差，用的是4G 4CPU 的虛擬機(jī)，5個(gè)節(jié)點(diǎn)，最多的consumer不超過200，平均consumer數(shù)量就5，6個(gè)左右。

目前線上provider數(shù)3萬左右實(shí)例數(shù)，consumer數(shù)10萬左右，目前運(yùn)行的沒什么問題。3萬個(gè)，如果每個(gè)服務(wù)10個(gè)實(shí)例，也就3,000個(gè)服務(wù)，全公司的，也沒多少。看起來是多了點(diǎn)。 跟公司發(fā)展歷史及使用場景關(guān)系很大。

之前關(guān)于ZooKeeper踩坑最多的是在客戶端上，最開始用的是netflix的curator(后來貢獻(xiàn)給apache，但是我們用的是老的，沒升級(jí))，遇到網(wǎng)絡(luò)閃斷重連不上，然后死循環(huán)一樣，升級(jí)到apache curator就好了。

后來遇到一個(gè)問題是，如果注冊(cè)watcher太多，發(fā)生重連的時(shí)候，zk client會(huì)自動(dòng)注冊(cè)之前的所有watcher，這樣會(huì)導(dǎo)致一個(gè)包的大小超過1M，然后也就重連不上又不斷地重連，后來hack了zk client解決了這個(gè)問題，這個(gè)bug到目前為止zk官方仍然沒有修復(fù)。

不過這些坑基本上遇到一個(gè)可以解決一個(gè)，但是目前有一個(gè)問題目前也沒找到好的解決方案，那就是業(yè)務(wù)方系統(tǒng)load變高，或者發(fā)生長時(shí)間gc，導(dǎo)致zk重連甚至session過期。

另外關(guān)于zk連接，我們?cè)谧畹紫伦隽诉B接共享，因?yàn)楹枚喾?wù)都依賴zk，這個(gè)也降低了不少連接數(shù)。