其实我们发现在我们本地新生成了文件,这个文件就是nacos;
这个文件怎么那么眼熟,不就是我们的controller中的注解里面的参数value么;
@Controller @NacosPropertySource(dataId = "springboot2-nacos-config", autoRefreshed = true) public class HealthController { @Autowired private String healthString;
@NacosValue(value = "${nacos.test.propertie:123}", autoRefreshed = true)
private String testProperties;
这个文件的内容我们看看呢
还真是跟我们的注解value的key是一样的,我们在nacos中每做一次修改这个值都会关联的改动,
而且我们直接把这个值改了,显示的依然还是nacos中的值,所以我们可以大胆预测,nacos修改配置值之后会联动改配置文件中的值,
但是取值还是根据缓存中的值来的,可能就是某个map或者其他的存储形式,肯定我们是在哪里漏了,我们继续go
其实,这块代码我们有看到过,只不过没有在意,上代码:
static public boolean dump(String dataId, String group, String tenant, String content, long lastModifiedTs) { String groupKey = GroupKey2.getKey(dataId, group, tenant); makeSure(groupKey); final int lockResult = tryWriteLock(groupKey); assert (lockResult != 0); if (lockResult < 0) { dumpLog.warn("[dump-error] write lock failed. {}", groupKey); return false; } try { final String md5 = MD5.getInstance().getMD5String(content); if (md5.equals(ConfigService.getContentMd5(groupKey))) { dumpLog.warn( "[dump-ignore] ignore to save cache file. groupKey={}, md5={}, lastModifiedOld={}, " + "lastModifiedNew={}", groupKey, md5, ConfigService.getLastModifiedTs(groupKey), lastModifiedTs); } else if (!STANDALONE_MODE || PropertyUtil.isStandaloneUseMysql()) { DiskUtil.saveToDisk(dataId, group, tenant, content); } updateMd5(groupKey, md5, lastModifiedTs); return true; } catch (IOException ioe) { dumpLog.error("[dump-exception] save disk error. " + groupKey + ", " + ioe.toString(), ioe); if (ioe.getMessage() != null) { String errMsg = ioe.getMessage(); if (NO_SPACE_CN.equals(errMsg) || NO_SPACE_EN.equals(errMsg) || errMsg.contains(DISK_QUATA_CN) || errMsg.contains(DISK_QUATA_EN)) { // 磁盘写满保护代码 fatalLog.error("磁盘满自杀退出", ioe); System.exit(0); } } return false; } finally { releaseWriteLock(groupKey); } }
上面标红的代码就是把我们跟新的配置存储到文件里面去;好了 一个闭环的来龙去脉基本清楚了,至于里面很多的其他逻辑
我感觉都是后面迭代打补丁上去的,主干的东东就这么多了;下面我们继续看,因为我们这个nacos跟client都是在windows下debug的
究竟保存的文件是保存到客户端还是nacos的,其实自己仔细想想应该就能知道了,嘿嘿,先卖个关子,下集我们继续,go!!