阿里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系列——配置中心为什么选择长轮询?_第1张图片

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

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

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

你可能感兴趣的:(Nacos系列学习,java,配置中心,nacos,长轮询,轮询与长轮询)