ZooKeeper写事件与出发watcher的对应关系

下面表格列出了写操做与ZK内部产生的事件的对应关系：

	event For "/path"	event For "/path/child"
create("/path")	EventType.NodeCreated	NA
delete("/path")	EventType.NodeDeleted	NA
setData("/path")	EventType.NodeDataChanged	NA
create("/path/child")	EventType.NodeChildrenChanged	EventType.NodeCreated
delete("/path/child")	EventType.NodeChildrenChanged	EventType.NodeDeleted
setData("/path/child")	NA	EventType.NodeDataChanged

而ZK内部的写事件与所触发的watcher的对应关系以下：

event For "/path"	defaultWatcher	exists ("/path")	getData ("/path")	getChildren ("/path")
EventType.None	√	√	√	√
EventType.NodeCreated		√	√
EventType.NodeDeleted		√(不正常)	√
EventType.NodeDataChanged		√	√
EventType.NodeChildrenChanged				√

综合上面两个表，咱们能够总结出各类写操做能够触发哪些watcher，以下表所示：

	"/path"	"/path/child"
	exists	getData	getChildren	exists	getData	getChildren
create("/path")	√	√
delete("/path")	√	√	√
setData("/path")	√	√
create("/path/child")			√	√	√
delete("/path/child")			√	√	√	√
setData("/path/child")				√	√

若是发生session close、authFail和invalid，那么全部类型的wather都会被触发

zkClient除了作了一些便捷包装以外，对watcher使用作了一点加强。好比subscribeChildChanges其实是经过exists和getChildren关注了两个事件。这样当create("/path")时，对应path上经过getChildren注册的listener也会被调用。另外subscribeDataChanges实际上只是经过exists注册了事件。由于从上表能够看到，对于一个更新，经过exists和getData注册的watcher要么都会触发，要么都不会触发。

zkClient地址：https://github.com/sgroschupf/zkclient