要先知道什么是zookeeper，就需要从它为什么会出现的开始说起，以分布式系统架构为例。
早期我们是单一的应用架构，随着互联网的快速发展和体量的不断增长，后端的架构通过垂直伸缩的方式很难达到我们期望的性能要求，同时投入产出比也非常大，同时普通PC 的性能也越来越高，所以通过水平伸缩的方式来提升性能成为了主流。
在分布式架构下，当服务越来越多，规模越来越大时，对应的机器数量也越来越大，单靠人工来管理和维护服务及地址的配置地址信息会越来越困难，单点故障的问题也开始凸显出来，一旦服务路由或者负载均衡服务器(Nginx)宕机，依赖他的所有服务均将失效。
此时，需要一个能够动态注册和获取服务信息的地方。来统一管理服务名称和其对应的服务器列表信息，称之为服务配置中心，服务提供者在启动时，将其提供的服务名称、服务器地址注册到服务配置中心，服务消费者通过服务配置中心来获得需要调用的服务的机器列表。通过相应的负载均衡算法，选取其中一台服务器进行调用。当服务器宕机或者下线时，相应的机器需要能够动态地从服务配置中心里面移除，并通知相应的服务消费者，否则服务消费者就有可能因为调用到已经失效服务而发生错误，在这个过程中，服务消费者只有在第一次调用服务时需要查询服务配置中心，然后将查询到的信息缓存到本地，后面的调用直接使用本地缓存的服务地址列表信息，而不需要重新发起请求道服务配置中心去获取相应的服务地址列表，直到服务的地址列表有变更（机器上线或者下线）。这种无中心化的结构解决了之前负载均衡设备所导致的单点故障问题，并且大大减轻了服务配置中心的压力.
所以我们需要一个中间件框架来解决这个问题，同时总结以上我们对这个框架需要一些要求:
1.去中心化，无中心化(理解看上文) 2.高可用 3.管理服务和配置服务 4.能够具备负载均衡算法。
于是zookeeper就这样出现了。
zookeeper 是一个开源的分布式协调服务，由雅虎公司创建，是google chubby 的开源实现。zookeeper 的设计目标是将哪些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集。
这里我感觉只要你能正确说出，分布式协调服务协调的是什么就可以说清楚了。
总结:
Zookeeper为分布式应用提供了高效且可靠的分布式协调服务，其实现依赖于ZAB协议，实现了一种主从服务器模式的架构来保持数据的一致性（Zookeeper本身可保证分布式数据的一致性，从而可以提供高效可靠的协调服务）。
Zookeeper作为分布式协调服务提供了诸如统一命名服务，配置管理和分布式锁等分布式的基础服务。在解决分布式数据的一致性方面，Zookeeper并没有直接采用Paxos算法，而是采用了一种被称为ZAB(Zookeeper Atomic Broadcast)原子广播协议的一致性协议。
ZK是Google的Chubby（基于paxos算法的分布式锁服务）一个开源的实现。由于ZK自身的高可用性和可保持一致性，所以可以将其用于很多系统服务：分负载均衡，命名服务，分布式锁，集群管理，master选举等，都是zk提高的协调服务。
