soul网关源码学习08-http长轮询数据同步

soul网关源码学习08-http长轮询数据同步

目标：

• 梳理http长轮询数据同步流程
• 分析http长轮询原理

一、数据流向分析

• soul-admin启动的时候会创建一个定时任务，这个任务每隔5分钟全量更新一次缓存的数据。
• soul-bootstrap启动的时候会发起一个http请求，从soul-admin拿到全量的数据，然后更新到缓存。
• soul-bootstrap启动之后会定时的发起http长轮询到soul-admin，如果有数据修改，把全量数据返回，然后更新到缓存。
  

二、数据同步流程

• 启动admin，加载事件分发器DataChangedEventDispatcher
• 实例化DataChangedListener的实现类HttpLongPollingDataChangedListener，开始监听admin数据的变化。
• 创建一个线程池，加载完bean之后启动线程，每5分钟执行一次把数据库数据更新到本地缓存ConfigDataCache。
• 初始化ConfigController，创建两个用于长轮询的接口listen和fetch。
• 启动bootstrap，加载http长轮询数据同步类HttpSyncDataService。
• 创建一个线程池，执行HttpLongPollingTask。
• 请求listen接口（细节先跳过），若有数据更新，则请求fetch接口拉取全量数据更新到缓存。
• admin和bootstrap都启动之后，修改admin的数据，会触发事件监听，admin会把数据更新到本地缓存ConfigDataCache，bootstrap监听到数据变化就拉取最新的全量。
  

三、启动项目

修改soul-admin的配置，然后启动项目

  sync:
      http:
        enabled: true

修改soul-bootstrap的配置，然后启动项目

sync:
    http:
        url : http://localhost:9095

打开系统http://localhost:9095，任意修改一个配置，可以看到控制台都会打印出同步数据的日志，下面就来看一下到底是怎么实现数据同步的。

四、源码分析

启动soul-admin

首先从soul-admin启动入手，找到数据同步的配置类DataSyncConfiguration，找到http长轮询的内部类。

    @Configuration
    @ConditionalOnProperty(name = "soul.sync.http.enabled", havingValue = "true")
    @EnableConfigurationProperties(HttpSyncProperties.class)
    static class HttpLongPollingListener {
        @Bean
        @ConditionalOnMissingBean(HttpLongPollingDataChangedListener.class)
        public HttpLongPollingDataChangedListener httpLongPollingDataChangedListener(final HttpSyncProperties httpSyncProperties) {
            return new HttpLongPollingDataChangedListener(httpSyncProperties);
        }
    }

这里要实例化HttpLongPollingDataChangedListener，进入这个bean看一下里面做了哪些操作，这里创建了一个线程池，然后接着往下看这个线程池有什么用。

    public HttpLongPollingDataChangedListener(final HttpSyncProperties httpSyncProperties) {
        this.clients = new ArrayBlockingQueue<>(1024);
        this.scheduler = new ScheduledThreadPoolExecutor(1,
                SoulThreadFactory.create("long-polling", true));
        this.httpSyncProperties = httpSyncProperties;
    }

接着到afterInitialize这个方法，这是bean实例化之后执行的方法，可以看到这里用线程池开启了一个定时任务，时间为5分钟。这个定时任务做了什么操作呢，看这个refreshLocalCache方法。

    protected void afterInitialize() {
        long syncInterval = httpSyncProperties.getRefreshInterval().toMillis();
        // Periodically check the data for changes and update the cache
        scheduler.scheduleWithFixedDelay(() -> {
            log.info("http sync strategy refresh config start.");
            try {
                this.refreshLocalCache();
                log.info("http sync strategy refresh config success.");
            } catch (Exception e) {
                log.error("http sync strategy refresh config error!", e);
            }
        }, syncInterval, syncInterval, TimeUnit.MILLISECONDS);
        log.info("http sync strategy refresh interval: {}ms", syncInterval);
    }

这一看，就是更新全量的数据到缓存，看一下updateAppAuthCache方法，就是更新缓存的操作，其他的类似。

    private void refreshLocalCache() {
        this.updateAppAuthCache();
        this.updatePluginCache();
        this.updateRuleCache();
        this.updateSelectorCache();
        this.updateMetaDataCache();
    }

    protected void updateAppAuthCache() {
        this.updateCache(ConfigGroupEnum.APP_AUTH, appAuthService.listAll());
    }

看一下更新缓存的具体方法，这里还计算了md5值，这个md5值应该是用来比较数据有没有被修改的，然后把最新的值放到ConfigDataCache里面。

    protected <T> void updateCache(final ConfigGroupEnum group, final List<T> data) {
        String json = GsonUtils.getInstance().toJson(data);
        ConfigDataCache newVal = new ConfigDataCache(group.name(), json, Md5Utils.md5(json), System.currentTimeMillis());
        ConfigDataCache oldVal = CACHE.put(newVal.getGroup(), newVal);
        log.info("update config cache[{}], old: {}, updated: {}", group, oldVal, newVal);
    }

总结一下就是soul-admin启动了一个间隔5分钟的定时任务，去全量的更新数据到缓存。

启动soul-bootstrap

继续找http同步数据的配置文件，找到HttpSyncDataConfiguration这个类，加载了一个bean。

    @Bean
    public SyncDataService httpSyncDataService(final ObjectProvider<HttpConfig> httpConfig, final ObjectProvider<PluginDataSubscriber> pluginSubscriber,
                                           final ObjectProvider<List<MetaDataSubscriber>> metaSubscribers, final ObjectProvider<List<AuthDataSubscriber>> authSubscribers) {
        log.info("you use http long pull sync soul data");
        return new HttpSyncDataService(Objects.requireNonNull(httpConfig.getIfAvailable()), Objects.requireNonNull(pluginSubscriber.getIfAvailable()),
                metaSubscribers.getIfAvailable(Collections::emptyList), authSubscribers.getIfAvailable(Collections::emptyList));
    }

接着看HttpSyncDataService这个类，前面都是各种初始化的操作，主要看start方法。

    public HttpSyncDataService(final HttpConfig httpConfig, final PluginDataSubscriber pluginDataSubscriber,
                               final List<MetaDataSubscriber> metaDataSubscribers, final List<AuthDataSubscriber> authDataSubscribers) {
        this.factory = new DataRefreshFactory(pluginDataSubscriber, metaDataSubscribers, authDataSubscribers);
        this.httpConfig = httpConfig;
        this.serverList = Lists.newArrayList(Splitter.on(",").split(httpConfig.getUrl()));
        this.httpClient = createRestTemplate();
        this.start();
    }

可以看注释，首先去拿到所有的配置，把配置分成不同的组（我们将插件、规则、流量配置、用户配置数据分成不同的组），然后根据配置组创建线程池，每个组启动一个http长轮询。

    private void start() {
        // It could be initialized multiple times, so you need to control that.
        if (RUNNING.compareAndSet(false, true)) {
            // fetch all group configs.
            this.fetchGroupConfig(ConfigGroupEnum.values());
            int threadSize = serverList.size();
            this.executor = new ThreadPoolExecutor(threadSize, threadSize, 60L, TimeUnit.SECONDS,
                    new LinkedBlockingQueue<>(),
                    SoulThreadFactory.create("http-long-polling", true));
            // start long polling, each server creates a thread to listen for changes.
            this.serverList.forEach(server -> this.executor.execute(new HttpLongPollingTask(server)));
        } else {
            log.info("soul http long polling was started, executor=[{}]", executor);
        }
    }

接着看一下所有的配置是怎么拿的，轮询所有的服务，这里只配了一个，看一下doFetchGroupConfig方法。

    private void fetchGroupConfig(final ConfigGroupEnum... groups) throws SoulException {
        for (int index = 0; index < this.serverList.size(); index++) {
            String server = serverList.get(index);
            try {
                this.doFetchGroupConfig(server, groups);
                break;
            } catch (SoulException e) {
                // no available server, throw exception.
                if (index >= serverList.size() - 1) {
                    throw e;
                }
                log.warn("fetch config fail, try another one: {}", serverList.get(index + 1));
            }
        }
    }

这里其实就是发起一个http请求去拿到所有的配置数据，然后去更新到缓存，具体更新的细节先不细看。

    private void doFetchGroupConfig(final String server, final ConfigGroupEnum... groups) {
        StringBuilder params = new StringBuilder();
        for (ConfigGroupEnum groupKey : groups) {
            params.append("groupKeys").append("=").append(groupKey.name()).append("&");
        }
        String url = server + "/configs/fetch?" + StringUtils.removeEnd(params.toString(), "&");
        log.info("request configs: [{}]", url);
        String json = null;
        try {
            json = this.httpClient.getForObject(url, String.class);
        } catch (RestClientException e) {
            String message = String.format("fetch config fail from server[%s], %s", url, e.getMessage());
            log.warn(message);
            throw new SoulException(message, e);
        }
        // update local cache
        boolean updated = this.updateCacheWithJson(json);
        if (updated) {
            log.info("get latest configs: [{}]", json);
            return;
        }
        // not updated. it is likely that the current config server has not been updated yet. wait a moment.
        log.info("The config of the server[{}] has not been updated or is out of date. Wait for 30s to listen for changes again.", server);
        ThreadUtils.sleep(TimeUnit.SECONDS, 30);
    }

这个/configs/fetch接口在soul-admin的ConfigController，返回全量的配置信息数据。

    @GetMapping("/fetch")
    public SoulAdminResult fetchConfigs(@NotNull final String[] groupKeys) {
        Map<String, ConfigData<?>> result = Maps.newHashMap();
        for (String groupKey : groupKeys) {
            ConfigData<?> data = longPollingListener.fetchConfig(ConfigGroupEnum.valueOf(groupKey));
            result.put(groupKey, data);
        }
        return SoulAdminResult.success(SoulResultMessage.SUCCESS, result);
    }

http长轮询

启动soul-bootstrap拿到所量的数据之后，后续会有http长轮询定时的取数据，看一下怎么实现的。

前面已经用线程池开启了长轮询的定时任务了，具体看一下这个HttpLongPollingTask类，是一个内部类，实现了Runnable接口，单独启动了一个线程。

class HttpLongPollingTask implements Runnable

接着看一下线程的run方法，有三次建立长轮询的机会，中间间隔5秒，如果三次失败，需要等待5分钟才能继续。

        public void run() {
            while (RUNNING.get()) {
                for (int time = 1; time <= retryTimes; time++) {
                    try {
                        doLongPolling(server);
                    } catch (Exception e) {
                        // print warnning log.
                        if (time < retryTimes) {
                            log.warn("Long polling failed, tried {} times, {} times left, will be suspended for a while! {}",
                                    time, retryTimes - time, e.getMessage());
                            ThreadUtils.sleep(TimeUnit.SECONDS, 5);
                            continue;
                        }
                        // print error, then suspended for a while.
                        log.error("Long polling failed, try again after 5 minutes!", e);
                        ThreadUtils.sleep(TimeUnit.MINUTES, 5);
                    }
                }
            }
            log.warn("Stop http long polling.");
        }

看一下这个类的doLongPolling，在长轮询的时候做了什么。简单来说，就是调用了/configs/listener这个接口，监听有没有数据变化，如果有，就去调用前面的那个fetch接口去拿到全量的数据。

    private void doLongPolling(final String server) {
        MultiValueMap<String, String> params = new LinkedMultiValueMap<>(8);
        for (ConfigGroupEnum group : ConfigGroupEnum.values()) {
            ConfigData<?> cacheConfig = factory.cacheConfigData(group);
            String value = String.join(",", cacheConfig.getMd5(), String.valueOf(cacheConfig.getLastModifyTime()));
            params.put(group.name(), Lists.newArrayList(value));
        }
        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);
        HttpEntity httpEntity = new HttpEntity(params, headers);
        String listenerUrl = server + "/configs/listener";
        log.debug("request listener configs: [{}]", listenerUrl);
        JsonArray groupJson = null;
        try {
            String json = this.httpClient.postForEntity(listenerUrl, httpEntity, String.class).getBody();
            log.debug("listener result: [{}]", json);
            groupJson = GSON.fromJson(json, JsonObject.class).getAsJsonArray("data");
        } catch (RestClientException e) {
            String message = String.format("listener configs fail, server:[%s], %s", server, e.getMessage());
            throw new SoulException(message, e);
        }
        if (groupJson != null) {
            // fetch group configuration async.
            ConfigGroupEnum[] changedGroups = GSON.fromJson(groupJson, ConfigGroupEnum[].class);
            if (ArrayUtils.isNotEmpty(changedGroups)) {
                log.info("Group config changed: {}", Arrays.toString(changedGroups));
                this.doFetchGroupConfig(server, changedGroups);
            }
        }
    }

然后看一下soul-admin的/configs/listener这个接口。

    @PostMapping(value = "/listener")
    public void listener(final HttpServletRequest request, final HttpServletResponse response) {
        longPollingListener.doLongPolling(request, response);
    }

看一下doLongPolling这个方法，比较现在最新的数据和缓存的数据的md5值，如果不一致，直接返回，也就是长轮询结束，响应客户端返回数据，如果一致，说明数据没有修改，继续监听数据变化情况，这里使用了servlet3.0的异步响应机制，阻塞了客户端请求的线程。

    public void doLongPolling(final HttpServletRequest request, final HttpServletResponse response) {

        // compare group md5
        List<ConfigGroupEnum> changedGroup = compareChangedGroup(request);
        String clientIp = getRemoteIp(request);

        // response immediately.
        if (CollectionUtils.isNotEmpty(changedGroup)) {
            this.generateResponse(response, changedGroup);
            log.info("send response with the changed group, ip={}, group={}", clientIp, changedGroup);
            return;
        }

        // listen for configuration changed.
        final AsyncContext asyncContext = request.startAsync();

        // AsyncContext.settimeout() does not timeout properly, so you have to control it yourself
        asyncContext.setTimeout(0L);

        // block client's thread.
        scheduler.execute(new LongPollingClient(asyncContext, clientIp, HttpConstants.SERVER_MAX_HOLD_TIMEOUT));
    }

走到这里，整个http长轮询的流程基本就已经走完了。

五、深入解析

这里参考官网的数据同步设计：https://dromara.org/zh/projects/soul/data-sync/

http长轮询机制如上所示，soul-web 网关请求admin的配置服务，读取超时时间为 90s，意味着网关层请求配置服务最多会等待 90s，这样便于admin配置服务及时响应变更数据，从而实现准实时推送。

http请求到达sou-admin之后，并非立马响应数据，而是利用 Servlet3.0 的异步机制，异步响应数据。首先，将长轮询请求任务LongPollingClient扔到BlocingQueue中，并且开启调度任务，60s 后执行，这样做的目的是 60s 后将该长轮询请求移除队列，即便是这段时间内没有发生配置数据变更。因为即便是没有配置变更，也得让网关知道，总不能让其干等吧，而且网关请求配置服务时，也有 90s 的超时时间。

public void doLongPolling(final HttpServletRequest request, final HttpServletResponse response) {
    // 因为soul-web可能未收到某个配置变更的通知，因此MD5值可能不一致，则立即响应
    List<ConfigGroupEnum> changedGroup = compareMD5(request);
    String clientIp = getRemoteIp(request);
    if (CollectionUtils.isNotEmpty(changedGroup)) {
        this.generateResponse(response, changedGroup);
        return;
    }

    // Servlet3.0异步响应http请求
    final AsyncContext asyncContext = request.startAsync();
    asyncContext.setTimeout(0L);
    scheduler.execute(new LongPollingClient(asyncContext, clientIp, 60));
}

class LongPollingClient implements Runnable {
    LongPollingClient(final AsyncContext ac, final String ip, final long timeoutTime) {
        // 省略......
    }
    @Override
    public void run() {
        // 加入定时任务，如果60s之内没有配置变更，则60s后执行，响应http请求
        this.asyncTimeoutFuture = scheduler.schedule(() -> {
            // clients是阻塞队列，保存了来自soul-web的请求信息
            clients.remove(LongPollingClient.this);
            List<ConfigGroupEnum> changedGroups = HttpLongPollingDataChangedListener.compareMD5((HttpServletRequest) asyncContext.getRequest());
            sendResponse(changedGroups);
        }, timeoutTime, TimeUnit.MILLISECONDS);
        //
        clients.add(this);
    }
}

如果这段时间内，管理员变更了配置数据，此时，会挨个移除队列中的长轮询请求，并响应数据，告知是哪个 Group 的数据发生了变更（我们将插件、规则、流量配置、用户配置数据分成不同的组）。网关收到响应信息之后，只知道是哪个 Group 发生了配置变更，还需要再次请求该 Group 的配置数据。有人会问，为什么不是直接将变更的数据写出？因为 http 长轮询机制只能保证准实时，如果在网关层处理不及时，或者管理员频繁更新配置，很有可能便错过了某个配置变更的推送，安全起见，我们只告知某个 Group 信息发生了变更。

// soul-admin发生了配置变更，挨个将队列中的请求移除，并予以响应
class DataChangeTask implements Runnable {
    DataChangeTask(final ConfigGroupEnum groupKey) {
        this.groupKey = groupKey;
    }
    @Override
    public void run() {
        try {
            for (Iterator<LongPollingClient> iter = clients.iterator(); iter.hasNext(); ) {
                LongPollingClient client = iter.next();
                iter.remove();
                client.sendResponse(Collections.singletonList(groupKey));
            }
        } catch (Throwable e) {
            LOGGER.error("data change error.", e);
        }
    }
}

当soul-web网关层接收到 http 响应信息之后，拉取变更信息（如果有变更的话），然后再次请求soul-admin的配置服务，如此反复循环。

六、总结

http长轮询的同步方式，利用http请求设置较大的请求超时时间，来监听数据的变化，不需要引入额外的中间件，但是每次都是全量更新数据，数据量较大的时候性能可能比较一般。