【Zookeeper】Leader选举机制示例

本文介绍下zookeeper中leader选举机制的基本用法和关键知识点。

一、 选项设置
提到Leader选举，先需要重点介绍下创建znode时的Flag选项。

• ZOO_EPHEMERAL
  

ZOO_EPHEMERAL，用来标记当创建这个znode的节点和Zookeeper失去连接后，这个znode将不再存在在Zookeeper里，Zookeeper使用Watcher察觉事件信息。当客户端接收到事件信息，比如连接超时、节点数据改变、子节点改变，可以调用相应的行为来处理数据。

• ZOO_SEQUENCE

ZOO_SEQUENCE 用来标识节点命名具有递增的后缀序号(一般是节点名称后填充 10 位字符的序号，如 /xyz0000000000, /xyz0000000001, /xyz0000000002, ...)，如下便所示，直接在/app_watch/下创建节点。

[zk: localhost:2181(CONNECTED) 42] ls /app_watch
[0000000017, 0000000018]

同样地，ZOO_EPHEMERAL, ZOO_SEQUENCE 可以组合使用，下面的示例中就用到了序列号的特性。

二、监视机制

以下面的示例中，可以看到在client的回调中，每监视到一次事件通知，需要再次调用触发监视，这里就需要具体说明下zookeeper和 watch机制。

Zookeeper 中最有特色且最不容易理解的是监视(Watches)。Zookeeper 所有的读操作——getData(), getChildren(), 和 exists() 都 可以设置监视(watch)，监视事件可以理解为一次性的触发器， 官方定义如下： a watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes。对此需要作出如下理解：

• （一次性触发）One-time trigger

当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了 getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对 /znode1 设置监视，否则客户端不会收到事件通知。

• （发送至客户端）Sent to the client

Zookeeper 客户端和服务端是通过 socket 进行通信的，由于网络存在故障，所以监视事件很有可能不会成功地到达客户端，监视事件是异步发送至监视者的，Zookeeper 本身提供了保序性(ordering guarantee)：即客户端只有首先看到了监视事件后，才会感知到它所设置监视的 znode 发生了变化(a client will never see a change for which it has set a watch until it first sees the watch event). 网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件