关于reactor和proctor

网络程序设计中有两种主流的设计模式：Reactor和Proactor。两者的区别，用知乎上的一个神回答解释：

如何深刻理解reactor和proactor？
reactor：能收了你跟俺说一声。
proactor: 你给我收十个字节，收好了跟俺说一声。

Linux下高性能的网络库中大多使用的Reactor 模式去实现,Boost Asio在Linux下用epoll和select去模拟proactor模式,影响了它的效率和实现复杂度。为什么Boost.Asio使用Proactor模式呢？借用知乎上陈聪的回答来解释吧：

Windows 下很难实现高效可伸缩的 Reactor。首先，Win32 API 里 WaitForMultipleObjects 只能同时等待 64 个 handle (MAXIMUM_WAIT_OBJECTS)；其次 WinSock 的 select() 实现又很 buggy，特别是在错误处理方面有很多奇葩行为（具体见各种跨平台网络库代码中对此的注释）；最后，Windows Vista 新增的 WSAPoll() 函数与 POSIX 的 poll() 又不尽兼容（ daniel.haxx.se/blog/201 ）。
Windows 有自己的一套高效异步IO模型（几乎等同于Proactor），同时支持文件IO和网络IO；但 Linux 只有高效的网络同步IO（epoll 之类的 io multiplexing 是同步的Reactor，且不支持磁盘文件），二者的高效IO编程模型从根本上不兼容（Windows 可以把网络事件发到 GUI 线程的事件队列中，有点类似 Reactor，但是似乎一个进程只能有一个 GUI 线程，因此在多核系统上其伸缩性受限）。
因此，ASIO 要想高效且跨平台，只能用 Proactor 模型了。不可避免地会在 Linux 上损失一点儿效率。
换句话说，proactor需要利用操作系统的底层异步API，由内核线程并行进行实际的I/O读写操作，可以实现灵活的异步回调，并且在回调之前数据已经准备好并放在用户缓存中了。

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

1. Initiator主动调用Asynchronous Operation Processor发起异步I/O操作，

2. 记录异步操作的参数和函数地址放入完成事件队列（Completion Event Queue）中

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

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

两者区别
　　综上我们可以发现Reactor模式和Proactor模式的主要区别:

1. Reactor实现同步I/O多路分发，Proactor实现异步I/O分发。

如果只是处理网络I/O单线程的Reactor尚可处理，但如果涉及到文件I/O，单线程的Reactor可能被文件I/O阻塞而导致其他事件无法被分发。所以涉及到文件I/O最好还是使用Proactor模式，或者用多线程模拟实现异步I/O的方式。

2. Reactor模式注册的是文件描述符的就绪事件，而Proactor模式注册的是完成事件。

即Reactor模式有事件发生的时候要判断是读事件还是写事件，然后用再调用系统调用(read/write等)将数据从内核中拷贝到用户数据区继续其他业务处理。

而Proactor模式一般使用的是操作系统的异步I/O接口，发起异步调用（用户提供数据缓冲区）之后操作系统将在内核态完成I/O并拷贝数据到用户提供的缓冲区中，完成事件到达之后，用户只需要实现自己后续的业务处理即可。

3. 主动和被动

Reactor模式是一种被动的处理，即有事件发生时被动处理。而Proator模式则是主动发起异步调用，然后循环检测完成事件。

---

再一种理解
Reactor模型有三个重要的组件：

多路复用器：由操作系统提供，在linux上一般是select, poll, epoll等系统调用。
事件分发器：将多路复用器中返回的就绪事件分到对应的处理函数中。
事件处理器：负责处理特定事件的处理函数。

Reactor模式是编写高性能网络服务器的必备技术之一，它具有如下的优点：
响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源；
可复用性，reactor框架本身与具体事件处理逻辑无关，具有很高的复用性；
Proactor模型流程
1、处理器发起异步操作，并关注I/O完成事件
2、事件分离器等待操作完成事件
3、分离器等待过程中，内核并行执行实际的I/O操作，并将结果数据存入用户自定义缓冲区，最后通知事件分离器读操作完成
4、I/O完成后，通过事件分离器呼唤处理器
5、事件处理器处理用户自定义缓冲区中的数据

从上面的处理流程，我们可以发现proactor模型最大的特点就是Proactor最大的特点是使用异步I/O。所有的I/O操作都交由系统提供的异步I/O接口去执行。工作线程仅仅负责业务逻辑。在Proactor中，用户函数启动一个异步的文件操作。同时将这个操作注册到多路复用器上。多路复用器并不关心文件是否可读或可写而是关心这个异步读操作是否完成。异步操作是操作系统完成，用户程序不需要关心。多路复用器等待直到有完成通知到来。当操作系统完成了读文件操作——将读到的数据复制到了用户先前提供的缓冲区之后，通知多路复用器相关操作已完成。多路复用器再调用相应的处理程序，处理数据。

Proactor增加了编程的复杂度，但给工作线程带来了更高的效率。Proactor可以在系统态将读写优化，利用I/O并行能力，提供一个高性能单线程模型。在windows上，由于没有epoll这样的机制，因此提供了IOCP来支持高并发， 由于操作系统做了较好的优化，windows较常采用Proactor的模型利用完成端口来实现服务器。在linux上，在2.6内核出现了aio接口，但aio实际效果并不理想，它的出现，主要是解决poll性能不佳的问题，但实际上经过测试，epoll的性能高于poll+aio，并且aio不能处理accept，因此linux主要还是以Reactor模型为主。

在不使用操作系统提供的异步I/O接口的情况下，还可以使用Reactor来模拟Proactor，差别是：使用异步接口可以利用系统提供的读写并行能力，而在模拟的情况下，这需要在用户态实现。具体的做法只需要这样：

注册读事件（同时再提供一段缓冲区）
事件分离器等待可读事件
事件到来，激活分离器，分离器（立即读数据，写缓冲区）调用事件处理器
事件处理器处理数据，删除事件(需要再用异步接口注册)
我们知道，Boost.asio库采用的即为Proactor模型。不过Boost.asio库在Linux平台采用epoll实现的Reactor来模拟Proactor，并且另外开了一个线程来完成读写调度。

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