Nacos 配置中心之服务端长轮询处理机制
Nacos 配置中心之服务端长轮询处理机制
接着上回说,客户端进行长轮询其实是使用定时线程来定时调用/v1/cs/configs/listener 接口,那么服务端的这个接口实现逻辑又是怎样的呢?今天我们就看看这一块的内容。
客户端发起 http 请求进行长轮询,调用接口/listner 服务端在 nacos-config 模块中的 ConfigController 类中:
ConfigController 的 listener()方法
ConfigController 的 listener()方法:
获取客户端需要监听的可能发送变化的配置,计算 MD5 值
inner.doPollingConfig 执行长轮询请求
doPollingConfig()方法
判断当前请求是否为长轮询,如果是,调用
LongPollingService
的 addLongPollingClient()方法不是长轮询,就立即返回结果
LongPollingService 的 addLongPollingClient()
这个方法主要把客户端的长轮询请求封装成 ClientLongPolling 交给 scheduler 执行
获取客户端请求的超时时间,减去 500ms 后赋值给 timeout 变量。
判断 isFixedPolling,如果为 true,定时任务将会在 30s 后开始执行,否则在 29.5s 后开始执行
和服务端的数据进行 MD5 对比,如果发送变化则直接返回
scheduler.execute 执行 ClientLongPolling 线程
ClientLongPolling
ClientLongPolling 是一个线程,run 方法如下:
通过 scheduler.schedule 启动一个定时任务,并延时时间为 29.5s
将 ClientLongPolling 实例本身添加到 allSubs 队列中,它主要维护一个长轮询的订阅关系。
定时任务执行后,先把 ClientLongPolling 实例本身从 allSubs 队列中移除。
通过 MD5 比较客户端请求的 groupKeys 是否发生变更,并将变更结果通过 response 返回给客户端
所谓长轮询就是服务端收到请求之后,不立即返回,而是在延 29.5s 才把请求结果返回给客户端,这使得客户端和服务端之间在 30s 之内数据没有发生变化的情况下一直处于连接状态。
总结
通过对服务端/v1/cs/configs/listener 接口的分析,我们知道这个接口处理客户端的长轮询,使用定时线程,29.5s 之后查看是否有信息变更,有的话再返回给客户端信息,保证 30s 内有数据变化内察觉到。
版权声明: 本文为 InfoQ 作者【周杰伦本人】的原创文章。
原文链接:【http://xie.infoq.cn/article/fcf4aa6480feea1d185567580】。文章转载请联系作者。
评论