《Nacos-配置动态更新》

[yunCrush]

Nacos配置动态更新

　　先分析两种简单的刷新配置的机制，Pull模式与Push模式。

1. Pull模式

Client每次从Server进行拉取配置，不足: 每次拉取的时间间隔不好把控，时间间隔太短，会存在许多次无效的拉取，时间间隔太长，Server端更新了配置，Client端不能及时的获取，这是时效性问题。

2. Push模式

Server端每次主动的给Client进行推送，一旦发生配置更新就及时推送，显然这是可以解决Pull模式的时效性问题，但是，Server需要保持长连接，并且维持与Client的心跳，方能知道Client是否有宕掉，是否可以及时的Push配置。不足: 如果Client数量过多，Server需要维持与多个节点的心跳，耗费资源，即多节点的心跳问题。

3. Nacos：长轮询

简要概述: Nacos采用的是客户端长轮询主动Pull的机制，长轮询也不难理解，即：Client端发起一个请求（假设这个请求的超时时间是30s），Server端获取到这个请求之后，并不会立即的响应这个请求，而是将这个请求hold住一段时间（为了保证不超时，这里hold住请求的时间假设为29.5s），在这29.5的时间段内，①如果Server端的配置没有发生变化，在29.5s时开始检查配置是否有变更，30s时返回这个请求，也不会超时，返回给Client端后，客户端再发起下次的请求。②如果在这个时间段内，Server端的配置发生了变化，就不需要再等待到29.5s，立即返回，这样就可以保证Client端在第一时间获取到最新的配置。


　　两个线程池分别是executor和executorService，executor处理逻辑是每10ms就执行一次checkConfigInfo方法，判断当前需要监听的namespace是否达到了阈值，如果达到了阈值，则再new一个任务到executorService线程池中，后者executorService线程池处理的任务逻辑是：向服务端发起超时时长为30s的httpPost请求，判断服务端与客户端的配置是否发生了变更，如果发生了变更，客户端再次向服务端发起getServerConfig的请求。服务端收到了httpPost请求后，将请求放到allSub队列中，如果此时通过nacos的dashboard修改了配置，如图2所示，是一直有一个监听事件在监听config的，更新了服务端的配置就会触发监听事件，执行③，过滤出客户端发送过来的请求有关的配置，将相关的group分组key返回，客户端收到后，再次请求服务端，即可拿到配置了。判断是否发生变更checkServerConfig与获取变更值getServerConfig都是executorService线程池中任务的逻辑。客户端拿到了最新的配置后，executorService线程池再次执行该任务。这样就保证了每次取到的都是最新的配置了。