zookeeper的缺點

1. zookeeper不是為高可用性設計的

   由于要跨機房容災，很多系統實際上是需要跨機房部署的。出于成本效益的考慮我們通常會讓多個機房同時工作，而不會搭建N倍的備援。也就是說單個機房肯定撐不住全流量（你能設想谷歌在全球隻剩下一個機房在幹活嗎）。由于zookeeper叢集隻能有一個master，是以一旦機房之間連接配接出現故障，zookeeper master就隻能照顧一個機房，其他機房運作的業務子產品由于沒有master都隻能停掉。于是所有流量集中到有master的那個機房，于是系統crash。

   即使是在同一個機房裡面，由于網段的不同，在調整機房交換機的時候偶爾也會發生網段隔離的情況。實際上機房每個月基本上都會發生短暫的網絡隔離之類的子網段調整。在那個時刻zookeeper将處于不可用狀态。如果整個業務系統基于zookeeper（比如要求每個業務請求都先去zookeeper擷取業務系統的master位址），則系統的可用性将非常脆弱。

   由于zookeeper對于網絡隔離的極度敏感，導緻zookeeper對于網絡的任何風吹草動都會做出激烈反應。這使得zookeeper的‘不可用’時間比較多，我們不能讓zookeeper的‘不可用’，變成系統的不可用。

2. zookeeper的選舉過程速度很慢

   這是一個很難從理論分析上看到的弱點，但是你一旦遇到就會痛不欲生。前面我們已經說過，網絡實際上常常是會出現隔離等不完整狀态的，而zookeeper對那種情況非常敏感。一旦出現網絡隔離，zookeeper就要發起選舉流程。zookeeper的選舉流程通常耗時30到120秒，期間zookeeper由于沒有master，都是不可用的。對于網絡裡面偶爾出現的，比如半秒一秒的網絡隔離，zookeeper會由于選舉過程，而把不可用時間放大幾十倍。

3. zookeeper的性能是有限的

   典型的zookeeper的tps大概是一萬多，無法覆寫系統内部每天動辄幾十億次的調用。是以每次請求都去zookeeper擷取業務系統master資訊是不可能的。是以zookeeper的client必須自己緩存業務系統的master位址。是以zookeeper提供的‘強一緻性’實際上是不可用的。如果我們需要強一緻性，還需要其他機制來進行保障：比如用自動化腳本把業務系統的old master給kill掉，但是那會有很多陷阱（這裡先不展開這個議題，讀者可以自己想想會有哪些陷阱）。

4. zookeeper無法進行有效的權限控制

   在大型的複雜系統裡面，使用zookeeper必須自己再額外的開發一套權限控制系統，通過那套權限控制系統再通路zookeeper額外的權限控制系統不但增加了系統複雜性和維護成本，而且降低了系統的總體性能即使有了zookeeper也很難避免業務系統的資料不一緻前面已經讨論過了，由于zookeeper的性能限制，我們無法讓每次系統内部調用都走zookeeper，是以總有某些時刻，業務系統會存在兩個master（業務系統client那邊緩存的業務系統master資訊是定時從zookeeper更新的，是以會有更新不同步的問題）。