阅读 1564

Java编程方法论-Spring WebFlux篇 01 为什么需要Spring WebFlux 上

前言

本系列为本人Java编程方法论 响应式解读系列的Webflux部分,现分享出来,前置知识Rxjava2 ,Reactor的相关解读已经录制分享视频,并发布在b站,地址如下:

Rxjava源码解读与分享:www.bilibili.com/video/av345…

Reactor源码解读与分享:www.bilibili.com/video/av353…

NIO源码解读相关视频分享: www.bilibili.com/video/av432…

NIO源码解读视频相关配套文章:

BIO到NIO源码的一些事儿之BIO

BIO到NIO源码的一些事儿之NIO 上

BIO到NIO源码的一些事儿之NIO 中

BIO到NIO源码的一些事儿之NIO 下 之 Selector BIO到NIO源码的一些事儿之NIO 下 Buffer解读 上 BIO到NIO源码的一些事儿之NIO 下 Buffer解读 下

其中,Rxjava与Reactor作为本人书中内容将不对外开放,大家感兴趣可以花点时间来观看视频,本人对着两个库进行了全面彻底细致的解读,包括其中的设计理念和相关的方法论,也希望大家可以留言纠正我其中的错误。

为什么需要Spring WebFlux

在我们要面临越来越高的并发处理,传统的Spring Web MVC已经无法满足我们的需求,即我们需要一个无阻塞的且通过很少的硬件资源(体现就是通过很少数量的线程)的web框架来处理并发任务。Servlet 3.1确实为非阻塞I/O提供了相应API。但是,使用它时,Servlet 其余部分API的在执行时就是同步(比如Filter)或阻塞(getParametergetPart)。 我们知道,Tomcat这类服务器其有一个Servlet Worker线程池,而使用Spring Web MVC的话,对于请求的处理过程将会在DispatcherServlet中进行,而其内部默认并不会进行异步处理,所以,当有I/O或者耗时操作的时候,很可能会阻塞当前Servlet所在线程。(参考网上关于SpringMVC异步操作的相关博文),关于其异步改造,本人也在RxJava2的相关分享视频的项目实例中进行有改造,大家可回顾。而我们的目的就是将当前Servlet所在线程给让出来,这样可以接收更多的请求。 那两者的区别到底在什么地方,Spring WebFlux到底有何意义可供我们迁移学习。相信大家在接触过Tomcat之后,都会去学习一下Tomcat的配置文件server.xml,从中我们也知道Connector,其主要功能是:接收连接请求,创建RequestResponse对象用于和请求端交换数据;然后分配线程让Servlet容器来处理这个请求,并把产生的RequestResponse对象传给Servlet。当Servlet处理完请求后,也会通过Connector将响应返回给客户端。 所以我们从Connector入手,讨论一些与Connector有关问题,包括NIO/BIO模式、线程池、连接数等。 根据协议的不同,Connector可以分为HTTP ConnectorAJP Connector等,此处只讨论HTTP Connector

Tomcat下Connector中的协议

Connector在处理HTTP请求时,会使用不同的protocol。不同的Tomcat版本支持的protocol不同,其中典型的protocol包括BIO、NIO和APR(Tomcat7中支持这3种,Tomcat8增加了对NIO2的支持,而在Tomcat8.5Tomcat9.0,则去掉了对BIO的支持)。

Connector使用哪种protocol,可以通过Tomcat配置文件server.xml中的<connector>元素中的protocol属性进行指定,也可以使用默认值。如果没有指定protocol,则使用默认值HTTP/1.1,其含义如下:在Tomcat7中,自动选取使用BIOAPR(如果找到APR需要的本地库,则使用APR,否则使用BIO);在Tomcat8中,自动选取使用NIOAPR(如果找到APR需要的本地库,则使用APR,否则使用NIO)。

无论是BIO,还是NIOConnector处理请求的大致流程是一样的:在accept队列中接收连接(当客户端向服务器发送请求时,如果客户端与服务端完成三次握手建立了连接,则服务端将该连接放入accept队列);在连接中获取请求的数据,生成request;调用Servlet容器处理请求;返回response。

为了便于大家的理解,这里先明确一下连接与请求的关系:

  • 连接是TCP层面的(传输层),对应socket
  • 请求是HTTP层面的(应用层),必须依赖于TCP的连接实现。
  • 一个TCP连接中可能传输多个HTTP请求。

BIO是Blocking IO,顾名思义是阻塞的IO;NIO是Non-blocking IO,则是非阻塞的IO。而APR是Apache Portable Runtime,是Apache可移植运行库,利用本地库可以实现高可扩展性、高性能;Apr是在Tomcat上运行高并发应用的首选模式,但是需要安装apr、apr-utils、tomcat-native等包。

BIO实现的Connector中,请求主要是由JioEndpoint对象来处理。JioEndpoint维护了AcceptorWorker,通过Acceptor接收socket,然后从Worker线程池中找出空闲的线程处理socket,如果worker线程池没有空闲线程,则Acceptor将阻塞。其中WorkerTomcat自带的线程池,如果通过<Executor>配置了其他线程池,原理与Worker类似。

NIO实现的Connector中,处理请求的主要实体是NIOEndpoint对象。NIOEndpoint中除了包含AcceptorWorker外,还是用了Poller,处理流程如下图所示:

图中AcceptorWorker分别是以线程池形式存在,Poller是一个单线程(此处是其与Netty最大的区别)。注意,与BIO的实现一样,这里,需要提及的是,在server.xml中没有配置<Executor>,则以Worker线程池运行,如果配置了<Executor>,则以基于java.util.concurrent.ThreadPoolExecutor线程池运行。

由图可知,Acceptor接收socket后(这里虽然是基于NIOconnector,但是在接收socket方面还是传统的serverSocket.accept()方式,获得SocketChannel对象,然后封装在一个tomcatorg.apache.tomcat.util.net.NIOChannel实现类对象,并将之包装为一个PollerEvent对象),并不是直接使用Worker中的线程处理请求,而是先将PollerEvent对象发送给了Poller,而Poller是实现NIO的关键。AcceptorPoller发送包装后的请求通过添加队列的操作实现,这里使用了典型的生产者-消费者模式。同时,在Poller中,维护了一个Selector对象;当Poller从队列中取出socket后,注册到该Selector中;然后通过遍历Selector,找出其中可读的socket,并使用Worker中的线程处理相应请求。与BIO类似,Worker也可以被自定义的线程池代替。

通过上述过程可以看出,在NIOEndpoint处理请求的过程中,无论是Acceptor接收socket,还是线程处理请求(添加到Poller队列是同步的),使用的仍然是阻塞方式;但在读取socket并交给Worker中的线程的这个过程中,使用非阻塞的NIO实现,这是NIO模式与BIO模式的最主要区别(其他区别对性能影响较小)。而也是由于这个区别,在并发量较大的情形下可以给Tomcat效率带来显著提升。

目前大多数HTTP请求使用的是长连接(HTTP/1.1默认keep-alivetrue),而长连接意味着,一个TCPsocket在当前请求结束后,如果没有新的请求到来,socket不会立马释放,而是等timeout后再释放。如果使用BIO读取socket并交给Worker中的线程这个过程是阻塞的,也就意味着在socket等待下一个请求或等待释放的过程中,处理这个socket的工作线程会一直被占用,无法释放;因此Tomcat可以同时处理的socket数目不能超过最大线程数,性能受到了极大限制。而使用NIO,读取socket并交给Worker中的线程这个过程是非阻塞的(是由Poller所在线程维护的),并不会占用工作线程,因此Tomcat可以同时处理的socket数目不受最大线程数约束,并发性能也就大大提高,但Poller同时也是其性能瓶颈。

因此,随着NIO所实现Connector的引入,客户端到服务器的通信是非阻塞的,但是服务器到servlet的连接仍然是阻塞的,也就意味着每个请求都会阻塞一个线程,也就导致我们会看到一个线程处理一个请求的模型。 因此,随着Servlet容器的发展,Servlet API也就需要非阻塞支持,也就是Servlet 3.1+

关于TomcatConnector的更多深入解读,有感兴趣的可以参考本人的另一篇博文tomcat从启动到接轨Servlet二三事

关注下面的标签,发现更多相似文章
评论