I/O模型之三：两种高性能 I/O 设计模式 Reactor 和 Proactor
目录：
《I/O模型之二：Linux IO模式及 select、poll、epoll详解》
《I/O模型之三：两种高性能 I/O 设计模式 Reactor 和 Proactor》
Reactor（反应堆）和Proactor（前摄器）
《I/O模型之三：两种高性能 I/O 设计模式 Reactor 和 Proactor》
《【转】第8章 前摄器（Proactor）：用于为异步事件多路分离和分派处理器的对象行为模式》
《Java NIO系列教程（八）JDK AIO编程》-- java AIO的proactor模式
《Java NIO系列教程（七） selector原理 Epoll版的Selector》--java NIO的Reactor模式
平时接触的开源产品如Redis、ACE，事件模型都使用的Reactor模式；而同样做事件处理的Proactor，由于操作系统的原因，相关的开源产品也少；这里学习下其模型结构，重点对比下两者的异同点；Reactor 和 Proactor 是基于事件驱动，在网络编程中经常用到两种设计模式。
说到异步IO，其实现在很难实现真正的异步，大部分情况下仍然需要阻塞在某个多路复用函数，比如select 或者 epoll 上，得到就绪描述符，然后调用注册在相应描述符上的回调函数。这种方式是现在的反应堆设计的基本思路。我截取一段反应堆模型的图给大家看看。
这个图是截取至 python的 twisted 服务器的反应堆文章介绍，但是大致和我们需要的理念一样。
事件循环阻塞查看描述符是否就绪，当就绪后返回可读或可写的描述符，也有可能带外数据或者出错等情况。
因为 select 很多文章都介绍了，下面我就以 epoll 为例，貌似是2.4.6还是哪个版本以后加入的IO多路复用方式。
epoll 较select 的一些优点就不多说了，内核采用红黑树机制，大大提高了epoll 的性能。著名的 libevent Nginx等内部都采用这个机制。
曾经在一个项目中用到了网络库 libevent，也学习了一段时间，其内部实现所用到的就是 Reactor，所知道的还有 ACE；Proactor 模式的库有 Boost.Asio，ACE，暂时没有用过。但我也翻阅了一些文档，理解了它的实现方法。下面是我在学习这两种设计模式过程的笔记。
反应器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管理器中。接下来的工作由管理 器来完成。这些参与者的相互关系如图2-1所示。
注意：这里提及的反应堆模型，实际上就是外国人设计的一个概念，将我们从面向过程编程转换为一个面向对象编程的一个东西，我们可以简单的认为，直接操作IO模型，是一个面向过程的操作，而由一个反应堆来操作的，是一个面向对象的操作，期间，面相对象操作会提高部分性能。
Reactor模式结构
Reactor包含如下角色：
- Handle 句柄；用来标识socket连接或是打开文件；
- Synchronous Event Demultiplexer：同步事件多路分解器：由操作系统内核实现的一个函数；用于阻塞等待发生在句柄集合上的一个或多个事件；（如select/epoll；）
- Event Handler：事件处理接口
- Concrete Event HandlerA：实现应用程序所提供的特定事件处理逻辑；
- Reactor：反应器，定义一个接口，实现以下功能：
1）供应用程序注册和删除关注的事件句柄；
2）运行事件循环；
3）有就绪事件到来时，分发事件到之前注册的回调函数上处理；
“反应”器名字中”反应“的由来：
“反应”即“倒置”，“控制逆转”
具体事件处理程序不调用反应器，而是由反应器分配一个具体事件处理程序，具体事件处理程序对某个指定的事件发生做出反应；这种控制逆转又称为“好莱坞法则”（不要调用我，让我来调用你）
业务流程及时序图
- 应用启动，将关注的事件handle注册到Reactor中；
- 调用Reactor，进入无限事件循环，等待注册的事件到来；
- 事件到来，select返回，Reactor将事件分发到之前注册的回调函数中处理；
Proactor模式
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模式结构
Proactor主动器模式包含如下角色
- Handle 句柄；用来标识socket连接或是打开文件；
- Asynchronous Operation Processor：异步操作处理器；负责执行异步操作，一般由操作系统内核实现；
- Asynchronous Operation：异步操作
- Completion Event Queue：完成事件队列；异步操作完成的结果放到队列中等待后续使用
- Proactor：主动器；为应用程序进程提供事件循环；从完成事件队列中取出异步操作的结果，分发调用相应的后续处理逻辑；
- Completion Handler：完成事件接口；一般是由回调函数组成的接口；
- Concrete Completion Handler：完成事件处理逻辑；实现接口定义特定的应用处理逻辑；
业务流程及时序图
- 应用程序启动，调用异步操作处理器提供的异步操作接口函数，调用之后应用程序和异步操作处理就独立运行；应用程序可以调用新的异步操作，而其它操作可以并发进行；
- 应用程序启动Proactor主动器，进行无限的事件循环，等待完成事件到来；
- 异步操作处理器执行异步操作，完成后将结果放入到完成事件队列；
- 主动器从完成事件队列中取出结果，分发到相应的完成事件回调函数处理逻辑中；
对比两者的区别
主动和被动
以主动写为例：
- 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，线程的同步问题就来了。
《Comparing Two High-Performance I/O Design Patterns》提到一个将 Reactor 模拟 Proactor 而不借助操作系统异步机制的方法：同样在 Reactor 注册感兴趣的事件（比如读），当事件发生时，执行非阻塞的读，读毕即才调用数据处理——假异步。
