场景描述：

发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。

使用ZooKeeper的发布与订阅模型，可以将应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取新配置信息的目的。这样的场景适合数据量很小，但是数据更新可能会比较快的需求。

传统配置方案：

1. 将配置信息保存在程序代码中

这种方案简单，但每次修改配置都要重新编译、部署应用程序。显然这种方案很不方便，也不可靠，更无法做到修改的实时生效。

2. 将配置信息保存在xml文件或者属性文件中

在参数信息保存在xml或者属性文件中，当需要修改参数时，直接修改 xml 文件。这样无需重新编译，只需重新部署修改的文件即可。但然后对所有的应用进行重新部署。这样做的缺点显而易见，要往上百台机器上重新部署应用，简直是一个噩梦。同时该方案还有一个缺点，就是配置修改无法做到实时生效。修改后往往过一段时间才能生效。

3. 将配置信息保存在数据库中

当需要修改参数时，直接修改数据库，然后重启分布式应用程序，或者刷新分布式应用的缓存。尽管这种做法比以上两种方案简单，但却面临着单点失效问题。如果数据库服务器停机，则分布式应用程序的配置信息将无法更新。另外这种方案的配置修改生效实时性虽然比第二种方案好些，但仍然不能达到某些情况下的要求。

基于Zookeeper的配置方案：

同一个应用系统需要多台 PC Server 运行，但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的配置项，那么就必须同时修改每台运行这个应用系统的 PC Server，这样非常麻烦而且容易出错。将配置信息保存在 Zookeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。

Zookeeper很容易实现这种集中式的配置管理，比如将所需要的配置信息放到/Configuration 节点上，集群中所有机器一启动就会通过Client对/Configuration这个节点进行监控【zk.exist("/Configuration″,true)】，并且实现Watcher回调方法process()，那么在zookeeper上/Configuration节点下数据发生变化的时候，每个机器都会收到通知，Watcher回调方法将会被执行，那么应用再取下数据即可【zk.getData("/Configuration″,false,null)】。

参考文献：（1）《从paxos到zookeeper》（2）http://www.mamicode.com/info-detail-1164032.html