Nacos作为阿里的开源中间件在Spring Cloud生态以后，不管是作为配置中心，还是作为注册中心，因为它简单易用的特性，在互联网公司被广泛运用。随后，大家会发现Nacos相关的面试题也就越来越多了。

这不，又有一位工作8年的小伙伴，被问到这样一道面试题，说，请你详细介绍一下Nacos客户端是如何实现配置动态更新的。今天，我给大家分享一下我对这个问题的理解。

1 原理分析

下面我给大家分享一下我对Nacos配置动态更新原理的理解。

首先，Nacos采用的是长轮询的方式。也就是说，由Nacos Client向Nacos Server端去发起配置更新查询的请求。所谓长轮询，就是客户端发起一次轮询请求到服务器端，当服务器端的配置没有任何变更的时候，这个连接会一直打开，直到服务端有配置变更或者连接超时之后才返回。

Nacos Client端需要去获取服务端变更的配置内容，但前提是需要先进行比较。也就是说将客户端本地缓存的配置信息和服务器端获取的配置信息进行比较。一旦发现本地缓存的配置内容和服务端的配置内容有差异，那么，就表示服务器端的配置有更新。于是，需要把更新的配置拉到本地，在这个过程中，有可能因为客户端的配置比较多，而导致对比的时间较长，使得配置的同步效率非常低。

于是Nacos针对这样一个场景，做了两个方面的优化：

1、减少网络通信的数据量。客户端把需要进行对比的配置按配置项进行分片，每个分片的大小是3000项，也就是说每一次最多拿3000个配置项去Nacos Server端进行对比。

2、分阶段进行对比和更新。第一阶段，客户端把3000个配置项的Key以及对应Value的MD5值拼接成一个字符串，然后发送到Nacos Server端进行判断，服务端会逐个比较这些配置中MD5不同的Key，把存在更新的Key返回给客户端。第二阶段，客户端拿到这些数据有变更的Key，循环逐个调用服务端，从而获取这些Key对应的Value值。

那么，这两个优化的核心目的是去减少网络通信中数据包的大小。把一次大数据包的通信拆分成了多个小数据包的通信。虽然会增加网络通信的次数，但是，提高了整体的数据传输的性能。

最后，再加上长轮询的方式，既减少了Pull的轮询次数，又利用了长轮询的优势，很好地实现了配置动态更新的同步功能。

好了，以上就是我对这个问题的理解。

我是被编程耽误的文艺Tom，关注我，面试不再难！