在web项目中都会有一些配置信息，如appkey、IP白名单等。这些配置信息数量少，一般会保存到内存、文件或者数据库。有的时候需要动态更新这些配置。当需要在多个应用服务器中修改这些配置文件的时候，需要做到快速、简单、不停止应用服务器的方式修改并同步配置信息到所有应用中去。

可用的的web集群配置方案

• 将配置信息保存在程序代码中，这种方式非常简单，但是每次更新配置的时候都要修改该代码，重新编译，部署应用。显然这个方案很不方便，也不可靠，无法做到袖带的实时生效。对于某些业务需要频繁的修改配置，这样就很不合适了。
• 将配置信息保存在属性文件中。当需要修改配置的时候，直接修改属性文件，这样不需要重新编译，只需要重新部署修改的文件按即可。这个方案如果集群内的机器非常多的话，这简直就是一个噩梦。
• 将配置信息保存在数据库中，或者再从数据库加载到缓存中，当需要修改配置的时候，直接修改数据库，如果还同时使用了缓存的话，需要再将更新后的配置加载到缓存中，这种做法比上面那种要简单，但是面临着单点失效问题。如果数据库宕机了，就不能更新配置。

基于Zookeeper的集群配置管理方案

直接将配置信息保存在Zookeeper中，或者把属性文件内容保存到Zookeeper，当属性文件内容发生变化时，就通知web应用去重新读取配置文件。

这里采用的是Zookeeper的发布与订阅模式，就是发布者将数据发布到Zookeeper的节点上，供订阅者获取数据，实现配置信息的集中式管理和动态更新。使用场景：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从而获取最新的配置信息。这样的场景适合数据量很小，但是数据更新可能比较快的需求。

基于Zookeeper的集群配置管理方案优点

借助Zookeeper实现的配置信息管理方案有如下优点：

1. 简单。修改配置的整个过程变的非常简单，用户只需要修改配置，无需进行其他任何操作，配置自动生效
2. 可靠。Zookeeper服务集群具有无单点失效的特性，使整个系统更加可靠。即使Zookeeper集群中的一台机器失效，也不会影响整体服务，更不会影响应用配置的更新
3. 实时。Zookeeper的数据更新通知机制，可以在数据发生变化后，立即通知给分布式应用程序，具有很强的变化响应能力。