关于zk的watcher
ZooKeeper允许客户端向服务端注册一个Watcher监听，当服务端的一些事件，比如节点更新，删除，增加。触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。
Watcher机制注意点
-
zk原生提供的watcher通知是一次性的，必须重复注册
这点可以通过Curator来改善，Curator是什么呢？我们来看看Zookeeper 的核心提交者 Patrick Hunt 对Curator的高度评价。
“Guava之于Java就是Curator之于Zookeeper”，我觉得这句话也很好的解释Curator是什么。Curator是Netflix公司开源的一套zookeeper客户端框架，解决了很多Zookeeper客户端非常底层的细节开发工作。其中就包括了对于注册监听操作的反复注册，也就是watcher通知后Curator能做到自动重新注册，这样就改善了watcher通知的一次性。还支持三种缓存监听，功能强大，感兴趣的小伙伴可以去了解一下。 -
节点数据的版本变化也会触发节点数据改变的方法（NodeDataChanged）
也就是说只要setData被执行，无论是否是set了新的值，也就是哪怕更改的内容和之前是一致的，都会触发这个wathcer -
一个watch对象或一个函数/上下文对，为一个事件只会被通知一次。
比如，如果同一个watch对象在同一个文件上分别通过exists和getData注册了两次，而这个文件之后被删除了，这时这个watch对象将只会收到一次通知。即
Watcher对象只会保存在客户端，不会传递到服务端。 -
很重要的一点：Zookeeper不能保证每一次节点的的变化都能成功反馈给客服端。
这是什么意思呢?其实就是一个数据库一致性的问题。我们先来分析一下原因。
我们来分析一下这个流程，主要是一个红色线条地方。当数据发生修改后，通知到客户端，客户端接收到数据，然后再次注册watch到zk，很明显这个流程中其实是有一个空档的。也就是说这个过程并没有watch去监听到zk节点的数据变化。如果在这个时候zk节点的数据发生了变化。那么这个修改对于客户端来说是不可见的。也就是这个数据修改客户端并没有感知和接收到。甚至在这个过程中zk的数据还可能发生了多次的修改。所以，Zookeeper并不能保证每一次节点的变化都能够通知到客户端。
谈谈Zookeeper作为配置中心
再说说一个比较冷门的微服务结构。用zk来做微服务架构的配置中心。配置中心的作用我在这就不过多做出阐述。感兴趣的同学可以去了解一下（不然后面可能有点难懂），其实引入微服务的各种概念无非就是要解决某些问题。配置中心其实就是解决了配置管理的问题。
相关依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zookeeper-config</artifactId>
</dependency>
我们先来看看官方文档对于zookeeper-config的介绍：
Zookeeper provides a hierarchical namespace that lets clients store arbitrary data, such as configuration data.Spring Cloud Zookeeper Config is an alternative to the Config Server and Client .
说人话：Zookeeper提供了一个 分层的名称空间 ，该名称空间使客户端可以存储任意数据，例如配置数据。Spring Cloud Zookeeper Config是Config Server和Client的替代方法 。
这个介绍其实已经很清晰了。我们看到最后一句zk config是一种替代方法。说明他还是有很多不足。
zk config原理分析：源码就不贴了，其实看起来也不算困难。我来口述一下吧。zk作为配置中心，他的一个原理就是zk的节点是可以存储数据的，我们可以把配置文件存在zk的节点中，然后客户端对节点注册watch监听，当然源码中用到了Curator封装的方法注册了监听，采用了缓存监听中TreeCache的方式（对于节点和子节点的数据变化都能感知到）对于存配置文件的节点注册了监听。然后zk节点上的配置文件一发生变化，客户端就能感知并接受到数据。这个过程是不是很熟悉。问题随之而来。
聪明的小伙伴们肯定马上就想到问题所在了吧。上文中提到了：Zookeeper不能保证每一次节点的的变化都能成功反馈给客服端。这样zk config的方式做配置中心就可能存在数据丢失的问题。从而导致配置文件的分发失败。
但就我个人而言，我觉得不是很庞大的系统的话，又是zk做注册中心的微服务架构的话。zk config真的非常非常非常方便和简易。其实我们想想就知道。配置中心配置文件的发布都是我们人为的一个过程。是可操控的，是由开发者指定。所以上面提到的问题其实是可以避免的。只要不接连的连续的多次更改配置文件，配置中心不快速连续多次的发布配置文件。那么zk config这种替代方案，还是非常的香的。
以上只是个人学习中一些感悟与分享，如有错误欢迎指正与交流。