5. Zookeeper精要-Zookeeper Watches

Zookeeper是为大型分布式应用程序所设计的可拓展、强中心化的一个服务，客户端访问此类的服务通常情况下都是通过轮训和拉取模式，但是在大型且复杂的分布式系统之中，拉取模式在拓展性方面都会有一定的局限性。为了解决这个问题，Zookeeper的设计者实现了一种客户端从Zookeeper服务端获取通知的一种机制代替了事件的轮训。这种机制类似于推送模式，通知被推送给已经在Zookeeper服务端注册的客户端。

任何和znode相关的修改客户端都可以在Zookeeper服务端注册，这种注册在Zookeeper的术语中我们称之为设置一个watch。在znode发生修改时，所设置的watch就会让客户端获得一个通知。一个watch只能执行一次性操作，即一个watch只能出发一次通知，如果客户端通过设置watche并接收到一次通知之后还想继续接受通知，客户端必须在每次接受到事件通知时重新注册watch。

我们通过一个集群中群成员管理的一个例子来阐述Zookeeper的watches和通知的概念。

1. 在集群中，有一个节点，叫做Client1,当集群中有新的节点加入时，Client1需要接收到通知。任何加入集群的节点都会在Zookeeper的/Members路径下创建一个临时的znode。
2. 现在，集群中的另外一个节点Client2加入集群并在/Members下创建了一个临时znode Host2。
3. Client1在Zookeeper的/Members路径下发起了一个getChildren的请求并且设置了一个watch。当Client2在/Members下创建了一个临时znode Host2时，watch就会被触发，然后Client1就会接受到一个从Zookeeper服务端发过来的通知。如果此时Client1再向Zookeeper服务端发送一个getChildren的请求时，它就会看到新的znode Host2。

Zookeeper的watches是一次性触发，也就是说如果客户端接收到一个watche时间并且想再次接受未来变更时的通知，那么它就必须重新设置一个watch。

以下的三个变革可以触发watch：

1. znode数据的改变，如使用setData操作在znode域中写入新数据。
2. znode子节点的改变，如使用delete操作删除znode的子节点。
3. znode的创建或删除。

关于watches和通知，Zookeeper确保维护一下几点：

1. Zookeeper保证所有的watch都是按先进先出（FIFO）排序，通知也是按顺序发送。
2. 同一个znode的第二次修改发生之前watch的通知就一定发送给客户端。
3. watch事件的顺序依赖于Zookeeper服务所能检测到的数据更新的顺序。

注意：

当客户端与服务端断开连接，在重新建立连接之前，它不会收到任何watch出发的通知。如果客户端和Zookeeper服务端重新建立连接，以前注册过的watche会被重新注册和触发，如果客户端连接到了一台新的Zookeeper服务器上，任何Session事件的watch也会被触发，从一台机器上断开连接并连接到一台新的机器上对于Zookeeper客户端应用程序来说是透明的。

虽然Zookeeper保证所有已经注册的watch都能够发送给客户端，即使客户端与Zookeeper服务端断开连接并重新连接到一台新的Zookeeper服务器上，但是有一种可能的场景也是值得注意的，那就是客户端watch丢失。这种指定的场景指的是客户端对一个没有创建完成的znode设置了watch，这种情况下，当znode创建完成之后并在客户端和服务端断开连接的情况下被删除的话watch事件将会丢失。