Zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理.
Zookeeper设计目的
- 最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
- 可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。
- 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
- 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
- 原子性：更新只能成功或者失败，没有中间状态。
- 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面
基于ZooKeeper的持久和非持久的特点，我们能够近乎实时地感觉到后端服务的状态(上线,下线,宕机)通过其集群间的zab协议，使得服务配置信息能够保持一致。而zk本身的容错特性和选举机制能够保障我们方便的进行扩容。通过zk来实现服务的动态注册，机器上线和下线的动态感知，扩容方便容错性好。且无中心化结构能够解决之前使用负载均衡设备所带来的单机故障问题，只有当配置信息更新时才回去zk上获取最新的服务地址列表，其他的时候使用本地缓存。
分布式服务框架就是同一个服务，把数据库的不同部分分开建立到不同的服务器上。以缓解数据库大量数据访问的压力。
很多大公司的业务量比较大，每天的访问量都达到几百万上千万，甚至上亿的访问量，在访问量不是很大的情况下，是可以通过提高单台服务器的配置来满足需求的。但是当单台服务器已经满足不了需求的时候就需要做分布式处理了。毕竟一台服务器的处理能力是有限的。
如果分散到几台甚至几十台几百天电脑上，其优势就显现出来了。