CacheData也是个出场频率非常高的一个类，我们看到除了dataId、group、tenant、content这些相关的基础属性，还有几个比较重要的属性如：listeners、md5(content真实配置数据计算出来的md5值)，以及注册监听、数据比对、服务端数据变更通知操作都在这里。
其中listeners是对dataId所注册的所有监听器集合，其中的ManagerListenerWrap对象除了持有Listener监听类，还有一个lastCallMd5字段，这个属性很关键，它是判断服务端数据是否更变的重要条件。
在添加监听的同时会将CacheData对象当前最新的md5值赋值给ManagerListenerWrap对象的lastCallMd5属性。
public void addListener(Listener listener) { ManagerListenerWrap wrap = (listener instanceof AbstractConfigChangeListener) ? new ManagerListenerWrap(listener, md5, content) : new ManagerListenerWrap(listener, md5); }看到这对dataId监听设置就完事了？我们发现所有操作都围着cacheMap结构中的CacheData对象，那么大胆猜测下一定会有专门的任务来处理这个数据结构。
变更通知
客户端又是如何感知服务端数据已变更呢？
我们还是从头看，NacosConfigService类的构造器中初始化了一个ClientWorker，而在ClientWorker类的构造器中又启动了一个线程池来轮询cacheMap。
而在executeConfigListen()方法中有这么一段逻辑，检查cacheMap中dataId的CacheData对象内，MD5字段与注册的监听listener内的lastCallMd5值，不相同表示配置数据变更则触发safeNotifyListener方法，发送数据变更通知。
void checkListenerMd5() { for (ManagerListenerWrap wrap : listeners) { if (!md5.equals(wrap.lastCallMd5)) { safeNotifyListener(dataId, group, content, type, md5, encryptedDataKey, wrap); } } }safeNotifyListener()方法单独起线程，向所有对dataId注册过监听的客户端推送变更后的数据内容。
客户端接收通知，直接实现receiveConfigInfo()方法接收回调数据，处理自身业务就可以了。
configService.addListener(dataId, group, new Listener() { @Override public void receiveConfigInfo(String configInfo) { System.out.println("receive:" + configInfo); } @Override public Executor getExecutor() { return null; } });为了理解更直观我用测试demo演示下，获取服务端配置并设置监听，每当服务端配置数据变化，客户端监听都会收到通知，一起看下效果。
public static void main(String[] args) throws NacosException, InterruptedException { String serverAddr = "localhost"; String dataId = "test"; String group = "DEFAULT_GROUP"; Properties properties = new Properties(); properties.put("serverAddr", serverAddr); ConfigService configService = NacosFactory.createConfigService(properties); String content = configService.getConfig(dataId, group, 5000); System.out.println(content); configService.addListener(dataId, group, new Listener() { @Override public void receiveConfigInfo(String configInfo) { System.out.println("数据变更 receive:" + configInfo); } @Override public Executor getExecutor() { return null; } }); boolean isPublishOk = configService.publishConfig(dataId, group, "我是新配置内容～"); System.out.println(isPublishOk); Thread.sleep(3000); content = configService.getConfig(dataId, group, 5000); System.out.println(content); }结果和预想的一样，当向服务端publishConfig数据变化后，客户端可以立即感知，愣是用主动拉pull模式做出了服务端实时推送的效果。
数据变更 receive:我是新配置内容～ true 我是新配置内容～ 服务端源码分析Nacos配置中心的服务端源码主要在nacos-config项目的ConfigController类，服务端的逻辑要比客户端稍复杂一些，这里我们重点看下。
处理长轮询
服务端对外提供的监听接口地址/v1/cs/configs/listener，这个方法内容不多，顺着doPollingConfig往下看。
服务端根据请求header中的Long-Pulling-Timeout属性来区分请求是长轮询还是短轮询，这里咱们只关注长轮询部分，接着看LongPollingService（记住这个service很关键）类中的addLongPollingClient()方法是如何处理客户端的长轮询请求的。
正常客户端默认设置的请求超时时间是30s，但这里我们发现服务端“偷偷”的给减掉了500ms，现在超时时间只剩下了29.5s，那为什么要这样做呢？