高性能服务器程序框架

三、I/O模型

第5章讲到，socket在创建的时候默认是阻塞的。可以给socket系统调用的第2个参数传递SOCK_NONBLOCK标志，或者通过fcntl系统调用的F_SETFL命令，将其设置为非阻塞。

阻塞和非阻塞的概念能应用于所有文件描述符，而不仅仅是socket，我们称阻塞的文件描述符为阻塞I/O，称非阻塞的文件描述符为非阻塞I/O。

针对阻塞I/O执行的系统调用可能无法立即完成而被操作系统挂起，直到等待的事件发生为止。

比如:客户端通过connect向服务器发起连接时，connect将首先发发送同步报文给服务器，然后等待服务器返回确认报文段。如果服务器的确认报文段没有立即到达客户端，则connect调用将被挂起，直到客户端收到确认报文段并唤醒connect调用。socket的基础API中，可能被阻塞的系统调用包括accept、send、recv 和 connect。

针对非阻塞I/O执行的系统调用则总是立即返回，而不管事件是否已经发生。如果事件没有发生，这些系统调用就返回-1，和出错的情况一样。这时候我们必须根据errno来区分这两种情况。

• accept、send、recv：事件未发生时errno通常被设置成为EAGAIN(意思是“再来一次”)或者EWOULDBLOCK(意为“期望阻塞”)。
• connect：errno则被设置成为EINPROGRESS(意思是“在处理中”)。 显然，我们只有在事件已经发生的情况下操作非阻塞I/O(读、写等)，才能提高程序的效率。因此，非阻塞I/O通常要和其他I/O通知机制一起使用，比如I/O复用和SIGIO信号。

I/O复用是最常用的I/O通知机制。它指的是，应用程序通过I/O复用函数向内核注册一组事件，内核通过I/O复用函数把其中就绪的事件通知给应用程序。Linux上常用的I/O复用函数时select、poll和epoll_wait，我们将在第9章详细讨论它们。但是I/O复用函数本身是阻塞的，它们能提高程序效率的原因在于它们具有同时监听多个I/O事件的能力。

缺失信号驱动I/O讲解

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

表8-2 I/O模型对比

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

四、两种高效的事件处理模式(Reactor/Proactor)

同步I/O模型通常实现Reactor模式、异步I/O模型则用于实现Proactor模式。后面还会看到如何使用同步I/O方式模拟出Proactor模式。

4.1 Reactor模式

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

使用同步I/O模型(以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上写入服务器处理客户端请求的结果。

图8-5总结了Reactor模式的工作流程。

图8-5中，工作线程从请求队列中取出事件后，将根据事件的类型来决定如何处理它:

• 可读事件，执行读数据和处理请求的操作。
• 可写事件，执行写数据的操作。 因此，图8-5所示Reactor模式中，没有必要区分所谓的 "读工作线程" 和 "写工作线程"。

4.2 Proactor模式

与Reactor模式不同，Proactor模式将所有I/O操作都交给主线程和内核来处理，工作线程仅仅负责业务逻辑，因此，Proactor模式更符合图8-4所描述的服务器编程框架。

使用异步I/O模型(以aio_read和aio_write为例)实现的Proactor模式的工作流程是：

1. 主线程调用aio_read函数向内核注册socket上的读完成事件，并告诉内核用户读缓冲区的位置，以及读操作完成时如何通知应用程序。
2. 主线程继续处理其他逻辑。
3. 当 socket 上的数据被读入数据缓冲区后，内核将向应用程序发送一个信号，通知应用程序数据已经可用。
4. 应用程序预先定义好的信号处理函数选择一个工作线程来处理客户请求。工作线程处理完成客户请求之后，调用aio_write函数向内核注册socket上的写完成事件，并告诉内核用户写缓冲区的位置，以及写操作完成时如何通知应用程序。
5. 主线程继续处理其他逻辑。
6. 当用户缓冲区的数据被写入socket之后，内核将向应用程序发送一个信号，通知应用程序数据已经发送完毕。
7. 应用程序预先定义好的信号处理函数选择一个工作线程来做完善后处理，比如决定是否关闭socket。 如下是Proactor模式工作流程：

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

4.3 模拟Proactor模式

使用I/O方式模拟出 Proactor 模式的一种方法。其原理是: 主线程执行数据读写操作， 读写完成之后， 主线程向工作线程通知这一“完成事件”。那么从工作线程的角度来看，它们就直接获得了数据读写的结果，接下来要做的只是对读写的结果进行逻辑处理。

使用同步I/O模型(任然以epoll_wait为例)模拟出的 Proactor 模式的工作流程如下：

1. 主线程往epoll内核事件表中注册socket上的读就绪事件。
2. 主线程调用epoll_wait等待socket上有数据可读。
3. 当socket上有数据可读时，epoll_wait通知主线程。主线程从socket循环读取数据，直到没有更多数据可读，然后将读取到的数据封装成一个请求对象并插入请求队列中。
4. 睡眠在请求队列上的某个工作线程被唤醒，它获得请求对象并处理客户请求，然后往epoll事件表中注册socket上的写就绪事件。
5. 主线程调用epoll_wait等待socket可写。
6. 当socket可写时，epoll_wait通知主线程。主线程往socket上写入服务器处理客户请求的结果。

上图总结了使用同步I/O模型模拟出的Proactor模式的工作流程。