zookeeper是一个高可用的分布式数据管理与协调框架，基于对ZAB算法的实现，该框架可以很好地保证分布式环境中数据的一致性。算法
数据发布/订阅系统，即配置中心。发布者将数据发布到zk上，功订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。
发布/订阅系统通常有两种设计模式：推push和拉pull。zk采用推拉结合的方式：客户端向服务端注册本身须要关注的节点，一旦该节点的数据发生变动，那么服务端就会向相应的客户端发送Watcher事件通知，客户端收到这个通知以后，须要主动到服务端获取最新的数据。设计模式
使用场景服务器
适合进行配置管理的信息通常具备如下特色：网络
使用方式并发
将须要集中管理的配置信息写到zk的数据节点上，称为配置节点负载均衡
集群中的每台机器在启动初始化阶段，从zk的配置节点上读取配置信息，同时在该节点上注册一个页游数据变动的Watcher，一旦节点数据发生变化，全部订阅的客户端可以获取到变动通知框架
系统运行过程当中，若是配置发生变化，客户端会接收到变动通知后，就能够从新获取最新的数据。异步
典型场景：动态DNS服务分布式
分布式系统中，被命名的实体一般能够是集群中的机器、提供的服务地址或远程对象。其中较为常见的就是一些分布式服务框架中的服务列表。经过使用命名服务，客户端应用可以经过指定名字来获取资源的实体、服务地址和提供者的信息等。
zk提供的命名服务功能，可以帮助应用系统经过一个资源引用的方式实现对资源的定位和使用。广义上命名服务的资源定位不是真正意义的实体资源，在分布式环境中，上层应用阴影须要一个全局惟一的名字，例如，使用zk实现一套分布式全局惟一ID的分配也属于命名服务。ide
zk使用watcher注册与异步通知机制，可以很好地实现分布式环境中不一样的机器，甚至是不一样系统之间的协调与通知。
使用场景
机器间的心跳检测是指在分布式环境中，不一样机器之间须要检测到彼此是否在正常运行。传统的方法是在机器之间创建长链接，经过TCP链接固有的心跳监测机制实现上层机器的心跳检测。基于zk的临时节点特性，可让不一样的机器都在zk的一个指定节点下建立临时子节点，不一样机器能够监听临时节点来判断对应的客户端机器是否存活。经过这种方式，检测系统和被检测系统不须要直接关联，大大减小系统耦合。
集群管理，包括集群监控与集群控制。
传统的分布式系统中，经过在集群中每台机器上部署一个agent，由agent主动想指定的监控中心系统上报本身所在的机器状态。
zk中，使用watcher监听和临时节点的特性实现集群管理。
使用示例
Master选举，即在集群的全部机器中选举出一台做为Master。 利用zk的强一致性，即zk将会保证客户端没法重复建立一个已经存在的数据节点，来保证高并发下节点的建立能保证全局惟一性。
Master动态选举的过程大体以下：客户端集群在zk上指定节点下建立临时节点，在这个过程当中，只有一个客户端能建立成功，那么这个客户端所在的机器就成为了页游里的http://www.sangpi.com/Master。同时，其余没有在zk上建立成功的客户端会注册一个子节点变动的watcher，用于监控当前master是否存活，一旦发现master挂了，那么其他的客户端从新进行master选举。
http://www.sangpi.com/
利用zk的临时节点实现，过程与master选举相似
利用zk的临时顺序节点实现。每台机器在指定节点下建立临时顺序节点，并指定节点类型是读仍是写，并对节点建立子节点变动的watcher。同时判断本身在子节点中的序号大小，以及比本身小的节点的类型，例如若是本身想申请读锁，若是比本身小的节点都是读，则获取锁。
上面共享锁的实现原理是，只要子节点发生变动，全部机器都要收到变动通知并获取全部子节点列表。当集群中节点个数不少时，会致使发送大量的watcher通知，对zk服务器形成巨大的性能影响和网络冲击，更严重的是，当若是同一时间有多个节点发生变化，zk服务器会在短期内向其他客户端发送大量的时间通知——这就是所谓的羊群效应。
改进后的共享锁是每一个临时节点不对全部的子节点注册watcher，而是只对比本身序号小的最后一个节点注册watcher监听。
分布式队列，简单地讲氛围两大类，一类是常规的先进先出队列，另外一种是等到队列元素集聚后才统一安排执行的Barrier模型。
实现原理与全写的共享锁相似，使用临时顺序节点实现，每一个节点监听比本身序号小的最后一个节点。
利用临时节点实现。好比当子节点个数达到10后再继续往下执行，过程大概是：将指定节点的数据内容赋值为10，客户端在指定节点下建立临时节点，而后客户端读取指定节点的数据内容，并对子节点列表注册watcher。