基本Liunx I/O模型矩阵

Blocking Non-blocking
Synchronous Read/Write Read/Write (O_NONBLOCK)
Asynchronous 多路复用IO（select/poll） AIO

Unix的五种I/O模型：

  1. 阻塞I/O：应用程序调用一个IO函数，导致应用程序阻塞，如果数据已经准备好，从内核拷贝到用户空间，否则一直等待下去
  2. 非阻塞I/O：
  3. I/O复用（select和poll）
  4. 信号驱动I/O（SIGIO）
  5. 异步I/O（Posix.1的aio_系列函数）

    1. I/O多路复用模型（ IO multiplexing）

    IO multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO。select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select，poll，epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。select，poll，epoll这个function也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数。
    image.png
    当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
    I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回。
    用select的优势在于它可以同时处理多个connection。所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）
    在IO multiplexing Model中，实际中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。

    2. 信号驱动I/O模型

    我们也可以用信号，让内核在描述符就绪时发送SIGIO信号通知我们。通过sigaction系统调用安装一个信号处理函数。该系统调用将立即返回，我们的进程继续工作，也就是说它没有被阻塞。当数据报准备好读取时，内核就为该进程产生一个SIGIO信号。我们随后既可以在信号处理函数中调用recvfrom读取数据报，并通知主循环数据已经准备好待处理。
    优势：等待数据报到达期间进程不被阻塞。主循环可以继续执行，只要等待来自信号处理函数的通知：既可以是数据已准备好被处理，也可以是数据报已准备好被读取。
    image.png

    3. 异步I/O模型（asynchronous IO）

    linux下的asynchronous IO其实用得很少。
    告知内核启动某个操作，并让内核在整个操作(包括将内核复制到我们自己的缓冲区)完成后通知我们。
    与信号驱动模型的主要区别在于：信号驱动式I/O是由内核通知我们何时可以启动一个I/O操作，而异步模型是由内核通知我们I/O操作何时完成。
    image.png
    调用aioread（Posix异步I/O函数以aio或lio_开头）函数，给内核传递描述字、缓冲区指针、缓冲区大小（与read相同的3个参数）、文件偏移以及通知的方式，然后系统立即返回。我们的进程不阻塞于等待I/0操作的完成。当内核将数据拷贝到缓冲区后，再通知应用程序。
    用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。

    4. Linux下几种网络概念

    • 用户空间和内核空间
    • 进程切换
    • 进程的阻塞
    • 文件描述符
    • 缓存 I/O

      4.1. 用户空间与内核空间

      现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操心系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间，而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。

      4.2. 进程切换

      为了控制进程的执行，内核必须有能力挂起正在CPU上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。因此可以说，任何进程都是在操作系统内核的支持下运行的，是与内核紧密相关的。
      从一个进程的运行转到另一个进程上运行，这个过程中经过下面这些变化：
      1. 保存处理机上下文，包括程序计数器和其他寄存器。
      2. 更新PCB信息。
      3. 把进程的PCB移入相应的队列，如就绪、在某事件阻塞等队列。
      4. 选择另一个进程执行，并更新其PCB。
      5. 更新内存管理的数据结构。
      6. 恢复处理机上下文。
      注：总而言之就是很耗资源

      4.3. 进程的阻塞

      正在执行的进程，由于期待的某些事件未发生，如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)，使自己由运行状态变为阻塞状态。可见，进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得CPU），才可能将其转为阻塞状态。当进程进入阻塞状态，是不占用CPU资源的。

      4.4. 文件描述符fd

      文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。
      文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

      4.5. 缓存 I/O

      缓存 I/O 又被称作标准 I/O，大多数文件系统的默认 I/O 操作都是缓存 I/O。在 Linux 的缓存 I/O 机制中，操作系统会将 I/O 的数据缓存在文件系统的页缓存（ page cache ）中，也就是说，数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。
      缓存 I/O 的缺点：
      数据在传输过程中需要在应用程序地址空间和内核进行多次数据拷贝操作，这些数据拷贝操作所带来的 CPU 以及内存开销是非常大的。

      5. I/O 多路复用之select、poll、epoll详解

      select，poll，epoll都是IO多路复用的机制。I/O多路复用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

      5.1. select

      select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述符就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以 通过遍历fdset，来找到就绪的描述符。
      使用方法总共分三步:
      1.三个fd_set初始化，用FD_ZERO　FD_SET
      2.调用select
      3.用fd遍历每一个fd_set使用FD_ISSET。如果成功就处理。
      select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点。select的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但 是这样也会造成效率的降低。

      5.2. poll

      不同与select使用三个位图来表示三个fdset的方式，poll使用一个 pollfd的指针实现。
  1. struct pollfd {
  2.     int fd; /* file descriptor */
  3.     short events; /* requested events to watch */
  4.     short revents; /* returned events witnessed */
  5. };

pollfd结构包含了要监视的event和发生的event，不再使用select“参数-值”传递的方式。同时，pollfd并没有最大数量限制（但是数量过大后性能也是会下降）。 和select函数一样，poll返回后，需要轮询pollfd来获取就绪的描述符。

从上面看，select和poll都需要在返回后，通过遍历文件描述符来获取已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。

也是分三步
1.pollfd初始化，绑定sock，设置事件event，revent。设置时间限制。
2.调用poll
3.遍历看他的事件发生了么，如果发生了置0。

5.3. epoll

epoll：一次循环
epoll是在2.6内核中提出的，是之前的select和poll的增强版本。而且只在linux下支持。相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。
epoll是直接在内核里的，用户调用系统调用去注册，因此省去了每次的复制和轮询的消耗。这儿用了三个系统调用，epollcreate只要每次调用开始调用一次创造一个epoll就可以了。然后用epoll_ctl来进行添加事件，其实就是注册到内核管理的epoll里。然后直接epoll_wait就可以了。系统会返回系统调用的。
使用方法
1.准备工作多了，很复杂，这个记录数据在内核里。
1)构建epoll描述符，通过调用epoll_create
2)用需要的时间和上下文数据指针初始化。
3)调用epoll_ctl 添加文件描述符。
4)调用epoll_wait每次处理20个事件。这儿是接收一个空数组，然后填上东西。也就是有200个东西过来，我可能只填了一个。当然如果50个完成了也是回复20.剩下的不会被漏掉，下次再来处理。
5)遍历返回的数据。注意这儿返回的都是有用的东西。

5.3.1. epoll总结

在 select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一 个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait() 时便得到通知。(此处去掉了遍历文件描述符，而是通过监听回调的的机制。这正是epoll的魅力所在。)
epoll的优点主要是一下几个方面：

  1. 监视的描述符数量不受限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。select的最大缺点就是进程打开的fd是有数量限制的。这对 于连接数量比较大的服务器来说根本不能满足。虽然也可以选择多进程的解决方案( Apache就是这样实现的)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完美的方案。
  2. IO的效率不会随着监视fd的数量的增长而下降。epoll不同于select和poll轮询的方式，而是通过每个fd定义的回调函数来实现的。只有就绪的fd才会执行回调函数。

  3. 如果没有大量的idle -connection或者dead-connection，epoll的效率并不会比select/poll高很多，但是当遇到大量的idle- connection，就会发现epoll的效率大大高于select/poll。

    5.4. select，poll，epoll区别

    select的缺点：

  4. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE 1024)

  5. 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
  6. select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
  7. select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

poll:
优势:
1.无上限1024。
2.由于它不修改pollfd里的数据，所以它可以不用每次都填写了。
3.方便的知道远程的状态比如宕机
缺点:
1、还要轮巡
2、不能动态修改set。
其实大多数client不用考虑这个，除非p2p应用。一些server端用不用考虑这个问题。
大多时候他都比select更好。甚至如下场景比epoll还好:

  • 你要跨平台，因为epoll只支持linux。
  • socket数目少于1000个。
  • 大于1000但是是socket寿命比较短。
  • 没有其他线程干扰的时候。

相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但select三个缺点依然存在。
拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。
epoll：
优点：
1.只返回触发的事件。少了拷贝消耗，迭代轮训消耗。
2.可以绑定更多上下文，不仅仅是socket。
3.任何时间处理socket。这些问题都是有内核来处理。了。这个还需要继续学习啊。
4.可以边缘触发。
5.多线程可以在同一个epoll wait里等待。
缺点：
1.读写状态变更之类的就要麻烦些，在poll里只要改一个bit就可以了。在这里面则需要改更多的位数。并且都是system call。
2.创建socket也需要两次系统调用，麻烦。
3.只有linux下可以使用
4.复杂难调试
适合场景
1.多线程，多连接。在单线程还不如poll
2.大量线程监控1000上，
3.相对长寿命的连接。系统调用会很耗时。
4.linux依赖的事情。
epoll IO多路复用模型实现机制
由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。
设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？
在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：
1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字
3）调用epoll_wait收集发生的事件的连接
如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

下面来看看Linux内核具体的epoll机制实现思路**
当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：

  1. struct eventpoll{  
  2.     ....  
  3.     /*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/  
  4.     struct rb_root  rbr;  
  5.     /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/  
  6.     struct list_head rdlist;  
  7.     ....  
  8. };

每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。
而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：

  1. struct epitem{  
  2.     struct rb_node  rbn;//红黑树节点  
  3.     struct list_head    rdllink;//双向链表节点  
  4.     struct epoll_filefd  ffd;  //事件句柄信息  
  5.     struct eventpoll *ep;    //指向其所属的eventpoll对象  
  6.     struct epoll_event event; //期待发生的事件类型  
  7. }

当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。
image.png
从上面的讲解可知：通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。
OK，讲解完了Epoll的机理，我们便能很容易掌握epoll的用法了。一句话描述就是：三步曲。
第一步：epoll_create()系统调用。此调用返回一个句柄，之后所有的使用都依靠这个句柄来标识。
第二步：epoll_ctl()系统调用。通过此调用向epoll对象中添加、删除、修改感兴趣的事件，返回0标识成功，返回-1表示失败。
第三部：epoll_wait()系统调用。通过此调用收集收集在epoll监控中已经发生的事件。

select仍然在现实保留的原因

1.历史遗留问题，因为select发展了很久的时间，额可以肯定大多的平台都支持他了，因为你无法保证新的平台都支持poll或者epoll。放心，我们说的不是enaic那种元祖机子，你听说过xp吗？你知道他在全中国全世界知道今天2016/9/10仍然占据多少比例么。oh no，它只支持iselect。
2.时间高精度，因为select可以精确到ns级别。而后二者只能精确到ms级别。当然你会说很多系统调用都没有那么高精度的。但是对于实时操作系统，也就是类似工业控制的高精领域，或者说比如核电站，核反应堆，oh，no这儿用select不止是让系统更安全，让你不被老板炒鱿鱼，更是关系到我们大众安全的问题，请你一定不要忘了这一点。
3，当然如果是简单应用场景，比如低于200个socket，那么你用什么其实问题都不大，更多的问题是在与程序员的编程水平了。

两种高性能I/O设计模式Reactor（反应堆）和Proactor（前摄器）

平时接触的开源产品如Redis、ACE，事件模型都使用的Reactor模式；而同样做事件处理的Proactor，由于操作系统的原因，相关的开源产品也少；这里学习下其模型结构，重点对比下两者的异同点；Reactor 和 Proactor 是基于事件驱动，在网络编程中经常用到两种设计模式。
说到异步IO，其实现在很难实现真正的异步，大部分情况下仍然需要阻塞在某个多路复用函数，比如select 或者 epoll 上，得到就绪描述符，然后调用注册在相应描述符上的回调函数。这种方式是现在的反应堆设计的基本思路。
image.png
这个图是截取至 python的 twisted 服务器的反应堆文章介绍，但是大致和我们需要的理念一样。
事件循环阻塞查看描述符是否就绪，当就绪后返回可读或可写的描述符，也有可能带外数据或者出错等情况。
epoll 较select 的一些优点就不多说了，内核采用红黑树机制，大大提高了epoll 的性能。著名的 libevent Nginx等内部都采用这个机制。

反应器Reactor

在事件驱动的应用中，将一个或多个客户的服务请求分离（demultiplex）和事件分发器 （dispatch）给应用程序。
上下文
在事件驱动的应用中，同步地、有序地处理同时接收的多个服务请求。
问题：
在分布式系统尤其是服务器这一类事件驱动应用中，虽然这些请求最终会被序列化地处理，但是必须时刻准备着处理多个同时到来的服务请求。在实际应用中，这些请求总是通过一个事件（如CONNECTOR、READ、WRITE等）来表示的。在有 序地处理这些服务请求之前，应用程序必须先分离和调度这些同时到达的事件。为了有效地解决这个问题，我们需要做到以下4方面：
为了提高系统的可测量性和反应时间，应用程序不能长时间阻塞在某个事件源上而停止对其他事件的处理，这样会严重降低对客户端的响应度。
为了提高吞吐量，任何没有必要的上下文切换、同步和CPU之间的数据移动都要避免。
引进新的服务或 改良已有的服务都要对既有的事件分离和调度机制带来尽可能小的影响。
大量的应用程序代码需要隐藏在复杂的多线程和同步机制之后。
解决方案：
在一个或多个事件源上等待事件的到来，例如，一个已经连接的Socket描述符就是一个事件源。将事件的分离和调度整合到处理它的服务中，而将分离和调度机制从应用程序对特定事件的处理中分离开，也就是说分离和调度机制与特定的应用程序无关。
具体来说，每个应用程序提供的每个服务都有一个独立的事件处理器与之对应。由 事件处理器处理来自事件源的特定类型的事件。每个事件处理器都事先注册到Reactor管理器中。Reactor管理器使用同步事件分离器在一个或多个事件源中等待事件的发生。当事件发生后，同步事件分离器通知Reactor管理器，最后由Reactor管理器调度和该事件相关的事件处理器来完成请求的服务。
在Reactor模式中，有5个关键的参与者。
描述符（handle）：

由操作系统提供，用于识别每一个事件，如Socket描述符、文 件描述符等。在Linux中，它用一个整数来表示。事件可以来自外部，如来自客户端 的连接请求、数据等。事件也可以来自内部，如定时器事件。

同步事件分离器 （demultiplexer）：

是一个函数，用来等待一个或多个事件的发生。调用者会被阻 塞，直到分离器分离的描述符集上有事件发生。Linux的select函数是一个经常被使 用的分离器。

事件处理器接口（event handler）：

是由一个或多个模板函数组成的接口。这些模板函数描述了和应用程序相关的对某个事件的操作。具体的事件处理器：是事件处理器接口的实现。它实现了应用程序提供的某个服务。每个具体的事件处理器总和一个描述符相关。它使用描述符来识别事件、识别应用程序提供的服务。

Reactor管理器（reactor）：

定义了一些接口，用于应用程序控制事件调度，以及应用程序注册、删除事件处理器和相关的描述符。它是事件处理器的调度核心。Reactor管理器使用同步事件分离器来等待事件的发生。一旦事件发生，Reactor管理器先是分离每个事件，然后调度事件处理器，最后调用相关的模板函 数来处理这个事件。通过上述分析，我们注意到，是Reactor管理器而不是应用程序负责等待事件、分离事件和调度事件。实际上，Reactor管理器并没有被具体的事件处理器调用，而是管理器调度具体的事件处理器，由事件处理器对发生的事件做出处理。这就是类似Hollywood原则的“反向控制”。在Reactor模式中，会先对每个client注册感兴趣的事件，然后有一个线程专门去轮询每个client是否有事件发生，当有事件发生时，便顺序处理每个事件，当所有事件处理完之后，便再转去继续轮询，如下图所示:

image.png
多路复用IO就是采用Reactor模式

Reactor模式结构

image.png
Reactor包含如下角色：

  • Handle 句柄；用来标识socket连接或是打开文件；
  • Synchronous Event Demultiplexer：同步事件多路分解器：由操作系统内核实现的一个函数；用于阻塞等待发生在句柄集合上的一个或多个事件；（如select/epoll；）
  • Event Handler：事件处理接口
  • Concrete Event HandlerA：实现应用程序所提供的特定事件处理逻辑；
  • Reactor：反应器，定义一个接口，实现以下功能：

1）供应用程序注册和删除关注的事件句柄；
2）运行事件循环；
3）有就绪事件到来时，分发事件到之前注册的回调函数上处理；
反应器名字中”反应“的由来：“反应”即“倒置”，“控制逆转”
具体事件处理程序不调用反应器，而是由反应器分配一个具体事件处理程序，具体事件处理程序对某个指定的事件发生做出反应；这种控制逆转又称为“好莱坞法则”（不要调用我，让我来调用你）

Proactor模式

image.png
Proactor模式的类图如上图所示，Proactor模式又叫前摄器或主动器模式。它用于实现异步I/O模型，运行流程如下：
　　1. Initiator主动调用Asynchronous Operation Processor发起异步I/O操作，
　　2. 记录异步操作的参数和函数地址放入完成事件队列（Completion Event Queue）中
　　3. Proactor循环检测异步事件是否完成。如果完成则从完成事件队列中取出回调函数完成回调。
　　Boost库中的asio就使用了Proactor模式，其底层的异步I/O由操作系统提供，而异步事件的分发还是由epoll/kequeue/select等实现。

Proactor模式结构

image.png
Proactor主动器模式包含如下角色

  • Handle 句柄；用来标识socket连接或是打开文件；
  • Asynchronous Operation Processor：异步操作处理器；负责执行异步操作，一般由操作系统内核实现；
  • Asynchronous Operation：异步操作
  • Completion Event Queue：完成事件队列；异步操作完成的结果放到队列中等待后续使用
  • Proactor：主动器；为应用程序进程提供事件循环；从完成事件队列中取出异步操作的结果，分发调用相应的后续处理逻辑；
  • Completion Handler：完成事件接口；一般是由回调函数组成的接口；

  • Concrete Completion Handler：完成事件处理逻辑；实现接口定义特定的应用处理逻辑；

    对比两者的区别

    主动和被动

    以主动写为例：

  • Reactor将handle放到select()，等待可写就绪，然后调用write()写入数据；写完处理后续逻辑；

  • Proactor调用aoi_write后立刻返回，由内核负责写操作，写完后调用相应的回调函数处理后续逻辑；

可以看出，Reactor被动的等待指示事件的到来并做出反应；它有一个等待的过程，做什么都要先放入到监听事件集合中等待handler可用时再进行操作；
Proactor直接调用异步读写操作，调用完后立刻返回；

实现

Reactor实现了一个被动的事件分离和分发模型，服务等待请求事件的到来，再通过不受间断的同步处理事件，从而做出反应；
Proactor实现了一个主动的事件分离和分发模型；这种设计允许多个任务并发的执行，从而提高吞吐量；并可执行耗时长的任务（各个任务间互不影响）

优点

Reactor实现相对简单，对于耗时短的处理场景处理高效；
操作系统可以在多个事件源上等待，并且避免了多线程编程相关的性能开销和编程复杂性；
事件的串行化对应用是透明的，可以顺序的同步执行而不需要加锁；
事务分离：将与应用无关的多路分解和分配机制和与应用相关的回调函数分离开来，
Proactor性能更高，能够处理耗时长的并发场景；

缺点

Reactor处理耗时长的操作会造成事件分发的阻塞，影响到后续事件的处理；
Proactor实现逻辑复杂；依赖操作系统对异步的支持，目前实现了纯异步操作的操作系统少，实现优秀的如windows IOCP，但由于其windows系统用于服务器的局限性，目前应用范围较小；而Unix/Linux系统对纯异步的支持有限，应用事件驱动的主流还是通过select/epoll来实现；

适用场景

Reactor：同时接收多个服务请求，并且依次同步的处理它们的事件驱动程序；
Proactor：异步接收和同时处理多个服务请求的事件驱动程序；

总结

相比网络编程中最简单的思路模式：bind,listen,accept,read,server operator,write，Reactor 和 Proactor 是两种高性能的设计模式，掌握此两种模式，有助于理解一些网络库的工作流程。此文提到了两种设计模式，但没有一些技术细节，譬如多线程同步。如果在 Reactor 中支持多线程，或多个线程共享一个 Proactor，线程的同步问题就来了。