阿里面试这样问：Nacos配置中心交互模型是 push 还是 pull ？（原理+源码分析）...

梦里梦外; 2022-09-11 02:20 78阅读 0赞

点击上方蓝色“石杉的架构笔记”，选择“设为星标”
    
    回复“PDF”获取独家整理的学习资料！

![0323c3a2add989ac12c72d427ab344b6.png][]

![c0f6f591c564a4df32cbdb4e5368e92f.png][]

![a628b3ca85fcc933b51b00fa2666e1d6.png][]

长按扫描上方一元购买

![a475ca2efab5e14a3a6a6864cb33ff22.png][]

# 本文来源：公众号「 程序员内点事」  #

对于`Nacos`大家应该都不太陌生，出身阿里名声在外，能做动态服务发现、配置管理，非常好用的一个工具。然而这样的技术用的人越多面试被问的概率也就越大，如果只停留在使用层面，那面试可能要吃大亏。

比如我们今天要讨论的话题，`Nacos`在做配置中心的时候，配置数据的交互模式是服务端推过来还是客户端主动拉的？

![80c243cc5eb8ddb64698714ecd82cb24.png][]

这里我先抛出答案：客户端主动拉的！

接下来咱们扒一扒`Nacos`的源码，来看看它具体是如何实现的？

### 配置中心 ###

聊`Nacos`之前简单回顾下配置中心的由来。

简单理解配置中心的作用就是对配置统一管理，修改配置后应用可以动态感知，而无需重启。

因为在传统项目中，大多都采用静态配置的方式，也就是把配置信息都写在应用内的`yml`或`properties`这类文件中，如果要想修改某个配置，通常要重启应用才可以生效。

但有些场景下，比如我们想要在应用运行时，通过修改某个配置项，实时的控制某一个功能的开闭，频繁的重启应用肯定是不能接受的。

尤其是在微服务架构下，我们的应用服务拆分的粒度很细，少则几十多则上百个服务，每个服务都会有一些自己特有或通用的配置。假如此时要改变通用配置，难道要我挨个改几百个服务配置？很显然这不可能。所以为了解决此类问题配置中心应运而生。

![5702f60155f1d7d017494feb43bec11c.png][] 配置中心

### 推与拉模型 ###

客户端与配置中心的数据交互方式其实无非就两种，要么推`push`，要么拉`pull`。

**推模型**

客户端与服务端建立`TCP`长连接，当服务端配置数据有变动，立刻通过建立的长连接将数据推送给客户端。

优势：长链接的优点是实时性，一旦数据变动，立即推送变更数据给客户端，而且对于客户端而言，这种方式更为简单，只建立连接接收数据，并不需要关心是否有数据变更这类逻辑的处理。

弊端：长连接可能会因为网络问题，导致不可用，也就是俗称的`假死`。连接状态正常，但实际上已无法通信，所以要有的心跳机制`KeepAlive`来保证连接的可用性，才可以保证配置数据的成功推送。

**拉模型**

客户端主动的向服务端发请求拉配置数据，常见的方式就是轮询，比如每3s向服务端请求一次配置数据。

轮询的优点是实现比较简单。但弊端也显而易见，轮询无法保证数据的实时性，什么时候请求？间隔多长时间请求一次？都是不得不考虑的问题，而且轮询方式对服务端还会产生不小的压力。

### 长轮询 ###

开篇我们就给出了答案，`nacos`采用的是客户端主动拉`pull`模型，应用长轮询（`Long Polling`）的方式来获取配置数据。

额？以前只听过轮询，长轮询又是什么鬼？它和传统意义上的轮询（暂且叫短轮询吧，方便比较）有什么不同呢？

**短轮询**

不管服务端配置数据是否有变化，不停的发起请求获取配置，比如支付场景中前段JS轮询订单支付状态。

这样的坏处显而易见，由于配置数据并不会频繁变更，若是一直发请求，势必会对服务端造成很大压力。还会造成推送数据的延迟，比如：每10s请求一次配置，如果在第11s时配置更新了，那么推送将会延迟9s，等待下一次请求。

![525f1fec094e57b6aca7213074ef817e.png][]

为了解决短轮询的问题，有了长轮询方案。

**长轮询**

长轮询可不是什么新技术，它不过是由服务端控制响应客户端请求的返回时间，来减少客户端无效请求的一种优化手段，其实对于客户端来说与短轮询的使用并没有本质上的区别。

客户端发起请求后，服务端不会立即返回请求结果，而是将请求挂起等待一段时间，如果此段时间内服务端数据变更，立即响应客户端请求，若是一直无变化则等到指定的超时时间后响应请求，客户端重新发起长链接。

![b6c6be6ef5601a67ad0a57a4b9710f0c.png][]

### Nacos初识 ###

为了后续演示操作方便我在本地搭了个`Nacos`。**注意：** 运行时遇到个小坑，由于`Nacos`默认是以`cluster`集群的方式启动，而本地搭建通常是单机模式`standalone`，这里需手动改一下启动脚本`startup.X`中的启动模式。

![ccc72a9ac0e0838206c5756397257fb3.png][]

直接执行`/bin/startup.X`就可以了，默认用户密码均是`nacos`。![160e3b5f70e350ace0fe908f8bb24bf1.png][]

### 几个概念 ###

`Nacos`配置中心的几个核心概念：`dataId`、`group`、`namespace`，它们的层级关系如下图：![5636d0d3a906949c87bd8b411295e087.png][]

`dataId`：是配置中心里最基础的单元，它是一种`key-value`结构，`key`通常是我们的配置文件名称，比如：`application.yml`、`mybatis.xml`，而`value`是整个文件下的内容。

目前支持`JSON`、`XML`、`YAML`等多种配置格式。![d7e33271f6ed6933e6dbdf9e21945f61.png][]

`group`：dataId配置的分组管理，比如同在dev环境下开发，但同环境不同分支需要不同的配置数据，这时就可以用分组隔离，默认分组`DEFAULT_GROUP`。

`namespace`：项目开发过程中肯定会有`dev`、`test`、`pro`等多个不同环境，`namespace`则是对不同环境进行隔离，默认所有配置都在`public`里。

### 架构设计 ###

下图简要描述了`nacos`配置中心的架构流程。

客户端、控制台通过发送Http请求将配置数据注册到服务端，服务端持久化数据到Mysql。

客户端拉取配置数据，并批量设置对`dataId`的监听发起长轮询请求，如服务端配置项变更立即响应请求，如无数据变更则将请求挂起一段时间，直到达到超时时间。为减少对服务端压力以及保证配置中心可用性，拉取到配置数据客户端会保存一份快照在本地文件中，优先读取。

![a09213f01b2b53c79dd1254c828e53bb.png][]

这里我省略了比较多的细节，如鉴权、负载均衡、高可用方面的设计（其实这部分才是真正值得学的，后边另出文讲吧），主要弄清客户端与服务端的数据交互模式。

> “
> 
> 下边我们以Nacos 2.0.1版本源码分析，2.0以后的版本改动较多，和网上的很多资料略有些不同 地址：https://github.com/alibaba/nacos/releases/tag/2.0.1

### 客户端源码分析 ###

`Nacos`配置中心的客户端源码在`nacos-client`项目，其中`NacosConfigService`实现类是所有操作的核心入口。

说之前先了解个客户端数据结构`cacheMap`，这里大家重点记住它，因为它几乎贯穿了Nacos客户端的所有操作，由于存在多线程场景为保证数据一致性，`cacheMap`采用了`AtomicReference`原子变量实现。

/**
     * groupKey -> cacheData.
     */
    private final AtomicReference<Map<String, CacheData>> cacheMap = new AtomicReference<Map<String, CacheData>>(new HashMap<>());

`cacheMap`是个Map结构，key为`groupKey`，是由dataId, group, tenant(租户)拼接的字符串；value为`CacheData`对象，每个dataId都会持有一个CacheData对象。

**获取配置**

`Nacos`获取配置数据的逻辑比较简单，先取本地快照文件中的配置，如果本地文件不存在或者内容为空，则再通过HTTP请求从远端拉取对应dataId配置数据，并保存到本地快照中，请求默认重试3次，超时时间3s。

![c3ce40028cb651ed948e63672ac06d4b.png][]

获取配置有`getConfig()`和`getConfigAndSignListener()`这两个接口，但`getConfig()`只是发送普通的HTTP请求，而`getConfigAndSignListener()`则多了发起长轮询和对dataId数据变更注册监听的操作`addTenantListenersWithContent()`。

@Override
    public String getConfig(String dataId, String group, long timeoutMs) throws NacosException {
        return getConfigInner(namespace, dataId, group, timeoutMs);
    }
    
    @Override
    public String getConfigAndSignListener(String dataId, String group, long timeoutMs, Listener listener)
            throws NacosException {
        String content = getConfig(dataId, group, timeoutMs);
        worker.addTenantListenersWithContent(dataId, group, content, Arrays.asList(listener));
        return content;
    }

**注册监听**

客户端注册监听，先从`cacheMap`中拿到`dataId`对应的`CacheData`对象。

public void addTenantListenersWithContent(String dataId, String group, String content,
                                              List<? extends Listener> listeners) throws NacosException {
        group = blank2defaultGroup(group);
        String tenant = agent.getTenant();
        // 1、获取dataId对应的CacheData，如没有则向服务端发起长轮询请求获取配置
        CacheData cache = addCacheDataIfAbsent(dataId, group, tenant);
        synchronized (cache) {
            // 2、注册对dataId的数据变更监听
            cache.setContent(content);
            for (Listener listener : listeners) {
                cache.addListener(listener);
            }
            cache.setSyncWithServer(false);
            agent.notifyListenConfig();
        }
    }

如没有则向服务端发起长轮询请求获取配置，默认的`Timeout`时间为30s，并把返回的配置数据回填至`CacheData`对象的content字段，同时用content生成MD5值；再通过`addListener()`注册监听器。

![fb400ea563f443ea87adb88fbc521de4.png][]

`CacheData`也是个出场频率非常高的一个类，我们看到除了dataId、group、tenant、content这些相关的基础属性，还有几个比较重要的属性如：`listeners`、`md5`(content真实配置数据计算出来的md5值)，以及注册监听、数据比对、服务端数据变更通知操作都在这里。

![ff0c20f19ef195d85fde3e97d28ca645.png][]

其中`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`对象，那么大胆猜测下一定会有专门的任务来处理这个数据结构。

![1e24071fdee11148a01fccb111775350.png][]

**变更通知**

客户端又是如何感知服务端数据已变更呢？

我们还是从头看，`NacosConfigService`类的构造器中初始化了一个`ClientWorker`，而在`ClientWorker`类的构造器中又启动了一个线程池来轮询`cacheMap`。

![3fedd2515720a43bec87bb3731849aae.png][]

而在`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`注册过监听的客户端推送变更后的数据内容。

![5329e5848affdbd16ba1596f730107eb.png][]

客户端接收通知，直接实现`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`往下看。

![268af6132e8ac051ec9a93f970c9c8da.png][]

服务端根据请求`header`中的`Long-Pulling-Timeout`属性来区分请求是长轮询还是短轮询，这里咱们只关注长轮询部分，接着看`LongPollingService`（记住这个service很关键）类中的`addLongPollingClient()`方法是如何处理客户端的长轮询请求的。

![600dee42b592c59610c87af0f4fa8e3f.png][]

正常客户端默认设置的请求超时时间是`30s`，但这里我们发现服务端“偷偷”的给减掉了`500ms`，现在超时时间只剩下了`29.5s`，那为什么要这样做呢？

用官方的解释之所以要提前500ms响应请求，为了最大程度上保证客户端不会因为网络延时造成超时，考虑到请求可能在负载均衡时会耗费一些时间，毕竟`Nacos`最初就是按照阿里自身业务体量设计的嘛！

![05c2d1feeec9deb0b557d719886efdd2.png][]

此时对客户端提交上来的`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线程不再需要一直阻塞，等待业务处理完毕才输出响应；可以先释放容器分配给请求的线程与相关资源，减轻系统负担，其响应将被延后，在处理完业务或者运算后再对客户端进行响应。

![d4b54839225b394e228b33494aeae33b.png][]

`ClientLongPolling`任务被提交进入延迟线程池执行的同时，服务端会通过一个`allSubs`队列保存所有正在被挂起的客户端长轮询请求任务，这个是客户端注册监听的过程。

如延时期间客户端据数一直未变化，延时时间到达后将本次长轮询任务从`allSubs`队列剔除，并响应请求`response`，这是`取消监听`。收到响应后客户端再次发起长轮询，循环往复。

![4ff3473e90e7fe69ab2ca1d1d52bec31.png][] 处理长轮询

到这我们知道服务端是如何挂起客户端长轮询请求的，一旦请求在挂起期间，用户通过管理平台操作了配置项，或者服务端收到了来自其他客户端节点修改配置的请求。

怎么能让对应已挂起的任务立即取消，并且及时通知客户端数据发生了变更呢？

**数据变更**

管理平台或者客户端更改配置项接位置`ConfigController`中的`publishConfig`方法。

![5bb16f47662f91e1fcd91b7b559109f4.png][]

值得注意得是，在`publishConfig`接口中有这么一段逻辑，某个`dataId`配置数据被修改时会触发一个数据变更事件`Event`。

ConfigChangePublisher.notifyConfigChange(new ConfigDataChangeEvent(false, dataId, group, tenant, time.getTime()));

仔细看`LongPollingService`会发现在它的构造方法中，正好订阅了数据变更事件，并在事件触发时执行一个数据变更调度任务`DataChangeTask`。

![7fc01d24d42519a809fa630fce2b2876.png][] 订阅数据变更事件

`DataChangeTask`内的主要逻辑就是遍历`allSubs`队列，上边我们知道，这个队列中维护的是所有客户端的长轮询请求任务，从这些任务中找到包含当前发生变更的`groupkey`的`ClientLongPolling`任务，以此实现数据更变推送给客户端，并从`allSubs`队列中剔除此长轮询任务。

![86b147a99d49190b41736e35910c38c4.png][] DataChangeTask

而我们在看给客户端响应`response`时，调用`asyncContext.complete()`结束了异步请求。

![b82dbb3bbccbb806b37108f0cd118798.png][]

### 结束语 ###

上边只揭开了`nacos`配置中心的冰山一角，实际上还有非常多重要的技术细节都没提及到，建议大家没事看看源码，源码不需要通篇的看，只要抓住核心部分就够了。就比如今天这个题目以前我真没太在意，突然被问一下子吃不准了，果断看下源码，而且这样记忆比较深刻（别人嚼碎了喂你的知识总是比自己咀嚼的差那么点意思）。

`nacos`的源码我个人觉得还是比较**朴素**的，代码并没有过多炫技，看起来相对轻松。大家不要对看源码有什么抵触，它也不过是别人写的业务代码而已，**just so so**!

![b0c3270d0d99c38dcce02e0c62751e02.png][]

[0323c3a2add989ac12c72d427ab344b6.png]: /images/20220829/ae87ffa34f6942a8b213590728509955.png
[c0f6f591c564a4df32cbdb4e5368e92f.png]: /images/20220829/83dc80f8c974471db60f3174310fd4ea.png
[a628b3ca85fcc933b51b00fa2666e1d6.png]: /images/20220829/d775bbe5ae224129be95c5460cdf72ce.png
[a475ca2efab5e14a3a6a6864cb33ff22.png]: /images/20220829/d3e3576224464b10920f7c87239c50c9.png
[80c243cc5eb8ddb64698714ecd82cb24.png]: /images/20220829/3761a0b528524aeaab75f718f28a4ff5.png
[5702f60155f1d7d017494feb43bec11c.png]: /images/20220829/f02555e59fde4d2aae5361e010614bd3.png
[525f1fec094e57b6aca7213074ef817e.png]: /images/20220829/0d9e70a0ba124d17b41e633992341780.png
[b6c6be6ef5601a67ad0a57a4b9710f0c.png]: /images/20220829/f9c7a4887d2d40f082982d3ef7d33d9a.png
[ccc72a9ac0e0838206c5756397257fb3.png]: /images/20220829/c63b2ef6eae24a82b57ff9b6dfa95467.png
[160e3b5f70e350ace0fe908f8bb24bf1.png]: /images/20220829/5cb1fa24dc564a41b16a5d0a4911a9af.png
[5636d0d3a906949c87bd8b411295e087.png]: /images/20220829/52d28949501c42e4a39f815662763f67.png
[d7e33271f6ed6933e6dbdf9e21945f61.png]: /images/20220829/14b92995dc644432b7cf2a0fda686eb8.png
[a09213f01b2b53c79dd1254c828e53bb.png]: /images/20220829/289a24a252b648b495030c30e9830528.png
[c3ce40028cb651ed948e63672ac06d4b.png]: /images/20220829/437fe0bf2e274754b83874a7e4daba91.png
[fb400ea563f443ea87adb88fbc521de4.png]: /images/20220829/abf304300ff7470ea26a27b7e2217ec9.png
[ff0c20f19ef195d85fde3e97d28ca645.png]: /images/20220829/b742e19be2a14777a7446f4b6e8c29cd.png
[1e24071fdee11148a01fccb111775350.png]: /images/20220829/823ac945c6ed4aac835f5aa7caf54907.png
[3fedd2515720a43bec87bb3731849aae.png]: /images/20220829/6f13da110ee74039bba3f398e0be3052.png
[5329e5848affdbd16ba1596f730107eb.png]: /images/20220829/124efb55ab144bbabd28bf023ab287ac.png
[268af6132e8ac051ec9a93f970c9c8da.png]: /images/20220829/27c75107ff9b4db3ae853fcab980a22d.png
[600dee42b592c59610c87af0f4fa8e3f.png]: /images/20220829/ca2bee0d758d4c0fabc566d360a2baf7.png
[05c2d1feeec9deb0b557d719886efdd2.png]: /images/20220829/f09c64a0d58c4c8cb9c5aac2e6ecfe56.png
[d4b54839225b394e228b33494aeae33b.png]: /images/20220829/a461c07c0a204de88810a77385d27e09.png
[4ff3473e90e7fe69ab2ca1d1d52bec31.png]: /images/20220829/51773235674f4a4caa597605e1647937.png
[5bb16f47662f91e1fcd91b7b559109f4.png]: /images/20220829/a249b65fc23a4f2f9560fc957bc94c66.png
[7fc01d24d42519a809fa630fce2b2876.png]: /images/20220829/6d8e1848305d4549afbc44152883a482.png
[86b147a99d49190b41736e35910c38c4.png]: /images/20220829/2564adcacb924461b25e4883f55c9ce9.png
[b82dbb3bbccbb806b37108f0cd118798.png]: /images/20220829/aabb9ec336a9430ea0df2bb118eba914.png
[b0c3270d0d99c38dcce02e0c62751e02.png]: /images/20220829/3d11bafbd93645c7880f275561f5fcbd.png