用官方的解释之所以要提前500ms响应请求，为了最大程度上保证客户端不会因为网络延时造成超时，考虑到请求可能在负载均衡时会耗费一些时间，毕竟Nacos最初就是按照阿里自身业务体量设计的嘛！
此时对客户端提交上来的groupkey的MD5与服务端当前的MD5比对，如md5值不同，则说明服务端的配置项发生过变更，直接将该groupkey放入changedGroupKeys集合并返回给客户端。
MD5Util.compareMd5(req, rsp, clientMd5Map)如未发生变更，则将客户端请求挂起，这个过程先创建一个名为ClientLongPolling的调度任务Runnable，并提交给scheduler定时线程池延后29.5s执行。
ConfigExecutor.executeLongPolling( new ClientLongPolling(asyncContext, clientMd5Map, ip, probeRequestSize, timeout, appName, tag));这里每个长轮询任务携带了一个asyncContext对象，使得每个请求可以延迟响应，等延时到达或者配置有变更之后,调用asyncContext.complete()响应完成。
asyncContext 为 Servlet 3.0新增的特性，异步处理，使Servlet线程不再需要一直阻塞，等待业务处理完毕才输出响应；可以先释放容器分配给请求的线程与相关资源，减轻系统负担，其响应将被延后，在处理完业务或者运算后再对客户端进行响应。
ClientLongPolling任务被提交进入延迟线程池执行的同时，服务端会通过一个allSubs队列保存所有正在被挂起的客户端长轮询请求任务，这个是客户端注册监听的过程。
如延时期间客户端据数一直未变化，延时时间到达后将本次长轮询任务从allSubs队列剔除，并响应请求response，这是取消监听。收到响应后客户端再次发起长轮询，循环往复。
到这我们知道服务端是如何挂起客户端长轮询请求的，一旦请求在挂起期间，用户通过管理平台操作了配置项，或者服务端收到了来自其他客户端节点修改配置的请求。
怎么能让对应已挂起的任务立即取消，并且及时通知客户端数据发生了变更呢？
数据变更
管理平台或者客户端更改配置项接位置ConfigController中的publishConfig方法。
值得注意得是，在publishConfig接口中有这么一段逻辑，某个dataId配置数据被修改时会触发一个数据变更事件Event。
ConfigChangePublisher.notifyConfigChange(new ConfigDataChangeEvent(false, dataId, group, tenant, time.getTime()));仔细看LongPollingService会发现在它的构造方法中，正好订阅了数据变更事件，并在事件触发时执行一个数据变更调度任务DataChangeTask。
DataChangeTask内的主要逻辑就是遍历allSubs队列，上边我们知道，这个队列中维护的是所有客户端的长轮询请求任务，从这些任务中找到包含当前发生变更的groupkey的ClientLongPolling任务，以此实现数据更变推送给客户端，并从allSubs队列中剔除此长轮询任务。
而我们在看给客户端响应response时，调用asyncContext.complete()结束了异步请求。
上边只揭开了nacos配置中心的冰山一角，实际上还有非常多重要的技术细节都没提及到，建议大家没事看看源码，源码不需要通篇的看，只要抓住核心部分就够了。就比如今天这个题目以前我真没太在意，突然被问一下子吃不准了，果断看下源码，而且这样记忆比较深刻（别人嚼碎了喂你的知识总是比自己咀嚼的差那么点意思）。
nacos的源码我个人觉得还是比较朴素的，代码并没有过多炫技，看起来相对轻松。大家不要对看源码有什么抵触，它也不过是别人写的业务代码而已，just so so!
我是小富～，如果对你有用在看、关注支持下，咱们下期见~
整理了几百本各类技术电子书，有需要的同学自取。技术群快满了，想进的同学可以加我好友，和大佬们一起吹吹技术。
电子书地址
个人公众号： 程序员内点事，欢迎交流