关于Nacos配置中心你所不知道的事！

「感谢你阅读本文！」

今天分享一下Nacos配置的相关知识点，现在使用Java生态如果使用微服务，如果部署在K8s上，那么可能会使用ConfigMap来存储配置文件，如果没有使用K8s，那么基本上都使用Nacos来做配置中心，所以有必要了解一下Nacos的配置的知识点。

本文只是对其中的部分实现原理进行分析。

一、怎么判断配置发生了变化

我们在使用Nacos的时候，在Console对配置进行更改后，不用重启服务，只要配置发生变化就能生效，那么Nacos是怎么判断配置发生了变化呢？

Nacos的配置中支持多种格式，比如yml，properties，xml，json等，当然，使用yml格式的应该占大部分！

不过可以肯定的是，无论使用的是哪一种格式，数据都是键值对的形式，所以我们有一种实现方式，就是将配置转换为一个Map保存下来，当通过控制台或者API对配置进行变更的时候，我们将变更的数据和保存下来的Map中的值进行一一比对，如果有发生变化的那么就更新变化的那个key的value值。

不过上面这种方案的话开销有点大，因为需要去解析配置文件，然后去对比每一个key。

Nacos的实现方式是通过对配置进行MD5加密，当配置发生变更，那么就对变更后的配置进行MD5加密，然后和本地的MD5进行比对，如果相同则代表配置没发生变更，MD5值不同则代表发生了变更，则需要推送变更的配置到服务里面。

虽然使用进行MD5加密有一定的开销，但是也是在能接受的范围内。

核心代码如下，当监听器收到配置变更后，会判断和本地的MD5是否一样，不一样则推送变更的配置。

二、怎么触发变更

在Nacos启动的时候，会在后台启动一个线程去比对配置信息变更情况，不过并不是使用死循环不断去获取，废话不多说，直接上核心代码。

Nacos中巧妙的使用了队列的poll来实现配置变更的实时拉取，图中圈出来的listenExecutebell，bell的意思是铃声，listenExecutebell是一个队列，使用了它的poll的超时方法，也就是说如果没有从listenExecutebell中获取到元素，那么就会阻塞，Nacos中阻塞50s，当获取到元素，立马往下执行。

为什么要这样做呢！

我们想一下，如果不使用这种方式，而是使用轮询的方式去处理，比如1s或者5s去获取一次，那么如果配置一直都没有变更，一直发起请求，这将会增加服务的压力，还有因为是轮询的方式，数据也不能保证能够实时。

Nacos1.X采用的是轮询分方式，后面进行了更改，比如我们从控制台或者通过API更改了配置信息，那么当客户端收到服务端配置变更的通知后，就会去调用notifyListenConfig()方法。

notifyListenConfig()方法就是往listenExecutebell队列中添加元素，当listenExecutebell中有元素时，就会去执行executeConfigListen()方法，这个方法就是去执行配置比对的相关操作。

所以总结下来，当配置信息发生变化的时候，就会主动去触发本地配置更新操作，不仅保证了实时，也不会像轮询那样占用资源。

三、服务故障数据怎么保证

因为配置信息属于需要很频繁访问的数据，所以是存储在内存中的，不过存储在内存中数据当机器发生故障的时候会丢失，那么Nacos是怎么来解决这个问题的呢？

首先如果我们要保证Nacos的高可用，高可靠，数据持久化是一定要做的，Nacos支持数据库持久化，我们可以使用Mysql来存储配置信息。

当服务出现故障重启后，Nacos会从数据库中获取数据，然后保存到内存中，如下，使用@PostConstruct标注init()方法，那么在启动时会执行这个方法。

Nacos的配置除了保存在内存，数据库中，还会保存在本地文件里，所以Nacos故障重启后，也会清理掉本地文件，然后重新生成，这样才能保证数据正确。

四、数据一致性

如果是Nacos单节点，就不存在数据一致性问题，但是当Nacos是集群部署时，就要考虑各节点数据一致问题了，所以就得引入共识机制。

Nacos使用的共识算法是JRaft和Distro，JRaft是强一致性算法，而Distro是最终一致性算法。

对于Nacos的共识机制，可以去官方文档上进行详细查看，这里不进行展开叙述了。

今天的分享就到这里，感谢你的观看，下期见！