配置中心集群数据量过大时，拉取全量配置，timeout，带宽不够用

[yomea]

代码位置： com.junmo.center.core.CenterClusterManager#start public static void start() throws InterruptedException { // get cluster alive node Set<String> aliveNodes = inquire(); // init cluster channel for (String aliveNode : aliveNodes) { joinCluster(aliveNode); } // sync init config for (String aliveNode : aliveNodes) { loadConfig(aliveNode); } }

加载配置方法： private static void loadConfig(String ip) throws InterruptedException { ClusterCenterConnector clusterCenterConnector = ALL_HISTORY_CLUSTER_MAP.get(ip); DaoMessage daoMessage = new DaoMessage((byte) 0, MessageType.INQUIRE_CLUSTER_FULL_CONFIG_REQUEST_MESSAGE, MainProperties.serialize, new ConfigMarkModel()); Promise<FullConfigModel> promise = new DefaultPromise<>(clusterCenterConnector.getChannel().eventLoop()); PullConfigResponseHandler.promise = promise; clusterCenterConnector.getChannel().writeAndFlush(daoMessage).addListener(future -> { if (!future.isSuccess()) { log.error("send full config data error", future.cause()); } }); if (!promise.await(8, TimeUnit.SECONDS)) { log.error("<<<<<<<<<<<<<< get full config data timeout >>>>>>>>>>>>>>"); throw new DaoException("promise await timeout"); } if (promise.isSuccess()) { List<ConfigModel> configModels = promise.getNow().getConfigModels(); for (ConfigModel configModel : configModels) { persistence.storage(configModel); } } else { throw new DaoException(promise.cause()); } }

建议： 不要循环拉取所有节点配置，在配置相同的副本情况下，做了很多无用功，另外配置数据量大时，这全量拉取容易导致带宽不够用，如果该网段还有其他的应用，此时几乎都要瘫痪，直至timeout

按照当前的架构设计，本身就是弱一致性，比如只更新某个节点的配置，而且是通过拷贝文件的方式，这个文件的存储结构可以自己好好设计下，减少体积

[Suzzt]

有关这个设计是根据场景来设定的！如果按包的拷贝的就会加大部署的繁琐，与本项目的意义违背原意，还有一个因素就是你这时候不知拷贝哪一个节点文件了，可能会加大导致整个配置信息不一致的概率！！。你说的场景可能存在，配置文件信息很大，但是这个框架本身就是轻量级设定的，处于场景不考虑处理该问题了，还有巨大配置信息是否有必要放在配置中心呢？

[yomea]

啥巨大配置，就是配置的数据很多，通常用户就一个配置中心，给多个应用使用，特别是项目多的公司，而且你这个是多个节点循环复制，其速度，性能可想而知，框架轻量不代表数据轻量，你说的不知道拷贝哪个，我是基于你目前的架构设计来的，它就是一个弱一致性，就算是redis哨兵模式，在拷贝时候虽然选择了一个数据量最全，最稳定的节点，在拷贝的那一刻也不能保证是完全一致的，毕竟网络环境什么都会变，你要做到最终一致就可以