Zookeeper是一个高可用的数据管理与系统协调框架，什么意思呢？简单来说就是Zookeeper可以在分布式环境中保证数据的强一致性。主要的应用场景如下：

• 数据发布于订阅：使用Zookeeper作为配置中心，发布者者将数据发布到Zookeeper节点上，订阅者实时获取数据，从而实现配置信息的集中式管理和动态更新。
• 负载均衡：在分布式环境中，一般服务提供方都会将服务部署多份，达到对等服务。服务消费方会从这些对等服务中选择一个来使用。比较典型的是kafka通过Zookeeper来做生产者和消费者的负载均衡。
• 命名服务：通过命名服务，客户端可以根据指定名字来获取资源，比较常见的是分布式服务框架中的服务地址列表。比较典型的应用是阿里的分布式服务框架Dubbo就是使用Zookeeper的命名服务。
• 分布式通知与协调：使用watcher注册于异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。
• 集群管理与Master选举：Zookeeper通过watcher和EPHEMERAL类型节点实现集群管理；通过EPHEMERAL_SEQUENTIAL节点类型特性实现动态Master选举。
• 分布式锁：锁服务可以分为保持独占和控制时序两类。
• 分布式队列：队列包括FIFO队列和增强FIFO队列。

Znode容量

之前使用Zookeeper同步python文件一直没有注意这个问题。直到前几天一个新需求提出后我才注意到之前使用Zookeeper时没有注意到这一点。新需求是希望可以同步数据文件，每个文件都在十几M的样子。
使用中直接报错，查阅资料后发现Znode的容量是有限制的。官方文档的解释如下：

Data Access
The data stored at each znode in a namespace is read and written atomically. Reads get all the data bytes associated with a znode and a write replaces all the data. Each node has an Access Control List (ACL) that restricts who can do what.

ZooKeeper was not designed to be a general database or large object store. Instead, it manages coordination data. This data can come in the form of configuration, status information, rendezvous, etc. A common property of the various forms of coordination data is that they are relatively small: measured in kilobytes. The ZooKeeper client and the server implementations have sanity checks to ensure that znodes have less than 1M of data, but the data should be much less than that on average. Operating on relatively large data sizes will cause some operations to take much more time than others and will affect the latencies of some operations because of the extra time needed to move more data over the network and onto storage media. If large data storage is needed, the usually pattern of dealing with such data is to store it on a bulk storage system, such as NFS or HDFS, and store pointers to the storage locations in ZooKeeper.

简单来说就是Zookeeper的Znode的大小限制为1M，一般用来存储配置信息的小文件，而不能用来存储较大的数据文件。较大的数据文件建议使用redis来保存，然后再Znode中保存这些数据的索引即可。