Zookeeper的優缺點

原文http://blog.csdn.net/wwwsq/article/details/7644445

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

• 由於要跨機房容災，很多系統實際上是需要跨機房部署的。出於性價比的考慮我們通常會讓多個機房同時工作，而不會搭建N倍的冗余。也就是說單個機房肯定撐不住全流量（你能設想谷歌在全球只剩下一個機房在干活嗎）。由於zookeeper集群只能有一個master，因此一旦機房之間連接出現故障，zookeeper master就只能照顧一個機房，其他機房運行的業務模塊由於沒有master都只能停掉。於是所有流量集中到有master的那個機房，於是系統crash。
• 即使是在同一個機房里面，由於網段的不同，在調整機房交換機的時候偶爾也會發生網段隔離的情況。實際上機房每個月基本上都會發生短暫的網絡隔離之類的子網段調整。在那個時刻zookeeper將處於不可用狀態。如果整個業務系統基於zookeeper（比如要求每個業務請求都先去zookeeper獲取業務系統的master地址），則系統的可用性將非常脆弱。
• 由於zookeeper對於網絡隔離的極度敏感，導致zookeeper對於網絡的任何風吹草動都會做出激烈反應。這使得zookeeper的‘不可用’時間比較多，我們不能讓zookeeper的‘不可用’，變成系統的不可用。

zookeeper的選舉過程速度很慢

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

zookeeper的性能是有限的

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

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

• zookeeper的權限控制非常薄弱
• 在大型的復雜系統里面，使用zookeeper必須自己再額外的開發一套權限控制系統，通過那套權限控制系統再訪問zookeeper
• 額外的權限控制系統不但增加了系統復雜性和維護成本，而且降低了系統的總體性能

即使有了zookeeper也很難避免業務系統的數據不一致

• 前面已經討論過了，由於zookeeper的性能限制，我們無法讓每次系統內部調用都走zookeeper，因此總有某些時刻，業務系統會存在兩個master（業務系統client那邊緩存的業務系統master信息是定時從zookeeper更新的，因此會有更新不同步的問題）。
• 如果要在業務系統client的master信息不一直的情況下，仍要保持系統的數據一致性，唯一的方法是“先kill掉老master，再在zookeeper上更新master信息”。但是在是否要kill current master這個問題上，程序是無法完全自動決定的（因為網絡隔離的時候zookeeper已經不可用了，自動腳本沒有全局信息，不管怎么做都可能是錯的，什么都不做也可能是錯的。當網絡故障的時候，只有運維人員才有全局信息，程序是無法接電話得知其他機房的情況的）。因此系統無法自動的保障數據一致性，必須要人工介入。而人工介入的典型時間是半個小時以上，我們不能讓系統這么長時間不可用。因此我們必須在某個方向上進行妥協，最常見的妥協方式是放棄‘強一致性’，而接受‘最終一致性’。
• 如果我們需要人工介入才能保證‘可靠的強一致性’，那么zookeeper的價值就大打折扣。

我們能做什么

• 我們或者選擇人工介入的強一致性，或者選擇程序自動化進行的弱一致性。需要進行取舍。
• 最終一致性甚至未必是程序來做的，有時候人工修正數據反而在靈活、可靠、低成本上有優勢。這需要權衡。
• 不要迷信zookeeper，有時候不妨考慮一下主備數據庫。數據庫自帶權限控制，用起來比zookeeper方便多了。
• zookeeper比較有價值的東西也許是內容變化的時候，可以阻塞回調的方式通知所有在線的client實時更新信息，但這個功能用處不大。因為php這樣的模塊你很難說它是在線還是離線，每次都是新發起的。一旦這個功能無法支持php，就無法覆蓋整個系統，那么就無法保證強一致性了。

 

 

      PS：以上只是個人對zookeeper的一些認識，歡迎討論和指正。

 

------------------------------------------------------------------------

替代方案博主：http://blog.csdn.net/wwwsq

• wwwsq

  2013-10-31 09:405樓
  回復
• 我看了下阿里雲飛天的分布式文件系統，他們的做法是“基於 Paxos協議的 多Master設計”，而不是套用zookeeper。他們的選擇是對的。Paxos只能保證自身的內在一致性，無法把這種一致性可靠的映射到外部去。