Nacos配置中心交互模型是 push 仍是 pull ？你应该这么回答

本文案例收录在 https://github.com/chengxy-nds/Springboot-Notebookjava

你们好，我是小富～git

对于Nacos你们应该都不太陌生，出身阿里名声在外，能作动态服务发现、配置管理，很是好用的一个工具。然而这样的技术用的人越多面试被问的几率也就越大，若是只停留在使用层面，那面试可能要吃大亏。程序员

好比咱们今天要讨论的话题，Nacos在作配置中心的时候，配置数据的交互模式是服务端推过来仍是客户端主动拉的？github

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

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

配置中心

聊Nacos以前简单回顾下配置中心的由来。网络

简单理解配置中心的做用就是对配置统一管理，修改配置后应用能够动态感知，而无需重启。数据结构

由于在传统项目中，大多都采用静态配置的方式，也就是把配置信息都写在应用内的yml或properties这类文件中，若是要想修改某个配置，一般要重启应用才能够生效。mybatis

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

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

推与拉模型

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

推模型

客户端与服务端创建TCP长链接，当服务端配置数据有变更，马上经过创建的长链接将数据推送给客户端。

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

弊端：长链接可能会由于网络问题，致使不可用，也就是俗称的假死。链接状态正常，但实际上已没法通讯，因此要有的心跳机制KeepAlive来保证链接的可用性，才能够保证配置数据的成功推送。

拉模型

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

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

长轮询

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

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

短轮询

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

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

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

长轮询

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

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

Nacos初识

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

直接执行/bin/startup.X就能够了，默认用户密码均是nacos。

几个概念

Nacos配置中心的几个核心概念：dataId、group、namespace，它们的层级关系以下图：

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

目前支持JSON、XML、YAML等多种配置格式。

group：dataId配置的分组管理，好比同在dev环境下开发，但同环境不一样分支须要不一样的配置数据，这时就能够用分组隔离，默认分组DEFAULT_GROUP。

namespace：项目开发过程当中确定会有dev、test、pro等多个不一样环境，namespace则是对不一样环境进行隔离，默认全部配置都在public里。

架构设计

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

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

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

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

下边咱们以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。

获取配置有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();
    // 一、获取dataId对应的CacheData，如没有则向服务端发起长轮询请求获取配置
    CacheData cache = addCacheDataIfAbsent(dataId, group, tenant);
    synchronized (cache) {
        // 二、注册对dataId的数据变动监听
        cache.setContent(content);
        for (Listener listener : listeners) {
            cache.addListener(listener);
        }
        cache.setSyncWithServer(false);
        agent.notifyListenConfig();
    }
}

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

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，那为何要这样作呢？

用官方的解释之因此要提早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!

我是小富～，若是对你有用在看、关注支持下，我们下期见~

整理了几百本各种技术电子书，有须要的同窗自取。技术群快满了，想进的同窗能够加我好友，和大佬们一块儿吹吹技术。

电子书地址

我的公众号： 程序员内点事，欢迎交流