也就是在nacosConfigService类中getConfigInner方法中使用了LocalConfigInfoProcessor.getFailover方法; 而这个方法在配置刷新之后,server端反馈给client端,最后调用spring的刷新机制,spring最后又会调用nacos-client的getConfig方法,在这里本来不应该再去请求server端了,因为之前nacos-client端已经请求过server,得到变更的配置并且更新仔本地文件中,我认为这里的LocalConfigInfoProcessor.getFailover(worker.getAgentName(), dataId, group, tenant) getFailover是废弃方法,它根本拿不到本地文件的最新配置,导致又请求了nacos-server,没有必要多做这一次请求,所以我觉得这里应该调用getSnapshot方法来获取本地最新的content然后直接返回
`private String getConfigInner(String tenant, String dataId, String group, long timeoutMs) throws NacosException { group = blank2defaultGroup(group); ParamUtils.checkKeyParam(dataId, group); ConfigResponse cr = new ConfigResponse();
cr.setDataId(dataId);
cr.setTenant(tenant);
cr.setGroup(group);
************************************** **************************************
**// i think this can not use getFailover,it need use getSnapshot.
//Otherwise, the local config will not be used here, and the server will always be requested. //This will cause the client to request the server twice when refreshing the configuration. //And there is no savefailover,so I guess the code here is your careless mistake.**
**String content = LocalConfigInfoProcessor.getFailover(worker.getAgentName(), dataId, group, tenant);**
if (content != null) {
LOGGER.warn("[{}] [get-config] get failover ok, dataId={}, group={}, tenant={}, config={}",
worker.getAgentName(), dataId, group, tenant, ContentUtils.truncateContent(content));
cr.setContent(content);
String encryptedDataKey = LocalEncryptedDataKeyProcessor
.getEncryptDataKeyFailover(agent.getName(), dataId, group, tenant);
cr.setEncryptedDataKey(encryptedDataKey);
configFilterChainManager.doFilter(null, cr);
content = cr.getContent();
return content;
}
try {
ConfigResponse response = worker.getServerConfig(dataId, group, tenant, timeoutMs, false);
cr.setContent(response.getContent());
cr.setEncryptedDataKey(response.getEncryptedDataKey());
configFilterChainManager.doFilter(null, cr);
content = cr.getContent();
return content;`
原提问者GitHub用户kangarooking
1、getFailover 并不是废弃方法,而是提供在配置中心失联的紧急情况下的干预手段。Failover是用于容灾的,如果出现客户端和服务端完全无法通信,但又需要修改配置的时候,手动创建failover目录及对应dataid配置内容。
2、getSnapshot 并不是用来获取最新的配置,而是提供在配置中心失联的情况下的,人工的 容灾干预是滞后的,这个时候客户端至少还可以从snapshot中获取旧的配置,而不至于直接报错罢工。
3、getConfig方法每一次都会请求nacos-server,这是合理的,在配置中心正常工作的情况下,该方法获取到的配置可以确认一定是最新可靠的。
4、如果不想因为每一次获取配置都去请求nacos-server造成配置中心压力过大,应该使用监听的方式。这样客户端只会在启动的时候访问一次nacos-server,之后依赖配置中心的主动推送异步更新配置,而不是每一次用到配置了就去发起请求。
原回答者GitHub用户MajorHe1
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践,通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式,助力制造业企业高效上云,实现系统稳定、应用敏捷智能。拥抱云原生,让创新无处不在。