是一个分布式应用程序协调服务，是Hadoop和HBase的重要组件。Zookeeper可以为分布式应用提供一致性服务。
功能包括：集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式通知协调等等。
在分布式应用中，由于工程师不能很好的使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可拓展的、分布式的、可配置的协调机制来统一管理系统的状态。
角色状态
- 三种角色：leader，follower，observer
- 四种状态：leading，following，observing，looking
组织架构（系统模型）：
数据结构：
zookkeeper 提供的名称空间非常类似于标准文件系统，key-value 的形式存储。名称 key 由斜线 / 分割的一系列路径元素，zookeeper 名称空间中的每个节点都是由一个路径标识。
设计目的：
- zookeeper是一个开源分布式的服务，它提供了分布式协作，分布式同步，配置管理服务功能
- zookeeper通过上述提供的服务，来解决分布式集群中应用系统的一致性问题
- zookeeper维护和监控你的存储的数据的状态变化，通过监控这些数据状态的变化，从而可以达到基于数据的集群管理，实现分布式协作，分布式同步，配置管理等
CAP理论：
Zookeeper保证了一致性和分区容错性，没有保证可用性，而Eureka保证的是一致性和可用性
原因在于Eureka内部使用http通信，网络故障会导致丢包或者数据延迟，而Zookeeper是因为Leader的选举时间非常长，在选举的时候，基本会影响可用性
**配置管理：**当多个PCServer运行同一个应用系统的时候，他们运行的应用系统的某些配置项是完全相同的，如果需要修改这些相同的配置项，就需要同时修改每一个PCServer
集群管理：
需求描述一：多台Server组成一个服务集群，那么必须要一个leader知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其他集群必须知道，从而做出调整重新分配五福策略。同样当增加集群的服务能力时，就会增加一台或者多台Server，同样也必须让leader知道
需求描述二：分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑往往只需要一个机器执行，其他机器共享结果，这样可以大大减少重复劳动，提高性能。
案例：
- Hbase中，使用Zookeeper来十天动态HMaster的选举
- 搜索系统中，如果集群中某个机器都生成一份全量索引，不仅耗时，而且不能保证彼此之间索引数据一致性。因此让集群中的Master来进行全量索引的生成，然后同步到集群中的其他机器。
命名服务：
需求描述：分布式系统中，需要通过名字来获取资源或服务地址，提供者等信息，这个名字要求整个系统唯一，zookeeper的树形结构先天满足这种全局唯一的path，这个path就可以作为这个名称
案例：阿里巴巴分布式框架Dubbo使用Zookeeper来作为其命名服务，维护全局的服务地址列表
分布式通知/协调：
需求描述1：心跳检测机制，检测系统和被检测系统之间并不直接关联起来，而是通过zk上某个节点关联大大减少系统耦合
需求描述2：系统调度模式：某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行响应的推送工作。管理人员在控制台作的一些操作实际上是修改了ZK上某些节点的状态，而ZK就把这些变化通知给他们注册Watcher的客户端，即推送系统，于是，做出了响应的推送任务
需求描述3：工作汇报模式：一些类似于任务分发系统，子任务启动后，到ZK来注册一个临时节点，并且定时将自己的进度进行汇报（将进度写回到这个临时节点），这样任务管理者就能够实时知道任务进度
- 优点：大大降低系统之间的耦合
负载均衡：
需求描述：分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就需要在这些对等的服务器中选择一个来执行相关的业务逻辑
案例：linkedin开源的KafKaMQ和阿里开源的metaq都是通过zookeeper来做到生产者、消费者的负载均衡
**生产者负载均衡：**metaq发送消息的时候，生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息，因此metaq在运行过程中，会把所有broker和对应的分区信息全部注册到ZK指定的节点上，默认的策略是一个一次轮询的过程，生产者再通过ZK获取分区列表之后，会按照brokerId和partition的顺序排列组织成一个有序的分区列表，发送的时候按照从头到尾循环往复的方式来选择一个分区发送消息。
**分布式锁：**跨进程和跨机器的所服务
**分布式信号量（同步队列）：**当N个都满足时，下一步的操作才可用，否则一直等待所有条件都满足