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

最新推荐文章于 2023-09-16 14:39:42 发布

AugustShuai

最新推荐文章于 2023-09-16 14:39:42 发布

阅读量2.6k

点赞数 9

分类专栏： Nacos系列学习文章标签： java 配置中心 nacos 长轮询轮询与长轮询

本文链接：https://blog.csdn.net/ChengHuanHuaning/article/details/115960121

版权

5 篇文章 5 订阅

订阅专栏

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

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

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

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

两者都是拉模式的实现

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

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

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

客户端发起长轮询

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

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

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

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

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

流程图
在这里插入图片描述

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

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