zookeeper应用场景

zookeeper可以实现统一命名服务、配置管理、锁和队列、状态同步、集群管理等功能

注册中心

zookeeper作为注册中心

依赖于临时节点
服务提供者启动时，将服务名称，ip地址注册到配置中心
服务消费者启动的时候，会先去注册中心中全量拉取服务的注册列表，缓存到本地，当消费者调用服务时，不会再去请求注册中心，直接通过负载均衡算法从ip列表中取出一个ip进行调用
当服务提供者下线（上线），相应的ip会从服务提供者列表中移除（新增），注册中心会将服务ip列表发送给服务消费者，刷新缓存
感知服务上下线（心跳检测，定时向服务提供者发送请求，确认是否在线）

注册中心对比

关系型数据库遵循的原则：ACID原则（A:原子性 C:一致性 I:独立性 D:持久性）
非关系型数据库遵循的原则：CAP原则（C:强一致性 A:可用性 P:分区容错性）

Eureka保证AP
zookeeper保证CP，因为在leader挂掉后，在进行新的leader选举过程中(30s~120s)，zk是不会接受客户端的读写操作的，所以不满足可用性

分布式协调

ZooKeeper 中特有 watcher 注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对 ZK 上同一个 znode 进行注册，监听 znode 的变化（包括 znode 本身内容及子节点的），其中一个系统 update 了 znode，那么另一个系统能够收到通知，并作出相应处理

以mq举例，A系统发个请求到mq，B系统消息消费之后处理了。A系统如何知道B系统的处理结果？
使用zookeeper实现分布式系统之间的协调工作。A系统发送请求之后可以在zookeeper上对某个节点的值注册个监听器，一旦B系统处理完了之后就修改zookeeper那个节点的值，A系统就可以收到通知

分布式锁

依赖于临时顺序节点，锁服务分为两类，一类是独占锁，一类是顺序锁

独占锁

场景：对某数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行完另一个再执行。

方案：使用zookeeper，一台机器接收到请求之后先获取zookeeper上的一把分布式锁（创建一个znode），接着执行操作，操作完成之后进行删除，另一个机器也尝试去创建那个znode，发现创建不了，因为该节点已被创建，等第一个机器执行完之后再执行。

顺序锁

三个系统A/B/C都去访问locks节点，访问的时候会创建带顺序号的临时/短暂节点，（例如，A创建了id_0000节点，B创建了id_0001节点，C创建了id_0002节点）
拿到/locks节点下的所有子节点（id_0000，id_0001，id_0002），getChildren方法，判断自己创建的是不是最小的节点
如果是，则拿到锁，执行完操作之后，把创建的节点删掉，即为释放锁
如果不是，找到比自己小1的节点，exists方法，并进行监听，发现比自己小1的节点删掉之后，发现自己已经是最小的节点了，拿到锁
如果在操作过程中，应用服务挂掉了，那么由于连接断开，此时的顺序临时节点也会自动删除

集群管理与master选举

依赖于临时节点，通过感知节点变化来获取集群状态，在约定的父目录下创建临时节点，然后监听父目录下临时节点变化消息，一旦有机器挂掉，该机器与zookeeper连接断开，其创建的临时目录节点就会被删除，从而触发监听事件，通知其他机器；而有新机器加入也会触发监听事件，通知到其他机器
如系统A、B、C，在集群groupMember下挂三个临时节点A、B、C，只要A系统挂掉，groupMember/A节点就会删除，通过监听groupMember下的子节点，B、C系统就可以感知到系统A挂了
除了感知节点上下线变化之外，zookeeper还可以实现动态选举master功能（主从架构下），使用临时顺序节点
zookeeper每次选举最小编号的作为master，如果master挂了，对应节点删除。然后让最小的编号节点做为master，这样就可以实现动态选举功能了。

在 Hbase 中，也是使用 ZooKeeper 来实现动态 HMaster 的选举。在 Hbase 实现中，会在 ZK 上存储一些 ROOT 表的地址和 HMaster 的地址，HRegionServer 也会把自己以临时节点（Ephemeral）的方式注册到 Zookeeper 中，使得 HMaster 可以随时感知到各个 HRegionServer的存活状态，同时，一旦 HMaster 出现问题，会重新选举出一个 HMaster 来运行，从而避免了 HMaster 的单点问题

可切换主备，主挂了通过zookeeper感知切换到备。

统一配置管理(配置中心)

发布与订阅模型，即所谓的配置中心，发布者将数据发布到 ZK 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新，各个系统监听这个节点有无变更，如果变更了，及时响应。例如全局的配置信息，分布式服务框架的服务地址列表等就非常适合使用。

应用中用到的一些配置信息放到 ZK 上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个 Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。
分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在 ZK 的一些指定节点，供各个客户端订阅使用。
分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用来分配收集任务单元，因此需要在 ZK 上创建一个以应用名作为 path 的节点 P，并将这个应用的所有机器 ip，以子节点的形式注册到节点 P 上，这样一来就能够实现机器变动的时候，能够实时通知到收集器调整任务分配。

统一命名服务

在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用 ZK 提供的创建节点的 API，能够很容易创建一个全局唯一的 path，这个 path 就可以作为一个名称。