ZK事件回调
当一个client访问ZK时，client与ZK保持长连接。应用可以通过client的api注册一些callback，当对应的事件发生时，client会执行对应的callback。
如果你基本了解ZK的watch机制，可直接看最后一节－ 一般性原则。
类别
总体上说，ZK的事件分为两类
session 事件 －表示client与ZK的连接状态
znode 事件 － 表示client所关注节点的状态
注册
以C lib为例，client api接受的callback定义如下：
1
typedef void (*watcher_fn)(zhandle_t *zh, int type, int state, const char *path,void *watcherCtx);
应用通过client api注册对应的callback，初始时通过zookeeper_init注册一个callback，用于全局默认的callback，保存在zh的watcher字段中（如果fn为NULL，client用一个空函数代替）。
当发生session事件时，该callback被执行。
1
zhandle_t *zookeeper_init(const char *host, watcher_fn fn, int recv_timeout, const clientid_t *clientid, void *context, int flags);
当client与ZK建立连接后，在进行数据查询的同时可以注册callback，典型的通过以下几个函数注册：
1
2
3
4
5
int zoo_wget(zhandle_t *zh, const char *path, watcher_fn watcher, void* watcherCtx, char *buffer, int* buffer_len, struct Stat *stat);
int zoo_wexists(zhandle_t *zh, const char *path, watcher_fn watcher, void* watcherCtx, struct Stat *stat);
int zoo_wget_children(zhandle_t *zh, const char *path, watcher_fn watcher, void* watcherCtx, struct String_vector *strings);
其中zoo_wget与zoo_wexists注册的callback用于监视path对应的znode的状态（wget与wexists区别一会解释）；
zoo_wget_children注册的callback用于监视path对应的znode的子节点的状态。
触发
当事件发生时，注册的callback被执行，参数中zh是对应的handle，type表示事件的类型，state表明该client的连接的当前状态，path对应的是节点路径，watcherCtx是callback被设置时指定的（用于传递数据）。
type有以下几种类型 ：
1
2
3
4
5
6
7
8
9
10
11
// c客户端，ZOO_SESSION_EVENT代表连接/session事件
const int ZOO_SESSION_EVENT = -1;
const int ZOO_CREATED_EVENT = 1;
const int ZOO_DELETED_EVENT = 2;
const int ZOO_CHANGED_EVENT = 3;
const int ZOO_CHILD_EVENT = 4;
对于第一类的session事件，type为ZOO_SESSION_EVENT，path为NULL ，state可能为一下几种类型 ：
1
2
3
4
5
6
7
const int ZOO_EXPIRED_SESSION_STATE;
const int ZOO_AUTH_FAILED_STATE;
const int ZOO_CONNECTED_STATE;
const int ZOO_CONNECTING_STATE;
（为叙述方便，下面会简写state的变量名，如EXPIRED表示ZOO_EXPIRED_SESSION_STATE）
当收到EXPIRED时，表明服务端判定该session已经超时并清理该session创建的临时节点，之后任何在zh上的查询将返回EXPIRED。
当遇到EXPIRED时，说明该zh已经不能在用了，这时候需要close该handle(zookeeper_close）来回收其占用的资源。
当遇到AUTH_FAILED时，说明使用zoo_add_auth添加的认证信息在ZK上验证失败了（公司内部一般没用auth，基于IP白名单的认证对应用透明，不需要add_auth），这时候该zh也不能用了，需要close。
当返回CONNECTED时，说明与ZK建立session成功，可以进行正常的读写了。
当返回CONNECTING时，说明与ZK的连接断开（可能网络抖动等），这时client会自动与ZK重连，重连上之后触发CONNECTED。在CONNECTING时，使用api读写ZK将返回ZCONNECTIONLOSS。
对于第二类znode事件，type为ZOO_CREATED_EVENT/ZOO_DELETED_EVENT/ZOO_CHANGED_EVENT/ZOO_CHILD_EVENT。
顾名思义，CREATED表明节点被创建，DELETE表明节点被删除，CHANGED表示节点内容被跟改，CHILD表示节点的子节点被创建或删除。
示例
zhandle_t zh = zookeeper_init(zkurl**callback1**)，当zh连上ZK后，收到第一个事件callback1(type=SESSION,state=CONNECTED)
然后执行zoo_wget(**path2**callback2"")并返回成功，zoo_wexists(**path3**callback3"")返回成功。
之后zoo_set(zh**path2**)，path2被更新，client会收到callback2(CHANGED,state=CONNECTED)。
假设此时zh连接的那台ZK机器挂了，client会收到callback1(SESSION,CONNECTING)，callback3(SESSION,CONNECTING)。
之后client会重试到其它机器上，依次收到callback1(SESSION,CONNECTED)，callback3(SESSION,CONNECTED)。
假设之后该session超时了，依次收到callback1(SESSION,EXPIRED)，callback3(SESSION,EXPIRED)
这个示例的隐含如下信息：
1. init注册的callback在发生session相关的事件时被触发，不需要重新注册。
2. get/exists/get_children注册的callback，收到znode事件后callback被触发且失效，需要重新注册。如果在发生znode事件前发生session相关的事件，callback会被触发，但不会失效。
通过client api注册的callback可能收到的事件对应关系可以总结成一张表格：
事件
会触发由此API添加的回调方法
SESSION_EVENT zookeeper_init()，wget()，wexists()，wget_children()
CREATED_EVENT wexists()
DELETED_EVENT wget()，wexists()，wget_children()
CHANGED_EVENT wget()，wexists()
CHILD_EVENT wget_children()
其中wexists可以对不存在的节点添加watcher，当节点被创建会收到CREATED，当wexists对一个已存在的节点添加watcher时，与wget等价。
wget_children添加的/path的子节点被创建删除时，会收到CHILD，当/path被删除时，会收到DELETED。
在client的api中，可复用全局的那个watcher函数指针
1
zoo_get(zhandle_t zh, const char *path, int watch, char *buffer,int buffer_len, struct Stat *stat);
当watch非0时，以zookeeper_init传入的watcher做为callback( 不推荐这种使用方式)。
一般性原则
在使用ZK的事件回调时，最好需要区分开ZK的这两大类事件。
一个callback_s，zookeeper_init时传入，用于处理session事件，比如EXPIRED时close句柄并重新建立连接。
一个callback_z，用于wget等时，只处理znode事件。
这么做的原因是session事件发生时，如上所述，callback_z也会被执行，如果callback_z也处理EXPIRED事件，则该逻辑会被执行多次，带来不必要的问题。
对于不同的查询函数，可以选择注册不同的callback，只需遵守watch数据的callback只处理znode事件即可。