本文深入分析了ZooKeeper的Watch事件机制，包括服务端如何维护watch表，触发和通知过程，以及客户端的响应。特别指出，ZooKeeper的Watch只触发一次，断开连接期间的事件会丢失，并在恢复时重新注册。建议在开发中，为了防止数据丢失，应在Watch回调后先注册再获取数据。
Watch实现
服务端
zookeeper server为每个本地client连接（不是session）维持一份watch表（map表），用于接收该client的watch请求，但不会把watch请求同步到其它节点（官方解释这样轻量化设计，好出多多…）
每次更新某个数据时，就会触发watch通知，开始遍历本地client是否有对应watch请求事件，如果有，再判断该连接是否连接正常，连接正常则立马发通知到client，否则跳过当前client，遍历下一个。与ETCD的机制不同，zks并不会存储该事件为历史事件（对比etcd可以通过index获取错过的事件，这点还是ETCD做的比较好）。
Zks会启动独立线程，定时执行删除已断开连接的watcher，避免失活的watcher驻留消耗资源。
客户端
根据应用请求watch类型，向当前连接的服务器申请watch请求，异步等待请求回复。若收到对应的watch回复，则执行对应的回掉后，删除该watch请求。
当连接断开时，则所有client的watcher会收到session断开事件执行回调，但
最低0.47元/天 解锁文章
4039
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
