1.6.1 背景
我们先来聊一下常用的几种即时通讯技术包括 轮询，长轮询，和 Websocket 三种。
1.6.1.1 轮询
轮询是客户端每隔一段时间向服务端发送请求，服务端不管是否又数据更新都会直接返回所有数据，这种方式实现起来很简单，而且服务端无需做任何改造就可以满足要求，但是会占用比较多的内存和带宽，无法承受大量客户端。
1.6.1.2 长轮询
长轮询是当服务器收到客户端发来的请求后,服务器端不会直接进行响应，而是先将这个请求挂起，然后判断服务器端数据是否有更新。如果有更新，则进行响应，如果一直没有数据，则到达一定的时间限制(服务器端设置)才返回。相比轮询，长轮询主要优点是可以减少带宽，但是服务端需进行一定的改造。
1.6.1.2 websocket
websocket 是一种比较新的网络协议，它是全双工的，在第一次客户端向服务端发送Http请求建立链接后，客户端和服务端就处于平等状态，可以相互发送数据，websocket 相比上面两种协议，无论是对服务器的CPU和内存资源的消耗，还是服务的响应及时性都要更好，但是需要服务器做的变动比较多，还需要又支持 websocket 的客户端。
1.6.2 soul Bootstrap
由于是客户端发起请求，我们先来看一下Bootstrap 客户端。我们还是根据 引入的 starter 追踪到 HttpSyncDataConfiguration 这个配置类，HttpSyncDataConfiguration 主要是初始化类 httpSyncDataService 这个bean。
httpSyncDataService 的初始化主要做了三件事，首先是初始化了所有的插件的 subscriber 订阅者，初始化 httpClinet 使用的是 OkHttp3ClientHttpRequestFactory 作为一个 Restemplate ，后面可以直接通过操作 Restemplate 进行轮询，最终调用start 方法。
start 方法先判断当前状态是否处于运行状态，保证每次只有一个客户端在轮询。
接着调用 /configs/fetch 接口先拿回全量的数据，然后更新。
这里有个有趣的地方，我们看 DataRefreshFactory 的 excite 方法，这里主要是通过stream 的 foreach 方法进行遍历，但是这里使用了一个 boolean 数组，但是只有一个元素，为什么呢，因为 lamb 表达式要求里面的所有元素都是 final 的，final 就意味着对这个元素的操作是线程安全的。但是假如是一个 final 的 boolean 那不是无法修改状态了吗，所以这里使用了一个看起来很奇怪的 boolean 数组。
接着 bootsrapt 启动一个 ThreadPoolExecutor 线程池 ，主要是执行定时刷新任务，这个线程池为每个 soul admin 服务端建立一个定时任务 HttpLongPollingTask ，所以我们知道 soul admin 和 soul bootstrap 是可以使用一个集群提供高可用保证的。
在定时任务中主要是先判断目前是处于运行中，是则进行长轮询，假如轮询失败则重试，重试超过三次就睡眠 5 min。
doLongPolling 首先为每个需要轮询的数据的MD5值和最后修改时间用逗号拼接作为请求参数，请求服务端。/configs/listener 接口，然后将拿到的数据更新到内存中。
1.6.3 soul admin
我们接着看 /configs/listener 接口 ， 这里也是调用 doLongPolling 方法。
它先比较请求的MD5值和当前的配置是否相等和最后修改时间和当前的配置是否相同，假如不同，则返回该配置组，假如都相同，这里会先取一把锁，然后从数据库里面更新最新的数据到内存中，这里主要是为了多个 soul admin 假如其中一个更新了，其他的也能同步更新，很多人会想问，这里数据是使用 concurrentHasmap 进行存储，为什么还需要加锁，这里作者解释，主要是因为存在多个 soul web 的话，可能存在同时向数据库请求，数据库的瞬时压力增大，这种情况很好理解，就像我们设置 redis 的 key 一样，不能同时设置同个过期时间，否则很容易造成缓存穿透和甚至缓存雪崩。
这里拿到所有已经更新的组信息返回。
这里假如有数据更新则立即返回数据。假如没有数据则调用 request.startAsync() 方法，这个是什么意思呢，它的作用是HTTP请求不再绑定到HTTP线程，这使我们以后可以使用更少的线程来处理它，我们拿到 asynccontext 后发给我们的线程池，这里处理该 http 请求的线程就完成了此次请求，后续需要发送数据给客户端只需要线程池进行通过操作 asynccontext 实现。
最终这里通过线程池的schedule方法，设置延时时长，到预定时间后查看缓存数据是否有更新，有则返回给客户端。
这里调用 asyncContext.complete() 整个调用才算结束。
1.6.3 总结
这一期最精彩的莫过于对request.startAsync()对运用，这里假如直接阻塞当前线程，我们知道 tomcat 处理http 请求对线程是有限的，直接阻塞假如 soul bootstrap 很多会耗尽请求线程池。这里直接放入 一个调度线程池， 这个线程池只有一个线程，当很多请求进来，他会先将它放入 BlockQueue 中，然后一个个处理，减少了线程池的开销。
