nacos的配置中心--服务端
1.1:概述
Nacos Config提供了配置管理的功能，它允许用户在nacos上配置key-value对，并在客户端订阅需要的配置。当配置发生变更时，订阅的客户端会获得通知，随后拉取最新的key-value对。
Config Server为了最大程度保证可用性采用了一种三层的存储架构设计，mysql - 本地文件 - 内存缓存：
1.2：数据库
Config Server所有的key-value配置信息都最终存储在mysql数据库中，当中包含四张核心表（table）：
config_info - 存储配置信息，包含id/data_id/group_id/tenant_id/content/md5/gmt_created/gmt_modified/app_name等列。当中data_id + group_id + tenant_id三者唯一确定一条key-value配置。
config_tags_relation - 存储配置上附加的tag，包含id/tag_name/tag_type/data_id/group_id/tenant_id/nid等列。
config_info_beta - 存储beta环境的特殊配置值，除了config_info表中的列之外新增了beta_ips列。
config_info_tag - 存储某个tag对应的特殊配置值，除了config_info表中的列之外新增了tag_id列。
1.3:本地磁盘
mysql数据库中存储的是最终的配置信息，config server在启动后会周期性（360min）的从mysql中将所有配置信息dump到本地文件系统中。配置会被存储到一个特殊的目录/{user.home}/nacos/data/config-data/{groupId}/{dataId}下，每条配置存在一个独立的文件中。
config server中关于配置的读取都是走本地文件系统中的dump，这种设计一方面提升了系统的可用性（防止mysql奔溃导致config不可用），另一方面极大降低了mysql数据库的负载，使得config server的水平扩张变得非常容易。
1.4：缓存
当config server启动时会一次性把mysql中存储的所有配置dump到本地文件系统中，并设置一个定时器周期性（默认6h）做全量dump。config server也有一种quick start模式，允许重用文件系统中保留的配置数据，做增量dump。
配置信息的写首先进入到mysql数据库中。mysql插入成功之后server会生成一个ConfigDataChangeEvent事件，在AsyncNotifyService中将捕获这个事件，对当前每一个config server发起/dataChange调用。
/dataChange调用在CommunicationController中被处理，通过ConfigService将变动的数据dump到本地文件中并更新内存缓存。
配置的读取及订阅都是从内存Cache + 本地文件中完成。
二、数据存储
2.1：流程图
整个流程分为两大部分：
-
入库。插入mysql数据库，发起ConfigDataChangeEvent，调用所有server上的/dataChange接口。
-
dump。server响应/dataChange请求，异步dump数据库配置信息到本地。
2.2：ConfigController.publishConfig
处理config获取/订阅/变更相关的http请求。
2.2.1：入口
其中进行一系列的逻辑判断，但是可以看出主要做了两件事：持久化和事件发布。
public Boolean publishConfig(HttpServletRequest request, HttpServletResponse response,
@RequestParam(value = "dataId") String dataId, @RequestParam(value = "group") String group,
@RequestParam(value = "tenant", required = false, defaultValue = StringUtils.EMPTY) String tenant,
@RequestParam(value = "content") String content, @RequestParam(value = "tag", required = false) String tag,
@RequestParam(value = "appName", required = false) String appName,
@RequestParam(value = "src_user", required = false) String srcUser,
@RequestParam(value = "config_tags", required = false) String configTags,
@RequestParam(value = "desc", required = false) String desc,
@RequestParam(value = "use", required = false) String use,
@RequestParam(value = "effect", required = false) String effect,
@RequestParam(value = "type", required = false) String type,
@RequestParam(value = "schema", required = false) String schema) throws NacosException {
.......
//进行持久化保存
persistService.insertOrUpdate(srcIp, srcUser, configInfo, time, configAdvanceInfo, true);
//配置更新事件
ConfigChangePublisher
.notifyConfigChange(new ConfigDataChangeEvent(false, dataId, group, tenant, time.getTime()));
.......
}
其中持久化主要交互到数据库，进行配置数据的插入和历史表的插入。
后面一步，封装成为ConfigDataChangeEvent进行事件发布，只需要找到监听位置进行跟踪后续逻辑。事件的发布和监听，是nacos自己写的逻辑，将任务发布即将任务加入到某个任务队列，另外有一个线程在阻塞监听队列的数据，一旦发现队列中有数据，会根据任务类型找到任务的订阅者，由订阅者处理新发布的事件。
2.2.2 ConfigDataChangeEvent监听
监听事件的处理内容：
@Override
public void onEvent(Event event) {
// Generate ConfigDataChangeEvent concurrently
if (event instanceof ConfigDataChangeEvent) {
ConfigDataChangeEvent evt = (ConfigDataChangeEvent) event;
long dumpTs = evt.lastModifiedTs;
String dataId = evt.dataId;
String group = evt.group;
String tenant = evt.tenant;
String tag = evt.tag;
Collection<Member> ipList = memberManager.allMembers();
// In fact, any type of queue here can be
//初始化一个队列
Queue<NotifySingleTask> queue = new LinkedList<NotifySingleTask>();
for (Member member : ipList) {
//遍历nacos集群的成员，并在队列中添加通知任务
queue.add(new NotifySingleTask(dataId, group, tenant, tag, dumpTs, member.getAddress(),
evt.isBeta));
}
//开辟新的任务，执行队列中的任务
ConfigExecutor.executeAsyncNotify(new AsyncTask(httpclient, queue));
}
}
2.2.3 不同节点同步
private void executeAsyncInvoke() {
while (!queue.isEmpty()) {
//弹出队列的数据
NotifySingleTask task = queue.poll();
String targetIp = task.getTargetIP();
//判断是否是集群成员
if (memberManager.hasMember(targetIp)) {
// start the health check and there are ips that are not monitored, put them directly in the notification queue, otherwise notify
boolean unHealthNeedDelay = memberManager.isUnHealth(targetIp);
//判断节点是否为非监控节点，如果不健康则延时进行调用，并根据尝试次数增加延时时长
if (unHealthNeedDelay) {
// target ip is unhealthy, then put it in the notification list
ConfigTraceService.logNotifyEvent(task.getDataId(), task.getGroup(), task.getTenant(), null,
task.getLastModified(), InetUtils.getSelfIp(), ConfigTraceService.NOTIFY_EVENT_UNHEALTH,
0, task.target);
// get delay time and set fail count to the task
asyncTaskExecute(task);
} else {
//对于健康节点，直接执行通知逻辑
HttpGet request = new HttpGet(task.url);
request.setHeader(NotifyService.NOTIFY_HEADER_LAST_MODIFIED,
String.valueOf(task.getLastModified()));
request.setHeader(NotifyService.NOTIFY_HEADER_OP_HANDLE_IP, InetUtils.getSelfIp());
if (task.isBeta) {
request.setHeader("isBeta", "true");
}
//执行请求，并带上回调函数
httpclient.execute(request, new AsyncNotifyCallBack(httpclient, task));
}
}
}
}
对于非监控节点延长延时时间，主要是根据次数增减加时长
private static int getDelayTime(NotifySingleTask task) {
int failCount = task.getFailCount();
int delay = MIN_RETRY_INTERVAL + failCount * failCount * INCREASE_STEPS;
if (failCount <= MAX_COUNT) {
task.setFailCount(failCount + 1);
}
return delay;
}
对于回调函数的内容，无非就是对http请求成功或者失败的判定，以及根据结果进行后续的逻辑处理：
无论是请求成功结果状态码不正确还是调用失败，异或是取消，都会添加任务到队列中进行重试。
@Override
public void completed(HttpResponse response) {
long delayed = System.currentTimeMillis() - task.getLastModified();
if (response.getStatusLine().getStatusCode() == HttpStatus.SC_OK) {
......
} else {
......
asyncTaskExecute(task);
.......
}
HttpClientUtils.closeQuietly(response);
}
@Override
public void failed(Exception ex) {
......
asyncTaskExecute(task);
......
}
@Override
public void cancelled() {
......
asyncTaskExecute(task);
......
}
private NotifySingleTask task;
private CloseableHttpAsyncClient httpClient;
}
2.3：CommunicationController.notifyConfigInfo
该接口，对应与2.2中的通知逻辑，该部分主要进行两件事情：
（1）：将配置数据更新到缓存和磁盘文件之中；
（2）：如果有客户端长连接监听配置信息的变化，此时会找到对应key的长连接的请求，并进行响应。
2.3.2 接收到请求
if (StringUtils.isNotBlank(isBetaStr) && trueStr.equals(isBetaStr)) {
dumpService.dump(dataId, group, tenant, lastModifiedTs, handleIp, true);
} else {
dumpService.dump(dataId, group, tenant, tag, lastModifiedTs, handleIp);
}
dump的方法，根据dataId, group, tenant（命名空间编号），组装成的key。
public void dump(String dataId, String group, String tenant, long lastModified, String handleIp, boolean isBeta) {
String groupKey = GroupKey2.getKey(dataId, group, tenant);
//添加任务
dumpTaskMgr.addTask(groupKey, new DumpTask(groupKey, lastModified, handleIp, isBeta));
}
//添加任务到tasks中，添加任务时候使用lock，大概是防止在任务添加的时候，执行该类的processor方法。
public void addTask(String type, AbstractTask task) {
this.lock.lock();
try {
AbstractTask oldTask = tasks.put(type, task);
MetricsMonitor.getDumpTaskMonitor().set(tasks.size());
if (null != oldTask) {
task.merge(oldTask);
}
} finally {
this.lock.unlock();
}
}
该类中有一个processor的方法，该方法是当前类循环执行，每次执行间隙会休眠：
public void run() {
while (!TaskManager.this.closed.get()) {
try {
Thread.sleep(100);
TaskManager.this.process();
} catch (Throwable e) {
LogUtil.DUMP_LOG.error("execute dump process has error : {}", e);
}
}
}
在processor方法两阶段事情：
（1）：判断当前任务是否还需要继续执行，不需要就将任务对队列中去除；
（2）：找到TaskProcessor，并调用result = processor.process(entry.getKey(), task);方法
protected void process() {
for (Map.Entry<String, AbstractTask> entry : this.tasks.entrySet()) {
AbstractTask task = null;
this.lock.lock();
try {
// Getting task.
//判断当前任务是否还需要继续执行，不需要就删除
task = entry.getValue();
if (null != task) {
if (!task.shouldProcess()) {
// If current task needn't to process, then it will skip.
continue;
}
// Remove task from task maps.
this.tasks.remove(entry.getKey());
MetricsMonitor.getDumpTaskMonitor().set(tasks.size());
}
} finally {
this.lock.unlock();
}
if (null != task) {
// Getting task processor.找到对应的TaskProcessor，此时会使用默认this.processor = new DumpProcessor(this);
TaskProcessor processor = this.taskProcessors.get(entry.getKey());
if (null == processor) {
// If has no related typpe processor, then it will use default processor.
processor = this.getDefaultTaskProcessor();
}
if (null != processor) {
boolean result = false;
try {
// Execute the task.
result = processor.process(entry.getKey(), task);
} catch (Throwable t) {
LOGGER.error("task_fail", "处理task失败", t);
}
if (!result) {
// If task is executed failed, the set lastProcessTime.
task.setLastProcessTime(System.currentTimeMillis());
// Add task into task map again.
this.addTask(entry.getKey(), task);
}
}
}
}
if (tasks.isEmpty()) {
this.lock.lock();
try {
this.notEmpty.signalAll();
} finally {
this.lock.unlock();
}
}
}
2.3.3 DumpProcessor.process
其中一大坨代码，只是进行两个操作：包装数据和调用DumpConfigHandler.configDump(build.build())方法：
......
//包装数据
ConfigDumpEvent.ConfigDumpEventBuilder build = ConfigDumpEvent.builder().namespaceId(tenant).dataId(dataId)
.group(group).isBeta(isBeta).tag(tag).lastModifiedTs(lastModified).handleIp(handleIp);
......
//查询数据，查出最新数据
ConfigInfo4Beta cf = persistService.findConfigInfo(dataId, group, tenant);
//如果查出是null的处理
build.remove(Objects.isNull(cf));
build.betaIps(Objects.isNull(cf) ? null : cf.getBetaIps());
build.content(Objects.isNull(cf) ? null : cf.getContent());
//进行进步调用
return DumpConfigHandler.configDump(build.build());
}
2.3.4 DumpConfigHandler.configDump
其中的核心代码：
//对比md5值之后，保存到缓存和本地文件
result = ConfigCacheService.dump(dataId, group, namespaceId, content, lastModified, type);
直接进入ConfigCacheService.dump：
开始部分：
尝试获取一次写锁，如果获取失败，就会直接返回，不再进行数据写入，写锁是代码层面实现，不深入。
final int lockResult = tryWriteLock(groupKey);
assert (lockResult != 0);
if (lockResult < 0) {
DUMP_LOG.warn("[dump-error] write lock failed. {}", groupKey);
return false;
}
接下来进入主题：
//获取当前内容的md5值
final String md5 = MD5Utils.md5Hex(content, Constants.ENCODE);
if (md5.equals(ConfigCacheService.getContentMd5(groupKey))) {
DUMP_LOG.warn("[dump-ignore] ignore to save cache file. groupKey={}, md5={}, lastModifiedOld={}, "
+ "lastModifiedNew={}", groupKey, md5, ConfigCacheService.getLastModifiedTs(groupKey),
lastModifiedTs);
} else if (!PropertyUtil.isDirectRead()) {
//保存到本地磁盘
DiskUtil.saveToDisk(dataId, group, tenant, content);
}
//更新MD5值
updateMd5(groupKey, md5, lastModifiedTs);
其中保存本地磁盘不再细化，即找到目标文件，将数据写入。后面updateMd5值：
public static void updateMd5(String groupKey, String md5, long lastModifiedTs) {
CacheItem cache = makeSure(groupKey);
if (cache.md5 == null || !cache.md5.equals(md5)) {
cache.md5 = md5;
cache.lastModifiedTs = lastModifiedTs;
NotifyCenter.publishEvent(new LocalDataChangeEvent(groupKey));
}
}
其中makerSure就是获取缓存数据，上面已经叙述缓存中只保存对应的md5值和更新时间，读写锁等信息，不包括具体的配置数据。
此时可以看到发布LocalDataChangeEvent事件，监听该事件部分在下一个章节进行描述。
