五种IO模型

计算机编程中，IO模型是描述程序与输入/输出操作之间交互方式的抽象概念。不同的IO模型可以影响程序的性能、可扩展性和资源利用效率。我们常见有五种 IO 模型：阻塞式 IO、非阻塞式 IO 、IO 多路复用、信号驱动 IO、异步 IO。

阻塞式 IO

listenfd = socket();   // 打开一个网络通信套接字
bind(listenfd);        // 绑定
listen(listenfd);      // 监听
while(1) {
  connfd = accept(listenfd);  // 阻塞 等待建立连接
  int n = read(connfd, buf);  // 阻塞 读数据
  doSomeThing(buf);  // 处理数据
  close(connfd);     // 关闭连接
}

从上面的伪代码中我们可以看出，服务端处理客户端的请求阻塞在两个地方，一个是 accept、一个是 read ，我们这里主要研究 read 的过程，可以分为两个阶段：

等待读就绪（等待数据到达网卡 & 将网卡的数据拷贝到内核缓冲区）
读数据。

read 的第一个阶段阻塞的，这就是我们常说的阻塞式 IO，即如果read 第一个阶段等待读就绪是阻塞的，我们就称为阻塞式IO:

非阻塞式 IO

伪非阻塞（多线程）

为了让上面操作中的读操作 read 不再主线程中阻塞，我们可以使用多线程实现非阻塞：

listenfd = socket();   // 打开一个网络通信套接字
bind(listenfd);        // 绑定
listen(listenfd);      // 监听
while(1) {
  connfd = accept(listenfd);  // 阻塞 等待建立连接
  newThreadDeal(connfd)       // 当有新连接建立时创建一个新线程处理连接
}

newThreadDeal(connfd){
  int n = read(connfd, buf);  // 阻塞 读数据
  doSomeThing(buf);  // 处理数据
  close(connfd);     // 关闭连接 
}

真正的非阻塞式 IO

伪非阻塞（多线程）实现方案是通过创建多线程的方式来处理不同的连接从而避免主线程阻塞，但实际上子线程内部读操作 read 还是阻塞的，这只是用户层的小把戏。
真正实现非阻塞式 IO 我们应该让操作系统提供一个非阻塞的 read() 函数，当第一阶段读未就绪时返回 -1 ，当读已就绪时才进行数据的读取。

arr = new Arr[];
listenfd = socket();   // 打开一个网络通信套接字
bind(listenfd);        // 绑定
listen(listenfd);      // 监听
while(1) {
  connfd = accept(listenfd);  // 阻塞 等待建立连接
  arr.add(connfd);
}

// 异步线程检测 连接是否可读
new Tread(){
  for(connfd : arr){
    // 非阻塞 read 最重要的是提供了我们在一个线程内管理多个文件描述符的能力
    int n = read(connfd, buf);  // 检测 connfd 是否可读
    if(n != -1){
       newThreadDeal(buf);   // 创建新线程处理
       close(connfd);        // 关闭连接 
       arr.remove(connfd);   // 移除已处理的连接
    }
  }
}

newTheadDeal(buf){
  doSomeThing(buf);  // 处理数据
}

从上面我们可以看出：所谓非阻塞 IO 是将第一阶段的等待读就绪改为非阻塞，但是第二阶段的数据读取还是阻塞的，非阻塞 read 最重要的是提供了我们在一个线程内管理多个文件描述符的能力。

IO 多路复用 (IO接口的复用)

上面服务端通过多线程的方式处理客户端请求实现了主线程的非阻塞，使用不同线程处理不同的连接请求，但是我们并没有那么多的线程资源，并且等待读就绪的过程是耗时最多的，那么有没有什么办法可以将连接保存起来，等读已就绪时我们再进行处理。

非阻塞IO却存在一个很大的问题，我们需要不断的调用 read() 进行系统调用，这里的系统调用我们可以理解为分布式系统的 RPC 调用，性能损耗十分严重，因为这依然是用户层的一些小把戏。

这时我们自然而然就会想到把上述循环检测连接（文件描述符）可读的过程交给操作系统去做，从而避免频繁的进行系统调用。当然操作系统给我们提供了这样的函数：select、poll、epoll。

select

select 是操作系统提供的系统函数，通过它我们可以将文件描述符发送给系统，让系统内核帮我们遍历检测是否可读，并告诉我们进行读取数据。

arr = new Arr[];
listenfd = socket();   // 打开一个网络通信套接字
bind(listenfd);        // 绑定
listen(listenfd);      // 监听
while(1) {
  connfd = accept(listenfd);  // 阻塞 等待建立连接
  arr.add(connfd);
}

// 异步线程检测 通过 select 判断是否有连接可读
new Tread(){
  while(select(arr) > 0){
    for(connfd : arr){
      if(connfd can read){
        // 如果套接字可读 创建新线程处理
        newTheadDeal(connfd);
        arr.remove(connfd);   // 移除已处理的连接
      }
    }
  }
}

newTheadDeal(connfd){
    int n = read(connfd, buf);  // 阻塞读取数据
    doSomeThing(buf);  // 处理数据
    close(connfd);        // 关闭连接 
}

从上面我们可以看出 select 运行的整个流程：

减少大量系统调用但也存在一些问题:

每次调用需要在用户态和内核态之间拷贝文件描述符数组，在高并发场景下这个拷贝的消耗是很大的。
内核检测文件描述符可读还是通过遍历实现，当文件描述符数组很长时，遍历操作耗时也很长。
内核检测完文件描述符数组后，当存在可读的文件描述符数组时，用户态需要再遍历检测一遍。

poll

poll 和 select 原理基本一致，最大的区别是去掉了最大 1024 个文件描述符的限制。
select 使用固定长度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的个数是有限制的，在 Linux 系统中，由内核中的 FD_SETSIZE 限制，默认最大值为 1024，只能监听 0~1023 的文件描述符。
poll 不再用 BitsMap 来存储所关注的文件描述符，取而代之用动态数组，以链表形式来组织，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符限制。

epoll

epoll 主要优化了上面三个问题实现:

内核中保存一份文件描述符，无需用户每次传入，而是仅同步修改部分。
通过事件唤醒机制唤醒替代遍历。
仅将可读部分文件描述符同步给用户态，不需要用户态再次遍历。

listenfd = socket();   // 打开一个网络通信套接字
bind(listenfd);        // 绑定
listen(listenfd);      // 监听
int epfd = epoll_create(...); // 创建 epoll 对象
while(1) {
  connfd = accept(listenfd);  // 阻塞 等待建立连接
  epoll_ctl(connfd, ...);  // 将新连接加入到 epoll 对象
}

// 异步线程检测 通过 epoll_wait 阻塞获取可读的套接字
new Tread(){
  while(arr = epoll_wait()){
    for(connfd : arr){
        // 仅返回可读套接字
        newTheadDeal(connfd);
    }
  }
}

newTheadDeal(connfd){
    int n = read(connfd, buf);  // 阻塞读取数据
    doSomeThing(buf);  // 处理数据
    close(connfd);        // 关闭连接 
}

边缘触发和水平触发

select/poll 只有水平触发模式，epoll 支持两种事件触发模式，分别是边缘触发（edge-triggered，ET）和水平触发（level-triggered，LT），epoll 默认的触发模式是水平触发。

边缘触发：使用边缘触发模式时，当被监控的 Socket 描述符上有可读事件发生时，服务器端只会从 epoll_wait 中苏醒一次，即使进程没有调用 read 函数从内核读取数据，也依然只苏醒一次，因此我们程序要保证一次性将内核缓冲区的数据读取完。
水平触发：使用水平触发模式时，当被监控的 Socket 上有可读事件发生时，服务器端不断地从 epoll_wait 中苏醒，直到内核缓冲区数据被 read 函数读完才结束，目的是告诉我们有数据需要读取。

事件驱动 IO

发起读请求后，等待读就绪事件通知再进行数据读取。

异步 IO

发起读请求后，等待操作系统读取完成后通知，完全将功能交给操作系统实现。

服务端的线程模型

在高性能的I/O设计中，有两个著名的模型：Reactor模型和Proactor模型，其中Reactor模型用于同步I/O，而Proactor模型运用于异步I/O操作。

无论是Reactor模型还是Proactor模型，对于支持多连接的服务器，一般可以总结为2种fd和3种事件，如下图：

2种fd：

listenfd：一般情况，只有一个。用来监听一个特定的端口(如80)。
connfd：每个连接都有一个connfd。用来收发数据。

3种事件：

listenfd进行accept阻塞监听，创建一个connfd
用户态/内核态copy数据。每个connfd对应着2个应用缓冲区：readbuf和writebuf。
处理connfd发来的数据。业务逻辑处理，准备response到writebuf。

Reactor模型

无论是C++还是Java编写的网络框架，大多数都是基于Reactor模型进行设计和开发，Reactor模型基于事件驱动，特别适合处理海量的I/O事件。

Reactor模型中定义的三种角色：

Reactor：负责监听和分配事件，将I/O事件分派给对应的Handler。新的事件包含连接建立就绪、读就绪、写就绪等。
Acceptor：处理客户端新连接，并分派请求到处理器链中。
Handler：将自身与事件绑定，执行非阻塞读/写任务，完成channel的读入，完成处理业务逻辑后，负责将结果写出channel。可用资源池来管理。

Reactor处理请求的流程：

读取操作：

应用程序注册读就绪事件和相关联的事件处理器
事件分离器等待事件的发生
当发生读就绪事件的时候，事件分离器调用第一步注册的事件处理器

写入操作类似于读取操作，只不过第一步注册的是写就绪事件。

单Reactor单线程模型

Reactor线程负责多路分离套接字，accept新连接，并分派请求到handler。Redis使用单Reactor单进程的模型。

消息处理流程：

Reactor对象通过select监控连接事件，收到事件后通过dispatch进行转发。
如果是连接建立的事件，则由acceptor接受连接，并创建handler处理后续事件。
如果不是建立连接事件，则Reactor会分发调用Handler来响应。
handler会完成read->业务处理->send的完整业务流程。

单Reactor单线程模型只是在代码上进行了组件的区分，但是整体操作还是单线程，不能充分利用硬件资源。handler业务处理部分没有异步。

对于一些小容量应用场景，可以使用单Reactor单线程模型。但是对于高负载、大并发的应用场景却不合适，主要原因如下：

即便Reactor线程的CPU负荷达到100%，也无法满足海量消息的编码、解码、读取和发送。
当Reactor线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重Reactor线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈。
一旦Reactor线程意外中断或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。

单Reactor多线程模型

消息处理流程：

Reactor对象通过Select监控客户端请求事件，收到事件后通过dispatch进行分发。
如果是建立连接请求事件，则由acceptor通过accept处理连接请求，然后创建一个Handler对象处理连接完成后续的各种事件。
如果不是建立连接事件，则Reactor会分发调用连接对应的Handler来响应。
Handler只负责响应事件，不做具体业务处理，通过Read读取数据后，会分发给后面的Worker线程池进行业务处理。
Worker线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给Handler进行处理。
Handler收到响应结果后通过send将响应结果返回给Client。

相对于第一种模型来说，在处理业务逻辑，也就是获取到IO的读写事件之后，交由线程池来处理，handler收到响应后通过send将响应结果返回给客户端。这样可以降低Reactor的性能开销，从而更专注的做事件分发工作了，提升整个应用的吞吐。

但是这个模型存在的问题：

多线程数据共享和访问比较复杂。如果子线程完成业务处理后，把结果传递给主线程Reactor进行发送，就会涉及共享数据的互斥和保护机制。
Reactor承担所有事件的监听和响应，只在主线程中运行，可能会存在性能问题。例如并发百万客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能。

为了解决性能问题，产生了第三种主从Reactor多线程模型。

主从Reactor多线程模型

比起第二种模型，它是将Reactor分成两部分：

mainReactor负责监听server socket，用来处理网络IO连接建立操作，将建立的socketChannel指定注册给subReactor。
subReactor主要做和建立起来的socket做数据交互和事件业务处理操作。通常，subReactor个数上可与CPU个数等同。

Nginx、Swoole、Memcached和Netty都是采用这种实现。

消息处理流程：

从主线程池中随机选择一个Reactor线程作为acceptor线程，用于绑定监听端口，接收客户端连接
acceptor线程接收客户端连接请求之后创建新的SocketChannel，将其注册到主线程池的其它Reactor线程上，由其负责接入认证、IP黑白名单过滤、握手等操作
步骤2完成之后，业务层的链路正式建立，将SocketChannel从主线程池的Reactor线程的多路复用器上摘除，重新注册到Sub线程池的线程上，并创建一个Handler用于处理各种连接事件
当有新的事件发生时，SubReactor会调用连接对应的Handler进行响应
Handler通过Read读取数据后，会分发给后面的Worker线程池进行业务处理
Worker线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给Handler进行处理
Handler收到响应结果后通过Send将响应结果返回给Client

总结

Reactor模型具有如下的优点：

响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
可扩展性，可以方便地通过增加Reactor实例个数来充分利用CPU资源；
可复用性，Reactor模型本身与具体事件处理逻辑无关，具有很高的复用性。

Proactor模型

模块关系：

Procator Initiator负责创建Procator和Handler，并将Procator和Handler都通过Asynchronous operation processor注册到内核。
Asynchronous operation processor负责处理注册请求，并完成IO操作。完成IO操作后会通知procator。
procator根据不同的事件类型回调不同的handler进行业务处理。handler完成业务处理，handler也可以注册新的handler到内核进程。

消息处理流程：

读取操作：

应用程序初始化一个异步读取操作，然后注册相应的事件处理器，此时事件处理器不关注读取就绪事件，而是关注读取完成事件，这是区别于Reactor的关键。
事件分离器等待读取操作完成事件
在事件分离器等待读取操作完成的时候，操作系统调用内核线程完成读取操作，并将读取的内容放入用户传递过来的缓存区中。这也是区别于Reactor的一点，Proactor中，应用程序需要传递缓存区。
事件分离器捕获到读取完成事件后，激活应用程序注册的事件处理器，事件处理器直接从缓存区读取数据，而不需要进行实际的读取操作。

Proactor中写入操作和读取操作，只不过感兴趣的事件是写入完成事件。

Proactor有如下缺点：

编程复杂性，由于异步操作流程的事件的初始化和事件完成在时间和空间上都是相互分离的，因此开发异步应用程序更加复杂。应用程序还可能因为反向的流控而变得更加难以Debug；
内存使用，缓冲区在读或写操作的时间段内必须保持住，可能造成持续的不确定性，并且每个并发操作都要求有独立的缓存，相比Reactor模型，在Socket已经准备好读或写前，是不要求开辟缓存的；
操作系统支持，Windows下通过IOCP实现了真正的异步 I/O，而在Linux系统下，Linux2.6才引入，并且异步I/O使用epoll实现的，所以还不完善。

因此在 Linux 下实现高并发网络编程都是以Reactor模型为主。

常见架构的进程/线程模型

Netty的线程模型

Netty采用的是主从线程模型。下面是Netty使用中很常见的一段代码

public class Server {
    public static void main(String[] args) throws Exception {
        EventLoopGroup bossGroup = new NioEventLoopGroup(1);
        EventLoopGroup workerGroup = new NioEventLoopGroup();
        try {
            ServerBootstrap b = new ServerBootstrap();
            b.group(bossGroup, workerGroup)
                    .channel(NioServerSocketChannel.class)
                    .childOption(ChannelOption.TCP_NODELAY, true)
                    .childAttr(AttributeKey.newInstance("childAttr"), "childAttrValue")
                    .handler(new ServerHandler())
                    .childHandler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        public void initChannel(SocketChannel ch) {
                        }
                    });
            ChannelFuture f = b.bind(8888).sync();
            f.channel().closeFuture().sync();
        } finally {
            bossGroup.shutdownGracefully();
            workerGroup.shutdownGracefully();
        }
    }
}

对Netty示例代码进行分析：

定义了两个EventLoopGroup，其中bossGroup对应的就是主线程池，只接收客户端的连接（注册，初始化逻辑），具体的工作由workerGroup这个从线程池来完成。可以理解为老板负责招揽接待，员工负责任务完成。线程池和线程组是一个概念，所以名称里有group。之后就采用ServerBootstrap启动类，传入这两个主从线程组。
客户端和服务器建立连接后，NIO会在两者之间建立Channel，所以启动类调用channel方法就是为了指定建立什么类型的通道。这里指定的是NioServerSocketChannel这个通道类。
启动类还调用了handler()和childHandler()方法，这两个方法中提及的handler是一个处理类的概念，他负责处理连接后的一个个通道的相应处理。handler()指定的处理类是主线程池中对通道的处理类，childHandler()方法指定的是从线程池中对通道的处理类。
执行ServerBootstrap的bind方法进行绑定端口的同时也执行了sync()方法进行同步阻塞调用。
关闭通道采用Channel的closeFuture()方法关闭。
最终优雅地关闭两个线程组，执行shutdownGracefully()方法完成关闭线程组。

boss线程池作用：

接收客户端的连接，初始化Channel参数。
将链路状态变更时间通知给ChannelPipeline。

worker线程池作用：

异步读取通信对端的数据报，发送读事件到ChannelPipeline。
异步发送消息到通信对端，调用ChannelPipeline的消息发送接口。
执行系统调用Task。
执行定时任务Task。

通过配置boss和worker线程池的线程个数以及是否共享线程池等方式，Netty的线程模型可以在以上三种Reactor模型之间进行切换。

tomcat的线程模型

Tomcat支持四种接收请求的处理方式：BIO、NIO、APR和AIO

NIO 同步非阻塞，比传统BIO能更好的支持大并发，tomcat 8.0 后默认采用该模型。使用方法(配置server.xml)：改为 protocol="org.apache.coyote.http11.Http11NioProtocol"
BIO 阻塞式IO，tomcat7之前默认，采用传统的java IO进行操作，该模型下每个请求都会创建一个线程，适用于并发量小的场景。使用方法(配置server.xml)：protocol =" org.apache.coyote.http11.Http11Protocol"
APR tomcat 以JNI形式调用http服务器的核心动态链接库来处理文件读取或网络传输操作，需要编译安装APR库。使用方法(配置server.xml)：protocol ="org.apache.coyote.http11.Http11AprProtocol"
AIO 异步非阻塞 (NIO2)，tomcat8.0后支持。多用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。使用方法(配置server.xml)：protocol ="org.apache.coyote.http11.Http11Nio2Protocol"

Nginx的进程模型

Nginx采用的是多进程（单线程）&多路IO复用模型。

工作模型：

Nginx在启动后，会有一个master进程和多个相互独立的worker进程。
接收来自外界的信号，向所有worker进程发送信号，每个进程都有可能来处理这个连接。
master进程能监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动启动新的worker进程。

发表于 2024-09-07 19:33 风好像从那里来阅读(15) 评论(0) 编辑收藏举报

搜索

常用链接

我的标签

随笔分类

随笔档案

阅读排行榜

网络编程基础

五种IO模型

阻塞式 IO

非阻塞式 IO

伪非阻塞（多线程）

真正的非阻塞式 IO

IO 多路复用 (IO接口的复用)

select

poll

epoll

边缘触发和水平触发

事件驱动 IO

异步 IO

服务端的线程模型

Reactor模型

单Reactor单线程模型

单Reactor多线程模型

主从Reactor多线程模型

总结

Proactor模型

常见架构的进程/线程模型

Netty的线程模型

tomcat的线程模型

Nginx的进程模型