Curator之PathChildrenCache的那些坑
好久没来了,一是在研究Zookeeper没时间,二是个人感觉没啥干货。zookeeper号称是最好的配置管理服务器,最近平台准备将集群的配置信息迁移到上面,做成无状态集群。其客户端基本都使用Curator作为包装,简便使用。Curator能操作选举、分布式锁、服务发现、节点变动监听等非常简便的操作。目前想法是集群中每个节点启动时,都注册到ZKServer上,然后每个节点都接收节点改变的监听,以便每
好久没来了,一是在研究Zookeeper没时间,二是个人感觉没啥干货。
zookeeper号称是最好的配置管理服务器,最近平台准备将集群的配置信息迁移到上面,做成无状态集群。
其客户端基本都使用Curator作为包装,简便使用。
Curator能操作选举、分布式锁、服务发现、节点变动监听等非常简便的操作。
目前想法是集群中每个节点启动时,都注册到ZKServer上,然后每个节点都接收节点改变的监听,以便每个节点都实时更新集群信息(其他应用要使用)
监听使用PathChildrenCache,能监听当前目录+子节点。
我的操作流程是:
节点启动时,首先初始化ZK上的节点信息,并且判断相关节点是否失效(ZK默认30秒才失效,而我的服务器可能在30秒内再次启动,导致Session节点在启动后失联,每次判断失效都要删除原来的session节点)。
这个过程,不能发送监听事件,因为可能为频繁删除,导致过多事件。
当时以为PathChildrenCacheListner的start时,才会监听之后的数据,结果数据混乱,没有规律,明显我只改动一个节点,却发送多个节点改变的事件。
查了半天才发现,是PathChildrenCache的start需要传入参数,如果不传,则初始会把监听节点的所有存在的节点都作为节点改变,发出事件
WTF
增加传入参数PathChildrenCache.StartMode.BUILD_INITIAL_CACHE后,问题解决
看来,仔细研究原API、相关例子很重要。。。
更多推荐
所有评论(0)