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请求设置较大的请求超时时间,来监听数据的变化,不需要引入额外的中间件,但是每次都是全量更新数据,数据量较大的时候性能可能比较一般。