DeferredResult 如何实现长轮询?

今天我们就来盘一下 Spring DeferredResult,这玩意使用起来是很简单的,回答的话可深可浅。

浅一点就是直接回答它的作用,深一点的话就是原理了,而这个原理其实还需要涉及到 tomcat (默认 tomcat 为 web 容器)。

我们先来看下 DeferredResult 的作用及使用方式。

DeferredResult 的用处

DeferredResult 其实是基于 Servlet 3.0 对异步请求的支持而来的,我们来看这样一个场景:

当前 controller 里面有个方法 A,其内部逻辑依赖 redis 里面的一个值,如果 redis 里面有值了,就可以获取返回,如果没值这时候没有东西可以返回,只能返回 null,而往 redis 塞入值依赖另一个后台线程。

正常的实现我们肯定可以想到轮询的方案,即浏览器不断轮询方法 A,直到有值才停止轮询,但是有时候过于频繁的轮询会给服务器产生压力。

而这时候 DeferredResult 就可以登场啦,从名字我们就可以知道:延期的结果

我们来简单的看下使用方式:

DeferredResult 如何实现长轮询?

可以看到,只需要用 DeferredResult 包装本来需要返回的值,然后设置一个超时时间和超时兜底值即可,例子设置了 5s。

我们来实验一下,如果后台线程就睡了 100 ms ,未超过设置的超时时间,此时过了 100 ms 就立马返回值:

DeferredResult 如何实现长轮询?

如果后台线程睡了 10000 ms ,那么超过设置的超时时间,此时等待了 5 秒后,返回的是:

DeferredResult 如何实现长轮询?

可以看到,这功能符合我们的预期。

关于 DeferredResult 还有一个很重要的点:请求的处理线程(即 tomcat 线程池的线程)不会等到 DeferredResult#setResult() 被调用才释放,而是直接释放了

也就是说 tomcat 线程安排好 DeferredResult 的一些配置后,不会等逻辑处理完(DeferredResult#setResult()的调用或者超时)。

而是直接释放了,这样 tomcat 线程就被回收到线程池中了,可以响应其他请求,不会傻傻地阻塞等着 DeferredResult#setResult() 被调用或超时。

我们都知道 tomcat 的线程池大小是有限的,如果我们的一些业务逻辑处理慢的话,会渐渐地占满 tomcat 线程,这样就无法处理新的请求,所以一些处理缓慢的业务我们会放到业务线程池中处理,但单纯的放到业务线程池中处理的话,我们无法得知其什么时候处理完,也无法将处理完的结果和之前的请求匹配上,所以常做的方式就是轮询。

而 DeferredResult 的做法就类似仅把事情安排好,不会管事情做好没,tomcat 线程就释放走了,注意此时不会给请求方(如浏览器)任何响应,而是将请求存放在一边,咱先不管它,等后面有结果了再把之前的请求拿来,把值响应给请求方。

最后还有个兜底的处理,如果超时了还没把该返回的值塞进来,那么就响应请求方兜底的值。

我来画个图(注意这不是源码分析图,仅仅只是为了更好地理解 DeferredResult 的逻辑):

DeferredResult 如何实现长轮询?

看到这里想必你应该明白 DeferredResult 的用法以及它的一些特性了吧?

接下来我们看下原理。

DeferredResult 原理分析

这个原理说来话长,真要完全理解的话需要同时懂得 Tomcat 的原理和 SpringMvc 的原理,为了避免过度展开偏离主题,本文主要针对 DeferredResult 的原理。

后面有时间再补充完整 Tomcat 和 SpringMvc 的原理,有需要的可以评论区留个言,多的话我立马安排。

我打算主要用文字来描述整体的过程,会跟一些源码(如果全上源码的话我怕会看晕了,毕竟调用链路还是有点长的)

我们做到理解就行,真对源码有兴趣的可以自行研究

开始分析

一个请求先要通过 tomcat 的调度,然后才会到我们的 Spring 中来,待我们在 Spring 中处理完业务逻辑后,tomcat 才会把相关的响应返回给客户端(如浏览器)。

所以想要完成 DeferredResult 的功能,需要 tomcat 的配合,它需要晓得这是一个异步请求,在结果还未设置且没超时之前,不能将响应返回给客户端,待 DeferredResult 塞入值之后,再将请求返回给客户端。

我再贴一下示例代码,我们基于这个代码分析:

DeferredResult 如何实现长轮询?

如果你用浏览器请求调用这个方法,那么 tomcat 此时肯定不知道这是一个异步处理的请求,只会认为是正常请求进行处理。

所以正常的话是 tomcat 调用 SpringMvc 定义的​​DispatcherServlet#doDispatch​​来处理请求。

根据 url 找到 controller 处理的方法即上文的实例方法。正常处理的话,这个方法应该给浏览器直接返回我们 new 的那个 deferredResult,但显然刚才演示的结果并不是这样。

那中间发生了什么事呢?

这就涉及到 SpringMvc 的内容。当通过反射调用 controller 中的方法得到返回值的时候,需要根据返回值的类型调用不同的 ​​returnValueHandlers​​来处理。

先来解释下为什么需要 returnValueHandlers 来处理返回值。

你想想看,如果我们返回类型可能是视图名或者是被标注了 ​​@RequestBody​​的值,这两者的处理方式肯定不一样,所以需要对返回值处理下。

而Spring搞了个 returnValueHandler 是专门用来处理 DeferredResult 类型的返回值,即 ​​DeferredResultMethodReturnValueHandler​​。

这里就可以做一些操作了,可以看到支持处理的返回类型是 DeferredResult :

DeferredResult 如何实现长轮询?

从这里我们可以得知,对于 DeferredResult 返回类型其实前半部的处理和正常的返回值没有区别,区别就在于对方法的返回值做了特殊处理

我简要地说下这个 returnValueHandler 触发的操作:

它调用了 tomcat 里面 Request#startAsync 方法,也传递了 timeout 的时间,这个操作是让 tomcat 明白当前请求是一个异步请求,这样 tomcat 就不会直接将 new 的那个 deferredResult 返回给客户端,也不会销毁当前的 request 和 response 。

而是会将处理这个请求的 Processor 暂时保存起来(简单的理解为每个请求都有对应的一个 processor,这是 tomcat 里面的概念),放到 waitingProcessors 里面。

然后 tomcat 线程池就溜了,处理完了,不管了。

此时上半部的准备工作就做完了,后面有两种处理路径:

  • 一种是 timeout 了
  • 一种是在超时前调用了 DeferredResult#setResult 成功返回。

我们分别来看看两种的不同:

请求超时了

从前面我们已经得知,异步请求已经被放到 waitingProcessors 里,且超时时间也已经设置上了,而 tomcat 会有一个线程,每隔 1 秒遍历 waitingProcessors 里面的 processor ,看看它们过期了没:

DeferredResult 如何实现长轮询?

如果发现过期了,那么会重新往 tomcat 里面线程池里面投掷任务,但是这个任务不太一样,可以看到 SocketEvent 是 TIMEOUT

DeferredResult 如何实现长轮询?

这样线程池跑到这个任务的时候就知道这个已经超时请求任务,此时就会将超时值塞入到请求中(具体是通过之前设置的 DeferredResult 相关的 interceptor 中的 handleTimeout 方法)

DeferredResult 如何实现长轮询?

这个 ​​setResultInteral​​ 最终就会将值保存到请求中(实际上是请求管理的 asyncManager 里),并将该请求重新进入 ​​DispatcherServlet#doDispatch()​​ 中处理。

你看这个请求又走了一遍 doDispatch,所以 DeferredResult 类型的方法会走两遍 doDispatch 逻辑,第二次走进来的时候发现请求里面的 asyncManager 已经被放入值了。

DeferredResult 如何实现长轮询?

因为已经塞了值,所以后面处理的时候,就会走到这个 if 里面,这里面就会把原先 controller 里面方法的反射内容替换了,新建一个反射内容,这个新建的反射方法的调用是直接返回塞入的 result。

DeferredResult 如何实现长轮询?

看到没,这就是所谓的移花接木,这样还是复用了正常的处理流程,只不过后面执行的时候获得的是被塞入的超时值,且由于是正常类型,那么该怎么处理就怎么处理,最终返回给了浏览器。

请求未超时,DeferredResult#setResult

其实,​​DeferredResult#setResult​​ 和请求超时的处理逻辑是一模一样的,差别就是触发的来源不同

请求超时是 tomcat 线程池扫描到超时,然后通过 handleTimeout 调用 ​​setResultInternal​​将超时默认值塞入后重新触发 ​​DispatcherServlet#doDispatch()​​ 处理。

而 DeferredResult#setResult 是我们应用线程主动塞入值:

DeferredResult 如何实现长轮询?

实际上也是调用 ​​setResultInternal​​ ,然后重新触发 ​​DispatcherServlet#doDispatch()​​ 处理。

所以两者后面的处理逻辑一模一样!

补充

其实里面有很多源码和比较重要的点都没提及,主要是展开的话太多了,这里稍微带一下。

比如 ​​WebAsyncManager​​,这玩意就如其名是一个异步的管理器,每个请求都会 new 一个与之配对,上面也有提到一点点。

DeferredResult 如何实现长轮询?

正常请求都只会进入一次到 ​​doDispatch​​ 方法中,而异步的 DeferredResult 进入了两次,这就要保证第二次进入的时候跟第一次进入是同一个 WebAsyncManager,一些信息需要缓存对齐,并且里面还有异步处理的逻辑,比如设置值重新触发 ​​doDispatch​​ 等等。

还有 tomcat 的请求其实有个状态机在,这里就需要了解 tomcat 的相关概念。

例如开始异步处理的时候会调用:

DeferredResult 如何实现长轮询?

这个 action 底层就会调用 ​​asyncStateMachine​​ 进行操作:

DeferredResult 如何实现长轮询?

然后这种状态机最终是通知到 CoyoteAdapter 的,这也是 tomcat 里面的一个概念。

tomcat 的连接器是通过调用 CoyoteAdapter#service 来调用容器的,这里面有异步请求的处理

public void service(org.apache.coyote.Request req, org.apache.coyote.Response res)
throws Exception {

...省略部分代码....

try {
// Parse and set Catalina and configuration specific
// request parameters
postParseSuccess = postParseRequest(req, request, res, response);
if (postParseSuccess) {
// Calling the container 调用容器
connector.getService().getContainer().getPipeline().getFirst().invoke(
request, response);
}
if (request.isAsync()) { //这里就是通过状态机判断的
async = true;
.....省略部分代码....
} else {
//如果不是异步就结束了
request.finishRequest();
response.finishResponse();
}

} catch (IOException e) {
// Ignore
} finally {
.... 省略部分代码....
if (!async) {
updateWrapperErrorCount(request, response);
//不是异步就回收request和response了
request.recycle();
response.recycle();
}
}
}

最后

大概了解到这个程度差不多了,如果想要深入了解还是需要掌握挺多内容的。

用简单的话来总结下 Spring DeferredResult :如果返回值类型是 DeferredResult 则表明其是异步请求,tomcat 线程不会等到应用程序处理完或者超时,而是会立即释放线程。

而这个未处理完的请求则会暂存,tomcat 知晓其为异步请求,也不会对客户端进行响应,直至 tomcat 线程扫描到请求超时或者应用线程将 result 塞入到 DeferredResult 中。

主要原理就是 Spring 有个​​DeferredResultMethodReturnValueHandler​​,识别到返回值是 DeferredResult 类型的话,会将这个请求标记为异步请求(这是基于 tomcat 对 servlet 3.0 异步请求的支持),且暂存这个请求。

待 tomcat 每秒扫描等待的异步请求是否超时来触发是否返回默认值,或者应用线程手动塞值到 DeferredResult 触发返回,具体返回的逻辑其实是二次利用 Spring 的 ​​DispatcherServlet#doDispatch​​,进行再次分发。

利用一个 WebAsyncManager 对象与请求进行绑定,进行异步操作的管理,如返回值的保存,上下文的保存等。

通过 WebAsyncManager 状态的不同 ​​DispatcherServlet#doDispatch​​处理逻辑有所不同,判断其实异步请求、判断其是否已经有异步返回值等。

如果有了返回值则通过新建一个反射内容替换之前 request 对应的 controller 的方法,通过移花接木的方式替换反射返回的结果。

好了,就这样差不多了。

发表评论

相关文章