1. 介绍

不得不说ZK的出现是解决分布式一致性问题的一道曙光。但是事务都是发展的,即使是ZK也不是十全十美的。

今天和小伙伴聊了点ZK的问题。一些ZK使用攻略也希望在此跟大家分享下。

2. ZK的缺点

  1. 读写性能不佳(这个还需要再验证,我也只是听说):ZK的读写性能测试可以参考ZooKeeper service latencies under various loads & configurations
  2. 不适合主数据存储:zk的quorum选举适用在共享集群配置而不是主数据存储。因为其吞吐量低,容忍故障所需要的冗余副本比较多
  3. 只容忍(N-1)/2的故障
  4. ZK设计的时候是基于session的,也就是基于TTL机制。保持会话需要不断续期TTL。后起之秀如etcd等都已通过grpc改进了TTL。后续我会专门聊聊etcd

3. ZK在实际应用中的问题

ZK在实际使用中肯能会受到网络抖动的影响,有时候这些影响对应用会造成“灾难”级的伤害。例如发生网络问题时,ZK集群需要开始选主,选主过程如果持续较长,应用都会抛异常。而且后续可能会出现follower不能及时跟上leader的情况。如果这个过程持续数十分钟,那么将会导致应用在这个期间内无法提供服务。影响是非常大的。

以上故事来自小伙伴的真实经历。但是到底哪些行为会造成ZK异常的选主行为尚没搞清楚。有谁知道也可以教下我。

此外建议大家把ZK部署在SSD上,能避免不少问题。ZK在SATA上还是会有些奇怪的问题。