Nacos回调机制

最新推荐文章于 2025-11-18 09:00:00 发布

转载最新推荐文章于 2025-11-18 09:00:00 发布 · 3.3k 阅读

Nacos 专栏收录该内容

6 篇文章

订阅专栏

1. 创建 ConfigService并实例化 ConfigService

1）ConfigFactory.createConfigService()创建ConfigService

2）NacosConfigService 的构造方法实例化 ConfigService ：

HttpAgent

ClientWorker

--checkConfigInfo()：

--LongPollingRunnable

① 本地检查

② 服务端检查

2. 添加Listener

ClientWorker.addTenantListeners()

CacheData类

3. 触发回调

cacheData.checkListenerMd5()

safeNotifyListener()

Nacos的动态配置：

nacos 服务端保存了配置信息，客户端连接到服务端之后，根据 dataID，group可以获取到具体的配置信息，当服务端的配置发生变更时，客户端会收到通知。

Nacos回调机制：

Nacos 服务端创建了相关的配置项（创建 ConfigService并实例化 ConfigService）。
客户端就可以进行监听了（添加 Listener）。
客户端通过一个定时任务（cacheData.checkListenerMd5()）来检查自己监听的配置项的数据的，一旦服务端的数据发生变化时，客户端将会获取到最新的数据，并将最新的数据保存在一个 CacheData 对象中，然后会重新计算 CacheData 的 md5 属性的值，此时（safeNotifyListener()）就会对该 CacheData 所绑定的 Listener 触发 receiveConfigInfo 回调。

demo：

package com.learn.nacos;
 
import com.alibaba.nacos.api.NacosFactory;
import com.alibaba.nacos.api.config.ConfigService;
import com.alibaba.nacos.api.config.listener.Listener;
import com.alibaba.nacos.api.exception.NacosException;
 
import java.util.Properties;
import java.util.concurrent.Executor;
 
/**
 * @author liuliuyang001
 *
 */
public class NacosConfig {
 
    public static void main(String[] args) {
        try {
            String serverAddr = "127.0.0.1:8848";
            String dataId = "nacos-sdk-java-config";
            String group = "DEFAULT_GROUP";
            String content = "nacos-sdk-java-config:init";
            Properties properties = new Properties();
            properties.put("serverAddr", serverAddr);
 
            // 方式一：创建ConfigService
            ConfigService configService = NacosFactory.createConfigService(serverAddr);
 
            // 方式二：创建ConfigService
            //ConfigService configService = ConfigFactory.createConfigService(serverAddr);
 
            // 方式三：创建ConfigService
            //ConfigService configService = NacosFactory.createConfigService(properties);
 
            // 方式四：创建ConfigService
            //ConfigService configService = ConfigFactory.createConfigService(properties);
 
            // 获取服务状态
            System.out.println("当前线程：" + Thread.currentThread().getName() + " ,服务状态：" + configService.getServerStatus());
 
            Listener configListener = new Listener() {
                public Executor getExecutor() {
                    return null;
                }
 
                public void receiveConfigInfo(String configInfo) {
                    System.out.println("当前线程：" + Thread.currentThread().getName() + " ,监听到配置内容变化：" + configInfo);
                }
            };
 
            // 添加监听（有时候能监听到，有时候监听不到，为什么？）
            System.out.println("添加监听");
            configService.addListener(dataId, group, configListener);
            System.out.println("添加监听成功");
 
            // 发布配置（多次运行，有时候会获取不到配置内容，难道要等待一段时间才能获取？）
            System.out.println("发布配置");
            configService.publishConfig(dataId, group, content);
            System.out.println("发布配置成功");
          
            try {
                Thread.sleep(1000 * 3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
 
            // 本地缓存：\nacos\config\fixed-127.0.0.1_8848_nacos\snapshot\DEFAULT_GROUP
            // 读取配置
            String configAfterPublish = configService.getConfig(dataId, group, 3000);
            System.out.println("当前线程：" + Thread.currentThread().getName() + " ,发布配置后获取配置内容：" + configAfterPublish);
 
            // 重新发布配置
            content = "sdk-java-config:update";
            System.out.println("重新发布配置");
            boolean rePublishFlag = configService.publishConfig(dataId, group, content);
            if(rePublishFlag) {
                System.out.println("重新发布配置成功");
            } else {
                System.out.println("重新发布配置失败");
            }
 
            // 重新读取配置
            String configAfterUpdate = configService.getConfig(dataId, group, 3000);
            System.out.println("当前线程：" + Thread.currentThread().getName() + " ,重新发布配置后获取配置内容：" + configAfterUpdate);
 
            try {
                Thread.sleep(1000 * 30);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
 
            // 移除配置
            System.out.println("移除配置");
            boolean removeFlag = configService.removeConfig(dataId, group);
            if(removeFlag) {
                System.out.println("移除配置成功");
            } else {
                System.out.println("移除配置失败");
            }
 
         try {
                Thread.sleep(1000 * 3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
          
            String configAfterRemove = configService.getConfig(dataId, group, 3000);
            System.out.println("当前线程：" + Thread.currentThread().getName() + " ,移除配置后获取配置内容：" + configAfterRemove);
 
          /*  // 取消监听
            System.out.println("取消监听");
            configService.removeListener(dataId, group, configListener);
            System.out.println("取消监听成功");*/
        } catch (NacosException e) {
            e.printStackTrace();
        }
    }
}

1. 创建 ConfigService并实例化 ConfigService

1）ConfigFactory.createConfigService()创建ConfigService

实际是通过反射调用了 NacosConfigService 的构造方法来创建 ConfigService 的，而且是有一个 Properties 参数的构造方法。
需要注意的是，这里并没有通过单例或者缓存技术，也就是说每次调用都会重新创建一个 ConfigService的实例。

2）NacosConfigService 的构造方法实例化 ConfigService ：

实例化时主要是初始化了两个对象，他们分别是：

HttpAgent
ClientWorker

HttpAgent

agent 是通过装饰者模式实现的，ServerHttpAgent 是实际工作的类，MetricsHttpAgent 在内部也是调用了 ServerHttpAgent 的方法，另外加上了一些统计操作，所以我们只需要关心 ServerHttpAgent 的功能就可以了。

ClientWorker

第一个线程池是只拥有一个线程用来执行定时任务的 executor，executor 每隔 10ms 就会执行一次 checkConfigInfo() 方法，从方法名上可以知道是每 10 ms 检查一次配置信息。
第二个线程池是一个普通的线程池，从 ThreadFactory 的名称可以看到这个线程池是做长轮询LongPollingRunnable的。

--checkConfigInfo()：

checkConfigInfo方法是取出了一批任务，然后提交给executorService线程池去执行，执行的任务就是LongPollingRunnable，每个任务都有一个 taskId。

--LongPollingRunnable

① 本地检查

首先取出与该 taskId 相关的 CacheData，然后对 CacheData 进行检查，包括本地配置检查和监听器的 md5 检查，本地检查主要是做一个故障容错，当服务端挂掉后，Nacos 客户端可以从本地的文件系统中获取相关的配置信息，如下图所示：

② 服务端检查

通过 checkUpdateDataIds() 方法从服务端获取那些值发生了变化的 dataId 列表，
通过 getServerConfig 方法，根据 dataId 到服务端获取最新的配置信息，接着将最新的配置信息保存到 CacheData 中。
最后调用 CacheData 的 checkListenerMd5 方法，可以看到该方法在第一部分也被调用过。

在该任务的最后，也就是在 finally 中又重新通过 executorService 提交了本任务。

2. 添加Listener

ClientWorker.addTenantListeners()

调用了ClientWorker 的 addTenantListeners 方法为 ConfigService 来添加一个 Listener

首先根据 dataId，group 和当前的场景获取一个 CacheData 对象
然后将当前要添加的 listener 对象添加到 CacheData 中去。

listener 最终是被这里的 CacheData 所持有了，那 listener 的回调方法 receiveConfigInfo 就应该是在 CacheData 中触发的。CacheData 是出现频率非常高的一个类，在 LongPollingRunnable 的任务中，几乎所有的方法都围绕着 CacheData 类，现在添加 Listener 的时候，实际上该 Listener 也被委托给了 CacheData。

CacheData类

成员变量：

dataId，group，content，taskId：跟配置相关的属性
listeners：该 CacheData 所关联的所有 listener，不过不是保存的原始的 Listener 对象，而是包装后的ManagerListenerWrap 对象，该对象除了持有 Listener 对象，还持有了一个 lastCallMd5 属性。
md5：根据当前对象的 content 计算出来的 md5 值。

3. 触发回调

cacheData.checkListenerMd5()

在 ClientWorker 中的定时任务中，启动了一个长轮询的任务：LongPollingRunnable，该任务多次执行了 cacheData.checkListenerMd5() 方法：

该方法会检查 CacheData 当前的 md5 与 CacheData 持有的所有 Listener 中保存的 md5 的值是否一致，如果不一致，就执行一个安全的监听器的通知方法：safeNotifyListener()，通应该是通知 Listener 的使用者，该 Listener 所关注的配置信息已经发生改变了。

safeNotifyListener()

那 CacheData 的 md5 值是何时发生改变的呢？我们可以回想一下，在上面的 LongPollingRunnable 所执行的任务中，在获取服务端发生变更的配置信息时，将最新的 content 数据写入了 CacheData 中，我们可以看下该方法如下：

在长轮询的任务中，当服务端配置信息发生变更时，客户端将最新的数据获取下来之后，保存在了 CacheData 中，同时更新了该 CacheData 的 md5 值，所以当下次执行 checkListenerMd5 方法时，就会发现当前 listener 所持有的 md5 值已经和 CacheData 的 md5 值不一样了，也就意味着服务端的配置信息发生改变了，这时就需要将最新的数据通知给 Listener 的持有者。