高效的事件处理模式——Reactor、Proactor

IO模型

从理论上说，阻塞IO、IO复用和信号驱动IO都是同步IO模型。因为在这三种IO模型中，IO的读写操作，都是在IO事件发生之后，由应用程序来完成的。而POSIX规范所定义的异步IO模型则不同。对异步IO而言，用户可以直接对IO执行读写操作，这些操作告诉内核用户读写缓冲区的位置，以及IO操作完成之后内核通知应用程序的方式。异步IO的读写操作总是立即返回，而不论I/O是否是阻塞的，因为真正的读写操作已经由内核接管。也就是说，同步IO模型要求用户代码自行执行IO操作（将数据从内核缓冲区读人用户缓冲区，或将数据从用户缓冲区写人内核缓冲区)，而异步IO机制则由内核来执行I/О操作〈数据在内核缓冲区和用户缓冲区之间的移动是由内核在“后台”完成的)。你可以这样认为，同步IO向应用程序通知的是IO就绪事件，而异步IO向应用程序通知的是IO完成事件。Linux环境下，aio.h头文件中定义的函数提供了对异步IO的支持。

lO模型	读写操作和阻塞阶段
阻塞IO	程序阻塞于读写函数
I/O复用	程序阻塞于I/O复用系统调用，但可同时监听多个IO事件。对IO本身的读写操作是非阻塞的
SIGIO信号	信号触发读写就绪事件，用户程序执行读写操作。程序没有阻塞阶段
异步IO	内核执行读写操作并触发读写完成事件。程序没有阻塞阶段

---

Reactor模式

Reactor是这样一种模式，它要求主线程（IO处理单元，下同）只负责监听文件描述上是否有事件发生，有的话就立即将该事件通知工作线程（逻辑单元，下同)。除此之外，主线程不做任何其他实质性的工作。读写数据，接受新的连接，以及处理客户请求均在工作线程中完成。 使用同步IO模型（以epoll_wait为例）实现的 Reactor模式的工作流程是:

1. 主线程往epoll 内核事件表中注册socket上的读就绪事件。

2. 主线程调用epoll _wait等待socket 上有数据可读。

3. 当socket 上有数据可读时，epoll_wait通知主线程。主线程则将socket可读事件放入请求队列。

4. 睡眠在请求队列上的某个工作线程被唤醒，它从 socket读取数据，并处理客户请求，然后往epoll内核事件表中注册该socket上的写就绪事件。

5. 主线程调用epoll_wait等待socket可写。

6. 当socket可写时，epoll_wait通知主线程。主线程将socket可写事件放入请求队列。

7. 睡眠在请求队列上的某个工作线程被唤醒，它往 socket上写人服务器处理客户请求的结果。

工作线程从请求队列中取出事件后，将根据事件的类型来决定如何处理它﹔对于可读事件，执行读数据和处理请求的操作﹔对于可写事件，执行写数据的操作。因此,Reactor模式中，没必要区分所谓的“读工作线程”和“写工作线程”。

---

Proactor

与Reactor模式不同，Proactor模式将所有IO操作都交给主线程和内核来处理，工作线程仅仅负责业务逻辑。

使用异步IO模型（以aio_read 和 aio_write为例）实现的Proactor模式的工作流程是:

1. 主线程调用aio_read函数向内核注册socket 上的读完成事件，并告诉内核用户读缓冲区的位置，以及读操作完成时如何通知应用程序（这里以信号为例，详情请参考sigevent的man手册)。

2. 主线程继续处理其他逻辑。

3. 当socket上的数据被读入用户缓冲区后，内核将向应用程序发送一个信号，以通知应用程序数据已经可用。

4. 应用程序预先定义好的信号处理函数选择一个工作线程来处理客户请求。工作线程处理完客户请求之后，调用aio_write函数向内核注册socket 上的写完成事件，并告诉内核用户写缓冲区的位置，以及写操作完成时如何通知应用程序（仍然以信号为例)。

5. 主线程继续处理其他逻辑。

6. 当用户缓冲区的数据被写人socket之后，内核将向应用程序发送一个信号，以通知应用程序数据已经发送完毕。

7. 应用程序预先定义好的信号处理函数选择一个工作线程来做善后处理，比如决定是否关闭socket。

在图8-6中，连接socket 上的读写事件是通过aio_read/aio_write向内核注册的，因此内核将通过信号来向应用程序报告连接socket 上的读写事件。所以，主线程中的epoll_wait调用仅能用来检测监听socket 上的连接请求事件，而不能用来检测连接socket 上的读写事件。