http://www.tuicool.com/articles/Z3MjuuE
1. 介绍
不得不说ZK的出现是解决分布式一致性问题的一道曙光。但是事务都是发展的，即使是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机制。保持会话需要不断续期TTL。后起之秀如etcd等都已通过grpc改进了TTL。后续我会专门聊聊etcd
3. ZK在实际应用中的问题
ZK在实际使用中肯能会受到网络抖动的影响，有时候这些影响对应用会造成“灾难”级的伤害。例如发生网络问题时，ZK集群需要开始选主，选主过程如果持续较长，应用都会抛异常。而且后续可能会出现follower不能及时跟上leader的情况。如果这个过程持续数十分钟，那么将会导致应用在这个期间内无法提供服务。影响是非常大的。
以上故事来自小伙伴的真实经历。但是到底哪些行为会造成ZK异常的选主行为尚没搞清楚。有谁知道也可以教下我。