zookeeper的基本概念和作用这里不做介绍，现在很多的公司都在使用它，说起它的作用，可能最先想到的是配置中心，可以将配置项作为一个node存储在zookeeper中，其他应用可以“关注”这个节点，当配置的值发生变化的时候，其他应用可以很快的被通知到。
这里有一个细节，就是通知的次数，我在初次认识zookeeper的时候，以为“关注”了某个节点后，之后这个节点的值发生变化都可以通知到，但是实际情况是客户端在“关注”了某个节点后，这个节点的首次变化会被通知到，之后的变化都不会再通知，如果想得到之前的变化，需要在首次变更通知到后，再次“关注”这个节点，也就是说，zoookeeper中的“关注”通知是一次性的，类似于Web中Request/Response。
基于这种情况，zookeeper的Java客户端Curator做了一定的优化，但是.Net还没有，基于此，我写了一个zookeeper Watch的帮助类，可以实现“一次关注，多次通知”。
ZookeeperWatchHelp的核心很简单，就是在"关注"了某个节点后，当节点发生变更，通知到应用程序后，立刻再次"关注"，之后才执行变更的处理程序。
目前代码已经开源，地址是：https://github.com/zhaoyb/ZookeeperWatcherHelp
之前的配置中心是基于心跳的，当配置发生变化，并不能立刻通知到客户端，对于某些应用场景可能不适用，所以升级为zookeeper版本。
zookeeper版本的核心思想： 将应用Id(AppId)作为一个node存入到zookeeper中，node的data是应用的版本号，修改配置的时候，除了修改应用的版本号，还要修改zookeeper中对用node的data。 客户端在启动的使用，注册对指定节点数据变更的关注，当节点的值发生变化，会通知到客户端，客户端请求服务端拉取最新的配置。
在启动的时候，主动创建一个节点，作为配置中心的根节点。
在配置发生变化的时候，处理更新版本号，还要更新zookeeper中对应节点的data。节点的名称就是应用的名称。
客户端的启动方式和之前类似
在启动的时候，首先会实例化zookeeper对象，需要zookeeper服务器的host和port，这些其实也是配置，所以会到服务端指定的应用下面获取配置(这些配置需要事先配置好)，在拉取到zookeeper的配置后，实例化zookeeper配置，并注册关注。
zookeeper的客户端本身具有重连机制，所以当某个服务器宕机，会自动重连到另外的机器，这些对上层应用来说是透明的，但是为了保证高可用，还是做了一个降级处理，就是会每隔20秒钟(这个时间可以更长）主动到服务端校验一次版本号。