简单理解I/O模型

Posted 2021-12-11

服务端I/O：

  I/O在计算机中指Input/Output， IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。

  一次完整的I/O是用户空间的进程数据与内核空间的内核数据的报文的完整交换，但是由于内核空间与用户空间是严格隔离的，所以其数据交换过程中不能由用户空间的进程直接调用内核空间的内存数据，而是需要经历一次从内核空间中的内存数据copy到用户空间的进程内存当中，所以简单说I/O就是把数据从内核空间中的内存数据复制到用户空间中进程的内存当中。
而网络通信就是网络协议栈到用户空间进程的IO就是网络IO

  磁盘I/O是进程向内核发起系统调用，请求磁盘上的某个资源比如是文件或者是图片，然后内核通过相应的驱动程序将目标图片加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内存，如果是比较大的数据也需要等待时间。

  每次IO，都要经由两个阶段：

1. 将数据从文件先加载至内核内存空间（缓冲区），等待数据准备完成，时间较长
2. 将数据从内核缓冲区复制到用户空间的进程的内存中，时间较短

系统I/O模型：

  同步/异步：关注的是消息通信机制，即在等待一件事情的处理结果之前，被调用者是否提供通知机制。
同步：进程发出请求调用后，等待内核返回响应之后再进行下一个请求。如果内核不进行返回数据，则进程一直处于等待状态。
异步：进程发出请求调用后，不等待内核返回响应，直接处理下一个请求。（nginx是异步处理机制）

  阻塞/非阻塞：关注调用者在等待结果返回之前所处的状态。
阻塞：I/O操作需要彻底完成之后才返回到用户空间，操作返回之前，调用者处于被挂起状态，无法执行其他操作。
非阻塞：I/O操作被调用后立即返回给用户一个状态值，无需等待完成，最终的调用结果返回之前，调用者不会被挂起，可以执行其他操作。

网络I/O模型

同步阻塞型I/O模型（blocking IO）

  阻塞IO模型是最简单的IO模型，用户线程在内核进行IO操作时被阻塞 用户线程通过系统调用read发起IO读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作 用户需要等待read将数据读取到buffer后，才继续处理接收的数据。整个IO请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够 优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源 缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，apache 的preforck使用的是这种模式。

  简单理解就是：程序向内核发送I/O请求后一直处于等待内核响应的状态，如果内核处理请求的I/O操作不能立即返回，则进程将一直处于等待状态而不再接收新的请求，并由进程轮询查看I/O是否完成，完成后进程将I/O结果返回给Client，在I/O没有返回期间进程不能接收其他客户的请求，而且是由进程自己去看I/O是否完成，这种方式简单，但是比较慢，所以用的比较少。

同步非阻塞型I/O模型(nonblocking IO)

  用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。即 “轮询”机制存在两个问题：如果有大量文件描述符都要等，那么就得一个一个的read。这会带来大量的Context Switch（read是系统调用，每调用一次就得在用户态和核心态切换一次）。轮询的时间不好把握。这里是要猜多久之后数据才能到。等待时间设的太长，程序响应延迟就过大；设的太短，就会造成过于频繁的重试，干耗CPU而已，是比较浪费CPU的方式，一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。

  简单理解就是：程序向内核发送I/O请求后一直等待内核响应，如果内核处理请求的I/O操作不能理解返回I/O结果，进程将不再等待，继续处理其他请求，但是仍然需要进程每隔一段时间就要查看内核I/O是否完成。这是一种比较浪费CPU的一种方式：轮询的时间不好把握，如果设置的等待时间过长，程序响应延迟就过大；设置的时间过短，就会造成过于频繁的重试。

I/O多路复用型(IO multiplexing)

  I/O多路复用型就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO。select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select，poll，epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。 当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。比如：Apache prefork是此模式的select，work是poll模式。

  简单理解即：I/O多路复用机制可以同时监控多个描述符，当某个描述符就绪（读或者写就绪），则立即通知相应程序进行读或者写操作。但select、poll、epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的。

信号驱动式IO(signal-driven IO)

  信号驱动IO就是用户进程可以通过sigaction系统调用注册一个信号处理程序，然后主程序可以继续向下执行，当有IO操作准备就绪时，由内核通知触发一个SIGIO信号处理程序执行，然后将用户进程所需要的数据从内核空间拷贝到用户空间 此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行，只要等待来自信号处理函数的通知。

1. 优点：线程并没有在等待数据时被阻塞，内核直接返回调用接收信号，不影响进程继续处理其他请求因此可以提高资源的利用率

2. 缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知

  简单理解就是：程序进程通过在内核上调用sigaction函数，向内核发送I/O调用后，不用等待内核响应，可以继续接受其他请求，内核收到进程请求后进行的I/O如果不能立即返回，就由内核等待结果，直到I/O完成后内核再通知进程。apache event就是这个模式。

异步（非阻塞）IO(asynchronous IO)

  相对于同步IO，异步IO不是顺序执行。用户进程进行aio_read系统调用之后，无论内核数据是否准备好，都会直接返回给用户进程，然后用户态进程可以去做别的事情。等到socket数据准备好了，内核直接复制数据给进程，然后从内核向进程发送通知。IO两个阶段，进程都是非阻塞的。 Linux提供了AIO库函数实现异步，但是用的很少。目前有很多开源的异步IO库，例如libevent、libev、libuv。

  程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他强求，内核调用的IO如果不能立即返回，内核会继续处理其他事物，知道IO完成后将结果通知给内核，内核再将IO完成的结果返回给进程，期间进程可以接受新的请求，内核也可以处理新的事物，因此相互之间是不影响的。可以实现较大的同时并实现较高的IO复用，因此异步非阻塞是使用最多的一种通信方式。

nginx事件驱动模型实现方式

  Nginx支持在多种不同的操作系统实现不同的事件驱动模型，但是其在不同的操作系统甚至是不同的系统版本上面的实现方式不尽相同，主要有以下实现方式

1. select：
   select库是在linux和windows平台都基本支持的 事件驱动模型库，并且在接口的定义也基本相同，只是部分参数的含义略有差异，最大并发限制1024，是最早期的事件驱动模型。
2. poll：
   在Linux 的基本驱动模型，windows不支持此驱动模型，是select的升级版，取消了最大的并发限制，在编译nginx的时候可以使用--with-poll_module和--without-poll_module这两个指定是否编译select库。
3. epoll：
   epoll是库是Nginx服务器支持的最高性能的事件驱动库之一，是公认的非常优秀的事件驱动模型，它和select和poll有很大的区别，epoll是poll的升级版，但是与poll的效率有很大的区别。
   epoll的处理方式是创建一个待处理的事件列表，然后把这个列表发给内核，返回的时候在去轮训检查这个表，以判断事件是否发生，epoll支持一个进程打开的最大事件描述符的上限是系统可以打开的文件的最大数，同时epoll库的IO效率不随描述符数目增加而线性下降，因为它只会对内核上报的“活跃”的描述符进行操作。
4. rtsig：
   不是一个常用事件驱动，最大队列1024，不是很常用
5. kqueue：
   用于支持BSD系列平台的高校事件驱动模型，主要用在FreeBSD 4.1及以上版本、OpenBSD 2.0级以上版本，NetBSD级以上版本及Mac OS X 平台上，该模型也是poll库的变种，因此和epoll没有本质上的区别，都是通过避免轮训操作提供效率。
6. /dev/poll:
   用于支持unix衍生平台的高效事件驱动模型，主要在Solaris 平台、HP/UX，该模型是sun公司在开发Solaris系列平台的时候提出的用于完成事件驱动机制的方案，它使用了虚拟的/dev/poll设备，开发人员将要见识的文件描述符加入这个设备，然后通过ioctl()调用来获取事件通知，因此运行在以上系列平台的时候请使用/dev/poll事件驱动机制。
7. eventport：
   该方案也是sun公司在开发Solaris的时候提出的事件驱动库，只是Solaris 10以上的版本，该驱动库看防止内核崩溃等情况的发生。
8. Iocp：
   Windows系统上的实现方式，对应第5种（异步I/O）模型。

常用模型汇总