背景
我们项目是集群部署的，通过DUBBO注册到Zookeeper上。
对于一些配置值，会在项目启动后会从数据库查询并加载到各主机缓存中。现在存在这样的问题，当A主机修改了该配置值并更新对应缓存后，如何同步修改到其他主机？我们的解决方案是利用Zookeeper的统一配置管理功能来实现。
Zookeeper介绍
Zookeeper是一个开源的分布式的，为分布式框架提供协调服务的Apache项目
工作机制
Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架——它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
特点
- Zookeeper：一个领导者（Leader），多个跟谁者（Follower）组成的集群
- 集群中只要有半数以上节点存活，Zookeeper集群就能正常服务，所以Zookeeper适合安装奇数台服务器。
- 全局数据一致：每个Server保存相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
- 更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行。
- 数据更新原子性，一次数据更新要么成功，要么失败。
- 实时性，在一定时间范围内，Client能读到更新数据。
数据模型
Zookeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。
每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。
节点分类
1）临时节点（EPHEMERAL） ：session链接断开就没了；不能创建子节点；不能同名
2）临时顺序节点（EPHEMERAL_SEQUENTIAL） ：session链接断开就没了；不能创建子节点；同名节点会在后面添加上序号（分布式锁使用的好处）
3）持久节点（PERSISTENT）：session断联、服务端重启还在；可以创建子节点，子节点可以临时也可以持久；不能同名
4）持久顺序节点（PERSISTENT_SEQUENTIAL）：session断联、服务端重启还在；可以创建子节点，子节点可以临时也可以持久；同名节点会在后面添加上序号
应用场景
统一命名服务，统一配置管理，统一集群管理，服务器节点动态上下线，软负载均衡等
统一命名服务
在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。
统一配置管理
1）分布式环境下，配置文件同步非常常见。
（1）一般要求一个集群中，所有节点的配置信息是一致的，比如Kafka集群。
（2）对配置文件修改后，希望能够快速同步到各个节点上。
2）配置管理可交由Zookeeper实现。
（1）可将配置信息写入Zookeeper上的一个Znode。
（2）各个客户端服务器监听这个ZNode。
（3）一旦Znode中的数据被修改，Zookeeper将通知各个客户端服务器。
服务器动态上下线
软负载均衡
ZK在缓存一致中的应用思路
为了解决前面提到了集群部署下缓存更新不一致的问题，我们利用Zookeeper的统一配置管理特性，来实现缓存更新一致。
配置项缓存第一次加载时，先注册一个永久节点（ZkClient.createPersistent），再注册一个监听（ZkClient.subscribeDataChanges，监听永久节点的数据变化）。当主机A进行了缓存更新后同时对ZNode中的对应数据进行变更，其他ZNode监听到后，就对本机具体的配置值进行缓存更新就可以保证整个集群缓存一致了。