Nacos源码分析-更新配置时服务端做了什么

在 Nacos console 修改了配置以后，服务端底层怎么存储配置？客户端怎么知道配置修改了？怎么通知集群其他节点？让我来揭开它神秘的面纱。

服务端接收配置更新请求

在控制台页面更新一项配置，看看控制台发送了什么请求给服务端。

控制台发送了一个 POST 请求：/nacos/v1/cs/configs，在官方 API指南可以找到 API 定义。

我 Nacos 源码是 2.* 版本，但是打开的 console 发布配置请求的 API 还是 1.* 版本。
官方说v2 是兼容 v1 的，在源码的 Controller 层面两个版本使用的也是相同的 Service 类处理请求。

请求进入com.alibaba.nacos.config.server.controller.ConfigController#publishConfig，封装配置和请求信息后调用ConfigOperationService#publishConfig。

publishConfig方法做了两件事：

ConfigDataChangeEvent被两个类监听：

DumpService在构造函数中订阅了ConfigDataChangeEvent事件，当监听到事件发生，调用handleConfigDataChange方法。

我回看了一下前面的文章，一些不重要的方法也有截图，白白的浪费了大家的阅读时间，对于简单的方法后面只会列出方法调用链路

👇handleConfigDataChange(Event event)
👇dumpFormal(String dataId, String group, String tenant, long lastModified, String handleIp)

dumpFormal方法作用是转存正式数据到本地磁盘和缓存，向任务管理器dumpTaskMgr提交了一个任务DumpTask。

dumpTaskMgr是TaskManager实例，在DumpService的构造函数中创建了该实例，并且为它指定了DumpProcessor作为默认任务处理器

TaskManager类本身没有实现执行任务的方法，而是继承自 NacosDelayTaskExecuteEngine, 来看下他是如何执行任务的。

在构造函数中创建单线程执行器，确保任务都能处理成功，并且每个任务之间间隔 100 毫秒。

执行器会一直执行ProcessRunnable，ProcessRunnable实现了Runnable接口，在run方法内调用processTaks方法处理任务

通过 taskKey 获取NacosTaskProcessor类型的处理器，调用处理器的process方法处理任务。这里实现了任务重试机制，如果执行失败则放入队列稍后执行。

NacosTaskProcessor是一个处理器接口，他有很多实现，分别用来处理不同的任务

dump 正式数据的任务则是由上面指定的默认任务处理器DumpProcessor来处理。

调用处理器的的process方法处理任务：

👇process(NacosTask task)
👇DumpConfigHandler.configDump(build.build())
👇ConfigCacheService.dump(dataId, group, namespaceId, content, lastModified, event.getType(), event.getEncryptedDataKey())
👇dumpWithMd5(dataId, group, tenant, content, null, lastModifiedTs, type, encryptedDataKey)
👇ConfigDiskServiceFactory.getInstance().saveToDisk(dataId, group, tenant, content)

调用saveToDisk方法保存到磁盘；updateMd5方法更新本地缓存的 md5和最后更新时间，并发布LocalDataChangeEvent事件。