1 场景描述
参考http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/index.html，实现自己的集中配置管理系统。
术语：配置管理（Configuration Management）
一个带配置的服务程序，部署在若干台机器上，如果配置发生了变化，接下去要进行的操作是停止所有机器上的该程序，修改每一台机器上该程序对应的配置文件。
这个情景会有两个问题：第一，机器多了，逐个修改配置是一件不合理的运维；第二，配置一般是程序启动时读入的，所以配置修改后，程序应该重启。
配置管理在某些场合称“数据发布与订阅”，顾名思义就是将数据发布到zk节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。
实际应用环境：
1. 索引信息和集群中机器节点状态存放在zk的一些指定节点，供各个客户端订阅使用。 2. 系统日志（经过处理后的）存储，这些日志通常2-3天后被清除。
3. 应用中用到的一些配置信息集中管理，在应用启动的时候主动来获取一次，并且在节点上注册一个Watcher，以后每次配置有更新，实时通知到应用，获取最新配置信息。
4. 业务逻辑中需要用到的一些全局变量，比如一些消息中间件的消息队列通常有个offset，这个offset存放在zk上，这样集群中每个发送者都能知道当前的发送进度。
5. 系统中有些信息需要动态获取，并且还会存在人工手动去修改这个信息。以前通常是暴露出接口，例如JMX接口，有了zk后，只要将这些信息存放到zk节点上即可。
2 需求概括
a）解决服务程序统一配置的问题；
b）解决服务配置更改的热加载问题；（热加载：程序更改配置，不需重启就能快速响应）
3 技术原理
利用zookeeper的特性（略），将配置信息保存在 Zookeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。
a）znode的路径作为配置项能做到全局唯一；
b）znode的内容作为配置项的值，始终存在与内存中，方便读取；
c）znode的权限作为项目之间的配置隔离机制，可以做到项目配置的安全管理；
zookeeper拥有的特性使得配置的存储、读取、监听（watch）等都很好地实现，我们所需要做的事情——开发一个统一的控制终端以及提供程序读取配置的接口。
a）集中的Web控制终端：包含配置信息增加、删除、修改、查询、部署等等；
b）Java读取配置项的类和接口；
c）C++读取配置的类和接口；
4 体系结构
5 配置存储结构
3 层，存xml文件的字符串。
5 优势
a）配置统一管理，方便运维；
b）服务程序热加载；
c）配置分布式存储，稳定可靠；
6 实现
功能类ConfMng提供载入xml配置文件到zk系统的函数和读取配置map的函数，并提供一个需要用户实现的抽象函数
// 解析xml将keyvalue存入Map
abstract public Map<?, ?> parserXML();
用户程序使用方法如下：
继承ConfMng类，实现parserXML();接口
读取配置内容。
原则：设计的集中配置管理类，将读取配置xml的方法开放给用户，做到配置的通用；竟可能在原程序基础上做到无缝结合。
来源：oschina
链接：https://my.oschina.net/u/137649/blog/282051