http://www.tuicool.com/articles/Z3MjuuE
1. 介紹
不得不說ZK的出現是解決分布式一致性問題的一道曙光。但是事務都是發(fā)展的，即使是ZK也不是十全十美的。
今天和小伙伴聊了點ZK的問題。一些ZK使用攻略也希望在此跟大家分享下。
2. ZK的缺點
- 讀寫性能不佳：ZK的讀寫性能測試可以參考 ZooKeeper service latencies under various loads & configurations
下圖可以看到的是220萬操作，在4核20client上的效果。簡單總結是相同core，增加client整體性能會下降。
- 不適合主數據存儲：zk的quorum選舉適用在共享集群配置而不是主數據存儲。因為其吞吐量低，容忍故障所需要的冗余副本比較多
- 只容忍（N-1）/2的故障
- ZK設計的時候是基于session的，也就是基于TTL機制。保持會話需要不斷續(xù)期TTL。后起之秀如etcd等都已通過grpc改進了TTL。后續(xù)我會專門聊聊etcd
3. ZK在實際應用中的問題
ZK在實際使用中肯能會受到網絡抖動的影響，有時候這些影響對應用會造成“災難”級的傷害。例如發(fā)生網絡問題時，ZK集群需要開始選主，選主過程如果持續(xù)較長，應用都會拋異常。而且后續(xù)可能會出現follower不能及時跟上leader的情況。如果這個過程持續(xù)數十分鐘，那么將會導致應用在這個期間內無法提供服務。影響是非常大的。
以上故事來自小伙伴的真實經歷。但是到底哪些行為會造成ZK異常的選主行為尚沒搞清楚。有誰知道也可以教下我。