简单理解I/O模型

---

服务端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）模型。

经常使用模型汇总