最近做项目，需要用到数据同步，对该项目同步模块描述如下：
web服务器共20台，这些服务器上的web站点上有很多.config配置文件，都是部署在服务器本地的，这些配置与站点是1对1的关系，对站点管理比较灵活，但随之也带来问题，每次更新配置要对20台服务器进行.config文件进行修改，将来不排除再添加web服务器的可能，显然这样的重复工作量很大，我又比较懒，为解决这个问题，决定开发定制的数据同步服务，来解决这个问题。
对该服务技术框架上有两种方案，描述如下：
两种方案共同点：
1），配置管理均为树结构
2），配置管理可分为主从配置
3），配置服务器端，设置配置管理存储媒介，如：db，文件，NOSQL。
以下是区别方案描述如下：
方案A:分发订阅式同步
1），配置服务器端，启动主线程监听对配置的变动，发现变动即时创建多子个线程，对变动的配置分发到各个web服务器上去，
分发过程中如果出现异常，则尝试多次分发到失败的web服务器上，直到获得web服务器响应。
3），web服务器接到数据即时刷新对应业务对象即可。
方案B：主动轮询式同步
1），web服务端定时向配置服务器发出请求，获取配置数据，配置服务器发现配置有变动即给出响应即可
以上两种方案均可实现同步，个人认为：
方案A，对配置服务器自身来说没有压力，因为没有来自web服务器的频繁请求，从而也不需要处理来自web服务器请求并发，在分发过程中是多线程实现的，也没有压力，这样配置服务端编程及维护难度降低；
方案B，配置服务器定时（一般以秒为单位）要接受来自web服务器的请求，显然对并发有要求了，在配置服务端无疑要出现锁了，配置文集变动很少变动或者几个月甚至一年变动一次，那web服务端的请求配置服务器时间间隔不好确定，再者，如果这个服务扩张了要给多个业务使用，那么配置服务器无疑压力更大了，这时候恐怕就要添加服务器来负载了，反观方案A，什么时候配置变动什么时候分发，不存在web服务器请求（频繁）的问题，这样服务器是没有压力的，一台机器即可搞定。
以上是我对这两种数据同步方案的见解，希望看到这篇文章的GG，MM们拍砖，发表你的高见，在下不甚感激。
