微服务学习第四十六节 Nacos Config动态刷新原理

Nacos Config动态刷新原理

动态监听

所谓动态监听，简单理解就是指Nacos会自动找到那些服务已经注册，而对比来说静态监听，就是指需要有指定配置指定的服务。

其实在这里我们就要说一下客户端和服务端的交互方式，无非就是推和拉

• Push：表示服务端主动将数据变更信息推送给客户端
  • 服务需要维持客户端的长连接，因为需要知道具体推送的客户端
  • 客户端耗费内存高，因为需要保存所有客户端的连接，并且需要检测连接有效性（心跳机制）
• Pull：表示客户端主动去服务端拉取数据
  • 需要定时拉取数据
  • 缺点：时效性，数据实时性，无效请求

Nacos Config动态刷新机制

核心：Nacos动态刷新机制，采用推和拉的优点，避免缺点。

Nacos做配置中心的时候，配置数据的交互模式是有服务端push推送的，还是客户端pull拉取的？

Nacos客户端发送一个请求连接到服务端，然后服务端中会有一个29.5+0.5s的一个hold期，然后服务端会将此次请求放入到allSubs队列中等待，触发服务端返回结果的情况只有两种，第一种是时间等待了29.5秒，配置未发生改变，则返回未发生改变的配置；第二种是操作Nacos Dashboard或者API对配置文件发生一次变更，此时会触发配置变更的事件，发送一条LocalDataEvent消息，此时服务端监听到消息，然后遍历allSubs队列，根据对应的groupId找到配置变更的这条ClientLongPolling任务，并且通过连接返回给客户端

Nacos动态刷新避免了服务端对客户端进行push操作时需要保持双方的心跳连接，同样也避免了客户端对服务端进行pull操作时数据的时效性问题，不必频繁去拉去服务端的数据

通过上面原理的初步了解，显而易见，答案是：客户端主动拉取的，通长轮询的方式（Long Polling）的方式来获取配置数据。

短轮询

不管服务端的配置是否发生变化，不停发起请求去获取配置，比如支付订单场景中前端不断轮询订单支付的状态，这样的坏处显而易见，由于配置并不会频繁发生变更，如果是一直发请求，一定会对服务端造成很大的压力。还会造成数据推送的延迟，比如每10秒请求一次配置，如果在第11秒的时候配置更新，那么推送将会延迟9秒，等待下一次请求这就是短轮询，为了解决短轮询的问题，有了长轮询的方案

长轮询

长轮询不是什么新技术，它其实就是由服务端控制响应客户端请求结果的返回时间，来减少客户端无效请求的一种优化手段，其实对于客户端来说，长轮询的使用并没有本质上的区别，客户端发起请求后，服务端不会立即返回请求结果，而是将请求hold挂起一段时间，如果此时间段内配置数据发生变更，则立即响应客户端，若一直无变更则等到指定超时时间后响应给客户端结果，客户端重新发起长链接