Zookeeper-Watcher机制与异步子用原理

Zookeeper-Watcher机制与异步调用原理

?

F1.Watch生命周期

?

?Zookeeper提供了如下几种可以"注册watch"的操作:exist,getChildren,getData;而对于create,setData,delete是有可能触发"watcher"的操作.客户端并不会把用户创建的watcher对象传递给Server,而是传递给server一个标记(boolean值)告知server此请求所涉及到的patch上是否有watcher..对于client端请求是队列话的,即一个操作阻塞直到server端响应.(异步操作稍后介绍,它不阻塞)Server对Client的每个请求的响应体中,都会明确告知此次响应的类型(是正常操作响应还是"事件",操作对应的xid,结果类型,错误信息等等);如果响应体中没有错误信息且其他校验正常的话,我们认为此次请求被正确的执行了.可能考虑到在Client与Server端传递wath对象所带来的程序复杂度,ZK采取了"分制"的方式,在Client端和Server端分别采取了不同的技巧来保存Watch列表;(参见上述)Server在接收Client请求时,会检测此次request体中是否持有watcher信息,如果有,则会导致Server端的watcher列表中新增一个此path关联的watch,只有exist/getChildren/getData会导致此操作.记住watcher信息将会被保存在ZKDatabase中(内存中,而非持久,ZKDatabase会持久Session/ACL/Data).那么对于create/setData/delete请求,将会触发watcher列表的检测,比如create操作,创建一个path,在实际的数据存储结束后,将会在watch列表中遍历是否有此path所关联的watches,如果有,则依次触发.触发watch其实很简单,对于server端而言,它持有了每个path所关联的watch列表,而且每个watch实例正是一个ServerCnxn对象(每个Client与Server的连接处理器,就是一个ServerCnxn对象),因为触发一个watcher将是便捷性将是显而易见的,直接将此watcher事件所对应的path/类型直接通过IO的方式发送出去;因此哪个Client注册了事件,将会被响应的ServerCnxn处理;集群中每个Server几乎会在同一时间向Client交付事件消息.可能因为网络的问题,不可确保他们能够在极短的时间差内都获得事件."插队",是因为对于watcher事件,将不再和其他Client操作放在同一队列中,而是直接通过IO发送,因为ServerCnxn处理client响应是同步的(方法是同步方法),即事件信息将会在当前packet发送之后被立即发送.事件一旦被server触发,将会在watcher列表中删除,因此watcher是一次性的(同一个path下的同一类型watcher).Client接收到Event响应结果之后,将会把此消息体放在eventQueue中,等待EventThread去remove并触发.EventThread将event队列中的事件,逐个移除并处理,每移除一个event,都会导致Client本地维护的watcher列表删除相应的watcher(根据path和event类型决定),移除之后并获取到Client维护的watcher对象(此对象就是先前的操作中注册的watcher),watcher对象明确了回调方法,此时将会执行watcher.process(),那么调用者的业务方法将会在此刻被执行.[对于业务方法被执行,从整个周期中,我们可以认为是异步的].对于节点的create操作,将会触发先前注册的"exist""getChildren"事件被触发;对于节点的delete操作,将会触发先前注册的"exsit""getChildren"事件被触发;对于节点的setData操作,将会触发先前注册的"getData"事件被触发......每个触发的事件都会包含事件的类型(比如:nodeCreate,nodeDelete等),对于用户自定义的watch.process()方法中可以根据事件类型做特定的处理.对于Server端遇到session关闭,连接关闭等异常时,都会触发和此连接(ServerCnxn)关联的watch列表.不过对于Client端却做了"弥补";"zookeeper.disableAutoWatchReset"这个系统参数的意义就是"是否关闭watch自动重置";如果此参数为false(即为开启"自动重置"),那么在Client端遇到连接异常(比如重连操作)时,都会将本地已有的watcher列表全部发送给Server(此操作称为"setWatches"),如果连接成功,那么新的server仍然会持有watcher列表,接下来事件将会被如期触发,就像网络异常根本就没发生一样..那么为什么ZK没有默认开启此参数呢?可能考虑到这是个双刃剑,Client有可能在网络异常时会做其他的操作(因为网络异常,最终也会触发一个本地的Event,Client可以在此Event中做自定义操作);也有可能在网络异常期间,Cluster中的数据已经被改变,极有可能这些事件中的部分事件已经被错过,即使接下来被触发,也将不能正确的反应目前的现状.如果你期望获得正确的结果,要么重新注册watcher,要么检测现有的数据是否已经改变.

到目前为止,watcher机制我们已经走到"头"了...