配置文件加载顺序

  • 配置文件的加载顺序为： 共享配置 -> 扩展配置 -> 当前应用自身配置，
  • 如果存在相同属性配置了不同属性值，则后加载的会将先加载的给覆盖。即优先级为： 共享配置 < 扩展配置 < 应用自身配置。
  • 对于每种配置文件的加载过程，又存在三种可用选择：在应用本地存在同名配置，远程配置中心存在同名配置，本地磁盘快照 snapshot 中存在同名配置。这三种配置的优先级为： 本地配置 > 远程配置 > 快照配置。只要前面的加载到了，后面的就不再加载。
  • 若要在应用本地存放同名配置，则需要存放到当前用户主目录下的 nacos\config\fixed-localhost_8848_nacos\data\config-data\{groupId}目录中。
  • 若开启了配置的快照功能，则默认会将快照记录在当前用户主目录下的 nacos\config\fixed-localhost_8848_nacos\snapshot\{groupId}目录中。

长轮询模型

Nacos Config Server （服务端）中配置数据的变更， Nacos Config Client （客户端）是如何知道的呢？ Nacos Config Server 采用了长轮询模型实现的变更通知。

一般情况下 Server 端数据的变更若要使 Client 感知到，可以选择两种模型：

  • Push 模型： 当 Server 端的数据发生了变更，其会主动将更新推送给 Client。 Push 模型适合于 Client 数量不多，且 Server 端数据变化比较频繁的场景。 其实时性较好，但其需 要维护长连接， 占用系统资源。
  • Pull 模型： 需要 Client 定时查看 Server 端数据是否更新。其实时性不好，且可能会产生数据更新的丢失。

长轮询模型整合了 Push 与 Pull 模型的优势。 Client 仍定时发起 Pull 请求，查看 Server端数据是否更新。

  • 若发生了更新，则 Server 立即将更新数据以响应的形式发送给 Client 端；
  • 若没有发生更新， Server 端不会发送任何信息，但其会临时性的保持住这个连接一段时间。若在此时间段内， Server 端数据发生了变更，这个变更就会触发 Server 向 Client 发送变更结果。这次发送的执行，就是因为长连接的存在。若此期间仍未发生变更，则放弃这个连接。等待着下一次 Client 的 Pull 请求。 

长轮询模型，是 Push 与 Pull 模型的整合，既减少了 Push 模型中长连接的被长时间维护 的时间，又降低了 Pull 模型实时性较差的问题。