ZooKeeper应用场景

数据发布/订阅

Zookeeper采取推拉结合模式。

• 服务端会推给注册了监控节点的客户端 Wathcer 事件通知

• 客户端获得通知后，然后主动到服务端拉取最新的数据

在实现时只需要少许步骤：

1. 创建一个 Znode 上，例如/config

2. 客户端启动后读取服务端节点，并且注册一个数据变更的 Watcher

3. 当Znode上数据发生变化时，客户端就会知道了

负载均衡

实现步骤：

• 创建Znode，例如/servers

• 每个客户端在启动的时候在/servers下面创建子临时节点，并存储ip、port、name等信息

• 当客户端要调用某个服务时，可以获取Znode的数据，并自行定义负载均衡的算法，选取一个地址进行调用

分布式协调/通知

一般情况下，像eureka这种内部服务可用性都采取了大量的心跳机制，检测各服务是否存活。

但是使用Zookeeper时，基于临时节点的特性，只要服务挂了，会话消失，临时节点消失。

命名服务

• 典型的rpc实现，如dubbo，服务启动时把自己的应用名称以及ip、port等信息存储

• 典型的分布式ID生成，如美团的leaf

利用Zookeeper的顺序节点的特性，可以作为发号器，自动生成有顺序的id。

集群管理

其实也是运用了临时节点的特性，服务上下线的时候能够给集群监控端或者控制端提供具体服务和节点的信息，方便下一步监控和控制。

Master 选举

基本思想有点像分布式锁，当多个节点启动时，会竞争去创建一个Znode，创建成功的那个就是Master，其他节点失败后就会Watch这个节点，如果消失，重新选举。

分布式锁

当业务客户端要申请一把锁的的时候，可以向服务端创建临时Znode，只会有一个成功，成功者获取了锁，执行相应的业务逻辑，执行完后或者宕机，锁会自动释放；其他业务节点发现已有节点，则注册一个节点变更事件，监听到变更后重新执行申请锁的流程。

分布式队列

入队操作就是在创建自增序的子节点，并把数据（队列大小）放入节点内。出队操作就是先找到序号最下的那个节点，取出数据，然后删除此节点。