Apache ZooKeeper 是 Google Chubby 项目的开源实现，它曾经作为 Hadoop 的子项目，在大数据领域得到广泛应用。Zookeeper 从文件系统 API 得到启发，提供一组简单的 API，使得开发人员可以实现通用的协作任务，包括选举主节点、管理组内成员关系、管理元数据等。

1 适用的场景

分布式系统中协作多个任务。比如：

• 典型的主-从工作模式，从节点处于空闲状态时会通知主节点可以接受工作，又或者在没有主节点时，许多节点需要选举出一个主节点。

• 分布式锁

• 元数据存储，因为ZK的顺序访问、全部数据放在内存等设计，ZK也被很多系统用作元数据存储。著名的依赖 ZK 的开源项目Apache HBase, Apache Kafka, Apache HDFS, ClickHouse, Apache Flink等。

2 不适用的场景

• 不适于用于海量数据存储，虽然可以看作是强一致的 kv 存储。设计系统时，协同元数据应该与应用数据区分开来。

• 不适于做过细粒度的锁，分布式锁如果过细会对 server 端造成很大压力，业务也会极不稳定。

3 注意事项

• 当前 ZK的SLA为99.95%，设计系统时应该考虑ZK短暂不可用的情况，否则ZK unavailable的影响会放大很多倍。ZK不可用的情况有很多：多数节点硬件/软件故障，节点间网络隔离/延迟增高，client-server间网络隔离/延迟增高等等

• 一旦数据量超过1GB，就应该思考ZK作为元数据存储使用是否正确了

• 一旦单系统内锁的粒度细到多于1000个锁或多于100个client抢一个锁，就应该思考ZK作为粗粒度锁使用是否正确了

• zk参数 jute.maxbuffer 限制了请求包的size，当前默认1MB，如果一个znode下children过多，.getChildren() 返回时可能会超过这个限制，从而报错。如果有需求，应首先思考zk的使用方式是否正确，比如单个znode太多children或单个znode数据量太大等等。实在有需求，可以适当increase(client和server都需要设置)。

• 为保证集群中组件的稳定性，不建议用户使用 zk 自主编程