在上篇博客中,介绍了zookeeper客户Curator对监听事件的封装及应用——《Zookeeper开源客户端Curator之事件监听详解》在讲解部分代码实例的运行结果时我们已经注意到,并不是所有的监听事件都会发送到客户端。比如连续更改一个节点的内容、创建节点再马上删除节点。本篇博客就讨论一下zookeeper监听事件丢失的原因及使用时的注意事项。
package com.secbro.learn.curator;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.cache.NodeCache;
import org.apache.curator.framework.recipes.cache.NodeCacheListener;
import org.apache.curator.retry.ExponentialBackoffRetry;
/**
* Created by zhuzs on 2017/4/15.
*/
public class CuratorNodeCacheTest {
public static void main(String[] args) throws Exception {
CuratorFramework client = getClient();
String path = "/p1";
final NodeCache nodeCache = new NodeCache(client,path);
nodeCache.start();
nodeCache.getListenable().addListener(new NodeCacheListener() {
@Override
public void nodeChanged() throws Exception {
System.out.println("监听事件触发");
System.out.println("重新获得节点内容为:" + new String(nodeCache.getCurrentData().getData()));
}
});
client.setData().forPath(path,"456".getBytes());
client.setData().forPath(path,"789".getBytes());
client.setData().forPath(path,"123".getBytes());
client.setData().forPath(path,"222".getBytes());
client.setData().forPath(path,"333".getBytes());
client.setData().forPath(path,"444".getBytes());
Thread.sleep(15000);
}
private static CuratorFramework getClient(){
RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000,3);
CuratorFramework client = CuratorFrameworkFactory.builder()
.connectString("127.0.0.1:2181")
.retryPolicy(retryPolicy)
.sessionTimeoutMs(6000)
.connectionTimeoutMs(3000)
.namespace("demo")
.build();
client.start();
return client;
}
}
执行结果:
监听事件触发
重新获得节点内容为:123
监听事件触发
重新获得节点内容为:333
监听事件触发
重新获得节点内容为:444
重复执行多次打印结果不同,但最后一个都会打印出“444”这个内容。
前面的章节已经提到zookeeper原生API注册Watcher需要反复注册,即Watcher触发之后就需要重新进行注册。另外,客户端断开之后重新连接到服务器也是需要一段时间。这就导致了zookeeper客户端不能够接收全部的zookeeper事件。zookeeper保证的是数据的最终一致性。因此,对于此问题需要特别注意,在不要对zookeeper事件进行强依赖。
zookeeper的getData(),getChildren()和exists()方法都可以注册watcher监听。而监听有以下几个特性:
Zookeeper 客户端和服务端是通过 Socket 进行通信的,由于网络存在故障,所以监视事件很有可能不会成功地到达客户端,监视事件是异步发送至监视者的,Zookeeper 本身提供了保序性(ordering guarantee):即客户端只有首先看到了监视事件后,才会感知到它所设置监视的 znode 发生了变化(a client will never see a change for which it has set a watch until it first sees the watch event). 网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件,但是不同的客户端所看到的一切具有一致的顺序。
Watch由client连接上的ZooKeeper服务器在本地维护。这样可以减小设置、维护和分发watch的开销。当一个客户端连接到一个新的服务器上时,watch将会被以任意会话事件触发。当与一个服务器失去连接的时候,是无法接收到watch的。而当client重新连接时,如果需要的话,所有先前注册过的watch,都会被重新注册。通常这是完全透明的。只有在一个特殊情况下,watch可能会丢失:对于一个未创建的znode的exist watch,如果在客户端断开连接期间被创建了,并且随后在客户端连接上之前又删除了,这种情况下,这个watch事件可能会被丢失。
对于watch,ZooKeeper提供了这些保障:
经过上面的描述,对于上一篇博客中连续修改节点内容部分监听事件丢失的原因也就变得显而易见了。虽然curator帮开发人员封装了重复注册监听的过程,但是内部依旧需要重复进行注册,而在第一个watcher触发第二个watcher还未注册成功的间隙,进行节点数据的修改,显然无法收到watcher事件。感兴趣的朋友可以在上篇博客中找到源码,测试一下。
zookeeper 丢失事件/miss event zookeeper之监听事件总结