ZooKeeper的典型应用场景

数据发布/订阅

数据发布/订阅系统，即所谓的配置中心，顾名思义就是发布者将数据发布到Zookeeper的一个节点或一系列节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新

发布/订阅系统一般有两种设计模式，分别是推（Push）模式和拉（Pull）模式。
推模式：服务器主动将数据更新发送给所有订阅的客户端；
拉模式：客户端主动发起请求来获取最新数据。
ZooKeeper采用的是推拉相结合的方式，客户端想服务器端注册直接需要关心的节点，一旦该节点的数据发生变更，那么服务器就会向相应的客户端发送Watcher事件通知，客户端接受到这个消息通知后需要主动到服务器端获取最新的数据。

如果将配置信息存放到ZooKeeper上进行集中管理，那么通常情况下，应用在启动的时候会主动到ZooKeeper服务器上进行一次配置信息的获取，同事在指定的节点上注册Watcher监听，如果配置信息发生了变更，那么服务器都会实时通知到所有订阅的客户端。

Master选举

在分布式系统中，Master往往用来协调集群中其他系统单元，具有对分布式系统状态变更的决定全。例如：在一些读写分离的应用场景中，客户端的写请求往往是由Master来处理的，而在另外一些场景中，Master负责处理一些复杂的逻辑，并将处理的结果同步给集群的其他单元。

原理：利用ZooKeeper的强一致性，能够很好地保证在分布式高并发的情况下节点的创建一定能够保证全局唯一性，也就是说如果同时多个客户端请求创建一个节点，那么最终一定只会有一个客户端请求能够创建成功。利用这个特性就能够很容易的在分布式环境中进行Master选举

image

分布式锁

在平时的实际项目开发中，往往很少会去在意分布式锁，而依赖于关系型数据库固有的排他性来实现不同进程之间的互斥。但是缺点就是会增加数据库压力

ZooKeeper实现分布式锁，排他锁 ，共享锁

排他锁

通过Zookeeper上的数据节点来表示一个锁，eg: /exclusive_lock/lock节点就可以被定义为一个锁，如图：

image

获取锁： 所有的客户端都会视图通过 create() 接口，在/exclusive_lock节点下创建一个临时节点 /exclusive_lock/lock。Zookeeper只会让一个客户端创建成功，那么就可以认为该客户端已经获取了锁，同时让其他没有获取到锁的客户端设置 Watcher 监听

释放锁：出现了一下两种情况，都可能释放锁，导致其他监听的客户端重新获取锁。
当前获取锁的客户端机器宕机，ZooKeeper上的这个临时节点就会被删除
正常执行完业务逻辑后，客户端会主动将自己创建的临时节点删除。

image

共享锁

当前事务只能做读取操作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上所有的共享锁都被释放。

image