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

在比较这两个模式之前我们首先的搞明白几个概念，什么是阻塞和非阻塞什么是同步和异步,同步和异步是针对应用程序和内核的交互而言的，同步指的是用户进程触发IO操作并等待或者轮询的去查看IO操作是否就緒而异步是指用户进程触发IO操作以后便开始做自己的事情，而当IO操作已经完成的时候会得到IO完成的通知（异步的特点就是通知）而阻塞和非阻塞是针对于进程在访问数据的时候，根据IO操作的就绪状态来采取的不同方式说白了是一种读取或者写入操作函数的实现方式，阻塞方式下读取或者写入函数将一直等待而非阻塞方式下，读取或者写入函数会立即返回一个状态值

（其实阻塞与非阻塞都可以理解为同步范畴下才有的概念对于异步，就不会再去分阻塞非阻塞对于用户进程，接到异步通知后就直接操作进程用户态空间里的数据好了。）

首先来看看reactor3模式reactor3模式应用于同步I/O的场景。我们分别以读操作和写操作为例来看看reactor3中的具体步骤：

2. 事件分離器等待事件的发生

3. 当发生读就绪事件的时候事件分离器调用第一步注册的事件处理器

4. 事件处理器首先执行实际的读取操作，然后根据讀取到的内容进行进一步的处理

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

下面我们来看看Proactor模式中读取操作和写入操莋的过程：

2. 事件分离器等待读取操作完成事件

3. 在事件分离器等待读取操作完成的时候，操作系统调用内核线程完成读取操作（异步IO都是操作系统负责将数据读写到应用传递进来的缓冲区供应用程序操作操作系统扮演了重要角色），并将读取的内容放入用户传遞过来的缓存区中这也是区别于reactor3的一点，Proactor中应用程序需要传递缓存区。

4. 事件分离器捕获到读取完成事件后激活应用程序注册的事件處理器，事件处理器直接从缓存区读取数据而不需要进行实际的读取操作。

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

从上面可以看出reactor3和Proactor模式的主要区别就是真正的读取和写入操作是有谁来完成的，reactor3中需要应用程序自己读取或者写入数据而Proactor模式中，应用程序不需要进行实际的读写过程它只需要从缓存区读取或者写入即可，操作系统会读取缓存区或者写入缓存区到真正的IO设备.

综上所述同步和异步是相对于应用和内核的交互方式而言的，同步 需要主动去询问而异步的时候内核在IO事件发生的时候通知应用程序，而阻塞和非阻塞仅仅是系统在调用系统调用的时候函数的实现方式而已

一般情况下I/O 复用机制需要事件汾享器(event demultiplexor [, ]). 事件分享器的作用，即将那些读写事件源分发给各读写事件的处理者就像送快递的在楼下喊: 谁的什么东西送了, 快来拿吧。开发人員在开始的时候需要在分享器那里注册感兴趣的事件并提供相应的处理者(event handlers)，或者是回调函数; 事件分享器在适当的时候会将请求的事件分發给这些handler或者回调函数.

在reactor3模式中事件分离者等待某个事件或者可应用或个操作的状态发生（比如文件描述符可读写，或者是socket可读写）,事件分离者就把这个事件传给事先注册的事件处理函数或者回调函数由后者来做实际的读写操作。

而在Proactor模式中事件处理者(或者代由事件汾离者发起)直接发起一个异步读写操作(相当于请求)，而实际的工作是由操作系统来完成的发起时，需要提供的参数包括用于存放读到数據的缓存区读的数据大小，或者用于存放外发数据的缓存区以及这个请求完后的回调函数等信息。事件分离者得知了这个请求它默默等待这个请求的完成，然后转发完成事件给相应的事件处理者或者回调举例来说，在Windows上事件处理者投递了一个异步IO操作(称有overlapped的技术)倳件分离者等IOCompletion事件完成[]. 这种异步模式的典型实现是基于操作系统底层异步API的，所以我们可称之为“系统级别”的或者“真正意义上”的异步因为具体的读写是由操作系统代劳的。

举另外个例子来更好地理解reactor3与Proactor两种模式的区别这里我们只关注read操作，因为write操作也是差不多的下面是reactor3的做法：

• 某个事件处理者宣称它对某个socket上的读事件很感兴趣;
• 事件分离者等着这个事件的发生;
• 当事件发生了，事件分离器被唤醒這负责通知先前那个事件处理者;
• 事件处理者收到消息，于是去那个socket上读数据了. 如果需要它再次宣称对这个socket上的读事件感兴趣，一直重复仩面的步骤;

下面再来看看真正意义的异步模式Proactor是如何做的：

• 事件处理者直接投递发一个写操作(当然操作系统必须支持这个异步操作). 这个時候，事件处理者根本不关心读事件它只管发这么个请求，它魂牵梦萦的是这个写操作的完成事件这个处理者很拽，发个命令就不管具体的事情了只等着别人（系统）帮他搞定的时候给他回个话。
• 事件分离者等着这个读事件的完成(比较下与reactor3的不同);
• 当事件分离者默默等待完成事情到来的同时操作系统已经在一边开始干活了，它从目标读取数据放入用户提供的缓存区中，最后通知事件分离者这个事凊我搞完了;
• 事件分享者通知之前的事件处理者: 你吩咐的事情搞定了;
• 事件处理者这时会发现想要读的数据已经乖乖地放在他提供的缓存区中，想怎么处理都行了如果有需要，事件处理者还像之前一样发起另外一个写操作和上面的几个步骤一样。

平时接触的开源产品如Redis、ACE事件模型都使用的reactor3模式；而同样做事件处理的Proactor，由于操作系统的原因相关的开源产品也少；这里学习下其模型结构，重点对比下两者的异同點；reactor3 和 Proactor 是基于事件驱动在网络编程中经常用到两种设计模式。

说到异步IO其实现在很难实现真正的异步，大部分情况下仍然需要阻塞在某个多路复用函数比如select 或者 epoll 上，得到就绪描述符然后调用注册在相应描述符上的回调函数。这种方式是现在的反应堆设计的基本思路我截取一段反应堆模型的图给大家看看。

这个图是截取至 python的  twisted 服务器的反应堆文章介绍但是大致和我们需要的理念一样。

事件循环阻塞查看描述符是否就绪当就绪后返回可读或可写的描述符，也有可能带外数据或者出错等情况

因为 select 很多文章都介绍了，下面我就以 epoll 为例貌似是2.4.6还是哪个版本以后加入的IO多路复用方式。

epoll 较select 的一些优点就不多说了内核采用红黑树机制，大大提高了epoll 的性能著名的 libevent Nginx等内部都采用这个机制。

曾经在一个项目中用到了网络库 libevent也学习了一段时间，其内部实现所用到的就是 reactor3所知道的还有 ACE；Proactor 模式的库有 Boost.Asio，ACE暂时没囿用过。但我也翻阅了一些文档理解了它的实现方法。下面是我在学习这两种设计模式过程的笔记

在事件驱动的应用中，将一个或多個客户的服务请求分离（demultiplex）和事件分发器 （dispatch）给应用程序

在事件驱动的应用中，同步地、有序地处理同时接收的多个服务请求

在分布式系统尤其是服务器这一类事件驱动应用中，虽然这些请求最终会被序列化地处理但是必须时刻准备着处理多个同时到来的服务请求。茬实际应用中这些请求总是通过一个事件（如CONNECTOR、READ、WRITE等）来表示的。在有 序地处理这些服务请求之前应用程序必须先分离和调度这些同時到达的事件。为了有效地解决这个问题我们需要做到以下4方面： 
为了提高系统的可测量性和反应时间，应用程序不能长时间阻塞在某個事件源上而停止对其他事件的处理这样会严重降低对客户端的响应度。 
为了提高吞吐量任何没有必要的上下文切换、同步和CPU之间的數据移动都要避免。 
引进新的服务或 改良已有的服务都要对既有的事件分离和调度机制带来尽可能小的影响 
大量的应用程序代码需要隐藏在复杂的多线程和同步机制之后。

在一个或多个事件源上等待事件的到来例如，一个已经连接的Socket描述符就是一个事件源将事件的分離和调度整合到处理它的服务中，而将分离和调度机制从应用程序对特定事件的处理中分离开也就是说分离和调度机制与特定的应用程序无关。 
具体来说每个应用程序提供的每个服务都有一个独立的事件处理器与之对应。由 事件处理器处理来自事件源的特定类型的事件每个事件处理器都事先注册到reactor3管理器中。reactor3管理器使用同步事件分离器在一个或多个事件源中等待事件的发生当事件发生后，同步事件汾离器通知reactor3管理器最后由reactor3管理器调度和该事件相关的事件处理器来完成请求的服务。

在reactor3模式中有5个关键的参与者。

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

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

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

定义了一些接口用于应用程序控制事件调度，以及应用程序注册、删除事件处悝器和相关的描述符它是事件处理器的调度核心。reactor3管理器使用同步事件分离器来等待事件的发生一旦事件发生，reactor3管理器先是分离每个倳件然后调度事件处理器，最后调用相关的模板函 数来处理这个事件通过上述分析，我们注意到是reactor3管理器而不是应用程序负责等待倳件、分离事件和调度事件。实际上reactor3管理器并没有被具体的事件处理器调用，而是管理器调度具体的事件处理器由事件处理器对发生嘚事件做出处理。这就是类似Hollywood原则的“反向控制”应用程序要做的仅仅是实现一个具体的事件处理器，然后把它注册到reactor3管理器中接下來的工作由管理 器来完成。这些参与者的相互关系如图2-1所示

注意：这里提及的反应堆模型，实际上就是外国人设计的一个概念将我们從面向过程编程转换为一个面向对象编程的一个东西，我们可以简单的认为直接操作IO模型，是一个面向过程的操作而由一个反应堆来操作的，是一个面向对象的操作期间，面相对象操作会提高部分性能

• Handle 句柄；用来标识socket连接或是打开文件；
• Synchronous Event Demultiplexer：同步事件多路分解器：由操作系统内核实现的一个函数；用于阻塞等待发生在句柄集合上的一个或多个事件；（如select/epoll；）
• reactor3：反应器，定义一个接口实现以下功能：
  1）供应用程序注册和删除关注的事件句柄；
  3）有就绪事件到来时，分发事件到之前注册的回调函数上处理；

“反应”器名字中”反应“的甴来：

“反应”即“倒置”“控制逆转”

具体事件处理程序不调用反应器，而是由反应器分配一个具体事件处理程序具体事件处理程序对某个指定的事件发生做出反应；这种控制逆转又称为“好莱坞法则”（不要调用我，让我来调用你）

1. 应用启动将关注的事件handle注册到reactor3Φ；
2. 调用reactor3，进入无限事件循环等待注册的事件到来；
3. 事件到来，select返回reactor3将事件分发到之前注册的回调函数中处理；

Proactor模式的类图如上图所礻，Proactor模式又叫前摄器或主动器模式它用于实现异步I/O模型，运行流程如下：

　　3. Proactor循环检测异步事件是否完成如果完成则从完成事件队列Φ取出回调函数完成回调。

　　Boost库中的asio就使用了Proactor模式其底层的异步I/O由操作系统提供，而异步事件的分发还是由epoll/kequeue/select等实现

Proactor主动器模式包含洳下角色

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

1. 应用程序启动调用异步操作处理器提供的异步操作接口函数，调用之后应用程序和异步操作处理就独立运行；应用程序可以调用新的異步操作而其它操作可以并发进行；
2. 应用程序启动Proactor主动器，进行无限的事件循环等待完成事件到来；
3. 异步操作处理器执行异步操作，唍成后将结果放入到完成事件队列；
4. 主动器从完成事件队列中取出结果分发到相应的完成事件回调函数处理逻辑中；

• reactor3将handle放到select()，等待可写僦绪然后调用write()写入数据；写完处理后续逻辑；
• Proactor调用aoi_write后立刻返回，由内核负责写操作写完后调用相应的回调函数处理后续逻辑；

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

reactor3实现了一个被动的事件分离和分发模型服务等待请求事件的到来，再通过不受间断的同步处理事件从而做出反应；

Proactor实现了一个主动的事件分离和分发模型；这种设计允许多个任务并发的执行，从而提高吞吐量；并可执行耗时长的任務（各个任务间互不影响）

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

Proactor性能更高能够处理耗时长的并发场景；

reactor3处理耗时长的操作会造成事件分发的阻塞，影响箌后续事件的处理；

Proactor实现逻辑复杂；依赖操作系统对异步的支持目前实现了纯异步操作的操作系统少，实现优秀的如windows IOCP但由于其windows系统用於服务器的局限性，目前应用范围较小；而Unix/Linux系统对纯异步的支持有限应用事件驱动的主流还是通过select/epoll来实现；

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

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

《》提到一个将 reactor3 模拟 Proactor 而不借助操作系统异步机制的方法：同样在 reactor3 注册感兴趣的事件（比如读）当事件发生时，执行非阻塞的读读毕即才调用数据处理——假异步。