zookeeper适用场景

dubbo（注册中心）

网上资料比较多，就不多描述，可自行baidu。

canal（主要用于主备切换）

出于容灾考虑，往往会配置两个Canal Server负责一个mysql数据库实例的数据增量复制。为了减少Canal Server 的dump请求对mysql master带来的性能影响，要求不同的Canal Server上的instance在同一时刻只能有一个处于Running状态，其他的instance处于Standby状态。具体步骤：

a）尝试启动。所有Canal Server上的instance都会向zk尝试创建一个临时节点，哪个Canal Server创建成功了，那么就让哪个Server启动

b）启动instance。将自己的信息写入该节点。其它的Canal Server对该节点注册Watch监听。

c）主备切换。如果服务节点与zk的会话失效，临时节点会被删除，从而所有的实例会重新竞争上岗，从而实现主备切换。但有一个问题，服务节点可能存在假死情况，网络出现闪断，导致zk认为其会话失效，从而释放Running节点，但此时Cannal Server对应的JVM并没未退出。解决策略：

状态为Standby的Cannal Sever在收到Running节点释放通知后，会延迟一段时间（通常5秒）抢占Running节点，而原本处于Running状态的instance可以不需要等待延迟，直接重新取得Running节点。

更多资料可参考《从Paxos到ZooKeeper》P219

otter

hbase

Hadoop

Kafka

分布式锁

分布式程序分布在不同主机上的进程对互斥资源进行访问的时候需要加锁。这样理解：很多分布式系统有多个服务窗口，但是某个时刻只让一个服务去干活，当这台服务器出问题的时候锁释放，立即fail over到其它的服务。

集群管理

分布式集群中，经常会由于各种原因，比如硬件故障，网络问题，有些节点挂掉、有些节点加进来。这个时候机器需要感知到变化，然后根据变化做出对应的决策，那么zk就实现了类似这种集群的管理。

master选举

分布式高并发情况下创建节点一定是全局唯一性，zk会保证客户端无法重复创建一个已经存在的数据节点。

客户端集群每天定时往zk上创建一个临时节点，例如 /master-selection/2017-10-20/binding，抢节点时，只有一个客户端创建成功，那么创建节点的客户端就成了master。其他客户端在/master-selection/2017-10-20上注册一个Watcher事件，用于监控Master机器是否存活，一旦发现当前Master挂了，其余的客户端会重新进行Master选举。

配置中心

在分布式系统中，一般会把服务部署到n台机器上，服务配置文件都是相同的，如果配置文件的配置选项发生了改变，那我们就得一台一台的去改动。这时候zookeeper就起作用了，可以把zk当成一个高可用的配置存储器，把这样配置的事情交给zk去进行管理，将集群的配置文件拷贝到zookeeper的文件系统的某个节点上，然后用zk监控所有分布式系统里的配置文件状态，一旦发现有配置文件发生了变化，那么每台服务器同步zk的配置文件，zk同时保证同步操作的原子性，确保每个服务器的配置文件都能被更新。

▼