Article Outline
ZooKeeper是一个分布式的开源分布式应用程序协调服务，是Google的Chubby的一个开源实现，Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等
ZooKeeper的特性
顺序一致性
从同一个客户端发起的事务请求，最终将严格地按照其发起顺序应用到ZooKeeper里
原子性
所有事务请求的处理结果在整个集群所有机器上的应用情况是一致的，即整个集群要么都成功应用了某个事务，要么都没有应用
单一视图
无论客户端连接的是哪个ZooKeeper服务器，其看到得服务端数据模型都是一致的
可靠性
一旦服务端成功地应用了一个事务，并完成对客户端的相应，那么该事务所引起的服务端状态变更将会一直被保留，除非有另一个事务对其进行变更
实时性
ZooKeeper保证在一定时间段内，客户端最终一定能从服务端读取到最新的数据状态
ZooKeeper的设计目标
简单的数据结构
ZooKeeper使分布式程序能通过一个共享的树形结构的名字空间来进行相互协调，即ZooKeeper服务器内存中的数据模型由一系列被称为ZNode的数据节点组成，ZooKeeper将全量的数据存储在内存里，以此来提高服务器吞吐，减少延迟的目的
可以构建集群
ZooKeeper集群通常由一组机器构成，组成ZooKeeper集群的每台机器都会在内存中维护当前服务器状态，并且每台机器之间都相互通信
顺序访问
对于来自客户端的每个更新请求，ZooKeeper都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序
高性能
ZooKeeper和Redis一样全量数据存储在内存中，100%读请求压测QPS 12~13W
ZooKeeper可以做什么
分布式服务注册与订阅
在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就需要在这些对等的服务器中选择一个来执行相关的业务逻辑，比较典型的服务注册与订阅，典型代表如 dubbo
分布式配置中心
发布和订阅模型，即配置中心。发布者将数据发布到ZK节点上，供订阅者获取数据，实现配置中心的集中式管理和动态更新，典型代表如 disconf
命名服务
在分布式系统中，通过使用命名服务，客户端应用能根据指定名字来获取资源或服务的地址、提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，进程对象等等，上述都可以统称为名字。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path即可作为一个名字
分布式锁
得益于ZooKeeper保证了数据的强一致性。锁服务可分为两类：
保持独占 所有试图获取这个锁的客户端，最终只有一个能成功获得这把锁。通常的做法是把zk上的一个znode看作一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute_lock节点，最终成功创建的那个客户端即拥有了这把锁
控制时序 所有试图获取这个锁的客户端，最终都会被安排执行，但是有全局时序。做法与保持独占类似，然而 /distribute_lock 已经事先存在，客户端在它下面创建临时有序节点（可通过节点属性控制：CreateMode.EPHEMERAL_SEQUENTIAL）。ZK的父节点 /distribute_lock 维持一份sequence，保证子节点创建的时序性，从而形成每个客户端的全局时序
Master选举
利用ZooKeeper的特性可以轻易实现Master选举功能：
- 选择一个根节点，例如:/master，多台机器同时对该节点尝试创建一个子节点/master/node，借助zooKeeper特性，最终只有一个机器能够创建成功，成功的机器就是master
负载均衡
使用ZooKeeper实现负载均衡：
- 需要在ZooKeeper指定path下注册提供服务的集群中每个节点的ip地址
- 消费者需要在该path上注册watcher，当服务提供者集群中增删几点时，ZooKeeper会发起watcher通知，所有消费者都会收到该watcher回调
- 此时，消费者可以及时知晓服务提供者集群中节点状况，在可用服务器列表中进行负载均衡计算