确保zookeeper一定收到通知消息的方法

arongsoft

　　zookeeper能够同步同步各节点的znode数据，client可以使用getChildren，getData,exists方法在znode tree路径上设置watch，当watch路径上发生节点create、delete、update的时候，会通知到client。client可以得到通知后，再获取数据，执行业务逻辑操作。
　　但是因为没有消息接收后的确认机制，这个通知机制是不可靠的，也就是说znode的修改者并不知道是否所有的client都被通知到了，或者说client也不知道自己是否错过了哪些通知消息。这种现象可能由网络原因引起，也可能是client刚触发了watch事件，还没有来得及重新设置watch，下个事件就发生了(zookeeper只提供了一次性watch)。
　　在笔者的使用场景中，这是有问题的。在我们分布式配置管理的场景中，有3份配置副本，管理节点本地数据库中有一份，zookeeper中保存了一份，使用配置的软件引擎进程中保存了一份。当下发配置时，是需要全部软件引擎都生效最新的配置，而如果有某个引擎错过了通知，那么就会漏掉某个配置，导致问题，而到底谁没有成功生效，这些节点都不知道，甚至错过通知的节点自身也不知道。
　　因此我提出一种设计，至少让错过通知的节点自身知道错过了消息，并采取主动同步配置的方式，来补救。这样能够保证，配置下发后，至少一段时间后所有软件引擎的都使用了最新的配置。
　　这利用了zookeeper自身的几个特性：
　　1）zookeeper维护一个全局的操作id，zxid，每一个create,delete,update操作都会使该id加1。
　　2）zookeeper为每个路径(znode)节点都保存了它的修改版本dataversion，和最新一次修改zxid——mzxid。
　　3）zookeeper保证每个client连接的session中，看到的通知顺序与这些事件发生的先后顺序是严格一致的。
　　我们来假设要在/group/policy下增加、删除、修改配置，每个配置有1个节点，配置数量可以很多、而且不固定。client要知道增加了什么配置，修改了什么，删除了什么配置，因此设定了watch。其中A复杂修改这些配置，N1,N2,...Nm这些节点监听通知，并更新软件引擎的变量，使其生效配置。
　　首先A在/group/policy下做create、delete、update操作后，都要set 一次 /group/policy节点。这会导致/group/policy的dataversion加1。并且可以知道有几次操作，dataversion就增加几。
　　伪代码如下：
　　doSomeOperion();
　　setData("/group/policy","")
　　Ni节点要对/group/policy下节点发生修改的事件进行watch，还要对/group/policy节点自身的修改进行watch。因此如果Ni没有错过通知的话，它将一次触发两个通知：1）配置变化通知；2)/group/policy数据更新通知。
　　Ni要在本地保存三个变量current_dataversion,current_zxid
　　在Ni client初始化时：
　　current_dataversion=/group/policy的dataversion；
　　current_zxid=/group/policy的mzxid；
　　然后在watch到配置发生变化的回调函数中：
　　doSometing(); //生效具体配置
　　current_dataversion += 1; //期待/group/policy的下一个dataversion增加1
　　在watch到/group/policy的数据发生变化后回调函数中：
　　if current_dataversion == /group/policy的dataversion: //意味着没有漏掉消息
　　current_zxid = /group/policy的mzxid
　　elif next_dataversion < /group/policy的dataversion： //一位置有配置变化的消息没有收到
　　遍历/group/policy子节点
　　if /group/policy/znodei的mzxid > current_zxid：
　　使用znodei中的配置。
　　删除已经不存在znode的配置项；
　　同步完成；
　　next_dataversion = /group/policy的dataversion
　　current_zxid = /group/policy的mzxid
　　这样就可以保证client能够发现自己错过了消息，并发现哪些znode的修改被自己错过了。那么至少在下一次发生修改配置后，client能够完全与当前配置一致。
　　我们可以写一个场景验证下：
　　初始时/group/policy下为空，/group/policy的stat为(mzxid=2,dataversion=0)
    current_dataversion=0；
    current_zxid=2
1)create /group/policy/n1(mzxid=3,dataversion=0) 收到通知 current_dataversion+=1 (等于1)
2)set /group/policy (mzxid=4,dataversion=1) 收到通知 curren_dataversion==/group/policy.dataversion，没有漏掉通知
                                                      current_zxid=/group/policy.mzxid (等于4)
情形一)                                                     
3.1) create /group/policy/n2 (mzxid=5,dataversion=0) 没有收到通知 current_dataversion不变（等于1）
4.1）set /group/policy (mzxid=6,dataversion=2) 收到通知 current_data < /group/policy.dataversion,得知漏掉了通知，并且知道漏掉1个
                                                         同步mzxid大于current_zxid(值为4)的节点（即n2节点）配置；
                                                         删除已经不存在znode的配置；
                                                         current_data = /group/policy.dataversion （等于2）
                                                         current_zxid = /group/policy.zxid (等于5)
  情形二)
  3.2)create /group/policy/n2(mzxid=5,dataversion=0) 收到通知 current_dataversion+=1 (等于2)
  4.2）set /group/policy (mzxid=6,dataversion=2)  没有收到通知  current_zxid(=4)不变。漏掉该消息是没有关系的，再次收到该消息时，会更新current_zxid
  情形三)
  3.3)create /group/policy/n2(mzxid=5,dataversion=0) 没收到通知 current_dataversion不变（等于1）
   4.3）set /group/policy (mzxid=6,dataversion=2)  没有收到通知   current_zxid(=4)不变。
   5)create /group/policy/n3(mzxid=7,dataversion=0) 收到通知 current_dataversion+=1 (等于2)
   6)set /group/policy (mzxid=8,dataversion=3)   收到通知    current_data < /group/policy.dataversion 得知漏掉了通知
                                                              同步mzxid大于current_zxid(值为4)的节点（即n2，n3节点）配置；
                                                              删除已经不存在znode的配置；
                                                              current_data = /group/policy.dataversion （等于3）
                                                              current_zxid = /group/policy.zxid (等于8)　　通过这种方式，可以让client端知道自己错过了通知，至少在下次收到/group/policy节点更新通知时，能够重新同步配置。因此可以保证client之间迟早会变得同步。
　　更进一步，可以额外再增加时钟来触发对/group/policy节点的检查。这样就可以保证一个时钟间隔之后，client肯定是同步的。