Nacos Config实现原理解析
Nacos Config针对配置提供了4中操作。针对这4中操作，Nacos提供了SDK及Open API的方式进行访问。
== 获取配置：从Nacos Config Server中读取配置==
监听配置：订阅感兴趣的配置，当配置发生变化时可以收到一个事件：
发布配置：将配置保存到Nacos Config Server中：
删除配置：删除配置中心的指定配置：
配置的CRUD
对于Nacos Config来说,其实就是提供了配置的集中式管理功能,然后对外提供CRUD的访问接口使得应用系统可以完成配置的基本操作。实际上这种场景并不复杂,对于服务端来说,无非就是配置如何存储,以及是否需要持久化,对于客户端来说，就是通过接口从服务器端查询到相应的数据,然后返回即可,如图所示：
除了默认采用的Derb数据库，nacos还支持MySQL数据库。
动态监听
当Nacos Config Server.上的配置发生变化时,需要让相关的应用程序感知配置的变化进而感知应用的变化,这就需要客户端针对感兴趣的配置实现监听。
那么Nacos客户端是如何实现配置变更的实时更新的呢?一般来说 ,客户端和服务端之间的数据交互无非两种方式: Pull和Push。
- Pull表示客户端从服务端主动拉取数据。
- Push表示服务端主动把数据推送到客户端。
这两种方式没有什么优劣之分,只是看哪种方式更适合于当前的场景。比如ActiveMQ就支持Push和Pull两种模式,用户可以在特定场景选择不同的模式来实现消费端消息的获取。
对于Push模式来说,服务端需要维持与客户端的长连接,如果客户端的数量比较多,那么服务端需要耗费大量的内存资源来保存每个连接,并且为了检测连接的有效性,还需要心跳机制来维持每个连接的状态。
在Pull模式下,客户端需要定时从服务端拉取一次数据，由于定时任务会存在一定的时间间隔,所以不能保证数据的实时性。并且在服务端配置长时间不更新的情况下，客户端的定时任务会做一些无效的Pull。
N acos采用的是Pull模式,但并不是简单的Pull ,而是一种长轮询机制,它结合Push和Pull两者的优势。客户端采用长轮询的方式定时发起Pull请求,去检查服务端配置信息是否发生了变更,如果发生了变更,则客户端会根据变更的数据获得最新的配置。所谓长轮询,是客户端发起轮询请求之后,服务端如果有配置发生变更,就直接返回,如图：
如果客户端发起Pull请求后,发现服务端的配置和客户端的配置是保持一致的,那么服务端会先"Hold" 住这个请求,也就是服务端拿到这个连接之后在指定的时间段内一直不返回结果,直到这段时间内配置发生变化，服务端会把原来"Hold" 住的请求进行返回,如图所示：
Nacos服务端收到请求之后,先检查配置是否发生了变更 ,如果没有 ,则设置一个定时任务,延期29.5s执行 ,并且把当 前的客户端长轮询连接加入allSubs队列。这时候有两种方式触发该连接结果的返回:
- 第一种是在等待29.5s后触发自动检查机制,这时候不管配置有没有发生变化,都会把结果返回客户端。而29.5s就是这个长连接保持的时间。
- 第二种是在29.5s内任意一个时刻,通过Nacos Dashboard或者API的方式对配置进行了修改,这会触发一个事件机制,监听到该事件的任务会遍历allSubs队列,找到发生变更的配置项对应的ClientLongPolling任务,将变更的数据通过该任务中的连接进行返回,就完成了一次"推送"操作。
这样既能保证客户端实时感知配置的变化，也降低了服务端的压力。其中，这个长连接的会话超时时间默认是30s。