阿里Nacos系列——配置中心为什么选择长轮询？

本系列是从头开始进行学习Nacos的相关知识，从相关概念到业务开发等等。本篇是第五篇，主要知道配置中心为什么选择长轮询？

入门篇：阿里Nacos系列——为什么要选择Nacos和Nacos的基础概念
入门篇：阿里Nacos系列——Nacos的核心概念
搭建篇：阿里Nacos系列——Nacos安装教程（带图–手把手教学）
搭建篇：阿里Nacos系列——（超详细、带图带源码）Nacos注册中心的搭建与测试
概念篇：阿里Nacos系列——配置中心为什么选择长轮询？

数据交互模式

数据交互有两种模式：Push（推模式）和 Pull（拉模式）。

推模式指的是客户端与服务端建立好网络长连接，服务方有相关数据，直接通过长连接通道推送到客户端。

• 优点是及时，一旦有数据变更，客户端立马能感知到；另外对客户端来说逻辑简单，不需要关心有无数据这些逻辑处理
• 缺点是如果客户端的数量比较多，那么服务端需要耗费大量的内存资源来保存每个资源，并且为了检测连接的有效性，还需要心跳机制来维持每个连接的状态

拉模式指的是客户端主动向服务端发出请求，拉取相关数据

• 优点是此过程由客户端发起请求，故不存在推模式中数据积压的问题
• 缺点是可能不够及时，如果服务端配置长时间不更新的情况下，客户端的定时任务会做一些无效的Pull操作

轮询与长轮询

两者都是拉模式的实现

轮询是指不管服务端数据有无更新，客户端每隔定长时间请求拉取一次数据，可能有更新数据返回，也可能什么都没有。配置中心如果使用「轮询」实现动态推送，会有以下问题：

• 推送延迟。客户端每隔 5s 拉取一次配置，若配置变更发生在第 6s，则配置推送的延迟会达到 4s。
  服务端压力。配置一般不会发生变化，频繁的轮询会给服务端造成很大的压力。
• 推送延迟和服务端压力无法中和。降低轮询的间隔，延迟降低，压力增加；增加轮询的间隔，压力降低，延迟增高。

长轮询则不存在上述的问题。客户端发起长轮询，如果服务端的数据没有发生变更，会 hold 住请求，直到服务端的数据发生变化，或者等待一定时间超时才会返回。返回后，客户端又会立即再次发起下一次长轮询。配置中心使用「长轮询」如何解决「轮询」遇到的问题也就显而易见了：

• 推送延迟。服务端数据发生变更后，长轮询结束，立刻返回响应给客户端。
• 服务端压力。长轮询的间隔期一般很长，例如 30s、60s，并且服务端 hold 住连接不会消耗太多服务端资源。

长轮询核心流程

• 客户端发起长轮询

  客户端发起一个 HTTP 请求，请求信息包含配置中心的地址，以及监听的 dataId（本文出于简化说明的考虑，认为 dataId 是定位配置的唯一键）。若配置没有发生变化，客户端与服务端之间一直处于连接状态。

• 服务端监听数据变化

  服务端会维护 dataId 和长轮询的映射关系，如果配置发生变化，服务端会找到对应的连接，为响应写入更新后的配置内容。如果超时内配置未发生变化，服务端找到对应的超时长轮询连接，写入 304 响应。

  304 在 HTTP 响应码中代表“未改变”，并不代表错误。比较契合长轮询时，配置未发生变更的场景。

• 客户端接收长轮询响应

  首先查看响应码是 200 还是 304，以判断配置是否变更，做出相应的回调。之后再次发起下一次长轮询。

• 服务端设置配置写入的接入点

  主要用配置控制台和 client 发布配置，触发配置变更

nacos实现长轮询

流程图

Nacos服务端收到请求后，会检查配置是否发生了变更，如果没有，那么设置一个定时任务，延期29.5秒执行。同时并且把当前的客户端长轮询连接加入到allSubs队列。 这时候有两种方式触发该连接结果的返回：

• 第一种：等待29.5秒（长连接保持的时间）后触发自动检查机制，这时候不管配置有无发生变化，都会把结果返回给客户端。
• 第二种：在29.5秒内的任意一个时刻，通过Nacos控制台或者API的方式对配置进行了修改，那么触发一个事件机制，监听到该事件的任务会遍历allSubs队列，找到发生变更的配置项对应的ClientLongPolling任务，将变更的数据通过该任务中的连接进行返回，即完成了一次推送操作。

参考文章：SpringCloud-Nacos配置中心实现原理