I/0模型

在高性能服务器中，一般采用非阻塞网络IO，单进程事件驱动的架构。这种架构的核心是事件驱动机制。目前Linux常用select，poll和epoll系统调用来完成事件驱动。select和poll是传统的unix事件驱动机制，但它们有很大的缺点：在大量的并发连接中，如果冷连接较多，select和poll的性能会因为并发数的线性上升而成平方速度的下降，这是因为调用者在每次select和poll返回时都要检测每个连接是否有事件发生，当连接数很大时，系统开销会非常大。另外select和poll每次返回时都要从内核向用户空间复制大量的数据，这样的开销也很大。所以，select和poll并不是处理网络IO的最好方案。

于是从Linux2.5开始，出现了一个新的系统调用epoll，它不仅可以完成select/epoll的功能，而且性能更高，功能更强。epoll的优点：1,每次只返回有事件发生的文件描述符信息，这样调用者不用遍历整个文件描述符队列，而且系统不用从内核向用户空间复制大量无用的数据；2,epoll可以设置不同的事件触发方式：边缘触发和电平触发，为用户使用epoll提供了灵活性。epoll也有缺点：1,在冷连接很少的情况下，性能与select和poll相比并没有什么优势；2,目前的实现还不完整，不支持EPOLLHUP事件，在边缘触发情况下，无法处理客户端网络连接主动断开；3,使用比较麻烦，如何边缘触发方式必须要小心处理，否则程序可能无法完成功能,在采用电平触发方式时，调用者要避免epoll_wait发生空转。

一， 磁盘IO

Linux磁盘IO有同步模式和异步模式。同步模式就是常见read/write系统调用，这两个系统调用都被认为是低速系统调用，执行时可能会使进程阻塞，在单进程的服务器中，这会使系统性能下降。所以Linux提供了异步磁盘IO。目前Linux中主要有两种异步IO解决方案：1,由glibc 实现的Posix AIO（aio_read，aio_write，….），采用线程或实时信号来通知IO完成，用户也可以采用轮询方式来检测IO是否完成；2,由kernel实现的Linux AIO(io_setup, io_getevents,…)，事件的通知机制(io_getevents)是采用类似select的语义。它们的共同点都是采用了多线程的方式来处理阻塞的磁盘IO，使其看起来像异步的。这两种方式主要区别是：1,Posix AIO是在用户态下实现的而Linux AIO是在内核中实现的；2,事件的通知机制不同，前面已说明。Posix AIO和Linux AIO性能的比较还没有做过。Linux的异步磁盘IO机制的缺点是：无论Posix AIO还是Linux AIO在处理新的IO请求时都会做创建线程的操作，这样比较的费时。

Linux磁盘IO还可以用内存映射的方式，优点是：1,可以避免在用户空间和内核空间之间复制数据；2,如果把小文件合成大文件，对大文件进行内存映射，可以减少open系统调用的次数。但内存映射的缺点也很明显：1,由于3G以上的大文件无法映射进内存，使用有局限性；2,如果所访问的页面不在内存中，需要进行换页操作，进程会阻塞。虽然合理地使用mincore可以避免进程阻塞，但编程实现难度较高。

如果是从磁盘向网络传送数据的话还可以使用sendfile，sendfile可以在内核空间中直接从磁盘向网络传送数据，避免了内存复制。

二， 同时处理网络IO和磁盘IO

数据服务器要同时处理大量的并发网络连接，而且处理这些网络连接需要进行大量的磁盘IO，如读取文件。在这样情况下，我们提出了两种模型：

1,分离网络IO和磁盘IO。这种模型是指用一个进程（RelayServer）来处理大量并发的网络连接，另一个进程（DataServer）处理磁盘IO，两个进程通过一个TCP连接交换信息，当客户（Client）请求到达，RelayServer将其转发给DataServer，DataServer去磁盘上读数据，读好数据后，将数据回传给RelayServer，RelayServer再转发给Client。

2,不分离网络IO和磁盘IO。这种模型是指只用一个进程（DataServer）来同时处理磁盘IO和网络IO。

下面讨论这两种模型的实现方案：

无论是采用哪种模型，都涉及到对大量磁盘IO的处理。根据前面对Linux磁盘IO的讨论，我们试验了以下几种磁盘IO的实现方式：

1,Posix AIO，实时信号通知。由于磁盘IO通常会在较短的时间内完成，进程频繁地被信号中断，系统调用频繁自动重启动，造成整个性能的下降。另外，因为无法向信号处理函数传参数，信号处理函数很难实现较为复杂的功能。

2,Posix AIO，线程通知。每完成一个IO请求，系统就会创建线程，开销较大。

3,Posix AIO，轮询。很难跟DataServer的epoll逻辑结合，只有不断轮询，性能较低。
Linux AIO未作测试，性能未知。内存映射无法处理很大的文件，也未采用。

从上面看来，Linux提供的异步IO机制无法满足我们的需求，于是我们自己在用户层实现了异步IO。我们的异步IO主要框架是采用预先创建线程，形成线程池。处理流程：用户发IO请求，线程池中的工作线程被唤醒，工作线程采用一般的read/write系统调用处理IO（为了保证磁盘IO能够完成，我们用的是readn和writen），工作线程做完IO后通过一个管道向epoll通知，并把用户IO的请求挂到完成队列上，epoll收到通知后，从完成队列中取下，再做相应的操作。根据我们的性能比较，这种方式比前面几种实现性能都要高，而且实现起来比较容易。所以我们对磁盘IO的处理主要采用这种方式，但针对不分离模型和分离模型的不同细节，又有所变化。

针对不分离模型，我们系统使用epoll管理socket描述符和一个管道描述符（磁盘IO用管道来通知epoll）。epoll只处理socket的读事件，负责完整收到Client一个请求，然后把请求交给磁盘IO。磁盘IO使用线程池，跟前面的区别在于，工作线程在读数据时使用sendfile，直接将磁盘数据发给对应的网络套接字，如果sendfile返回EAGAIN错误或者没发完数据，就更新请求，然后把请求重新放回队列。

分离的模型中DataServer也是用epoll管理socket描述符和与磁盘IO通信的管道描述符。epoll需要处理socket的读事件和写事件，负责从RelayServer收请求和向RelayServer发送数据。磁盘IO与前面的模型一致。

不分离模型和分离模型的对比结论：

1,不分离模型和分离模型在面对200左右并发连接数时性能上基本一致。测试表明：当请求读文件的大小较大时（超过256KB），无论OS对文件的缓存命中率大小，两种模型所能达到的网络吞吐量都差不多(20-30MB/S)。并且网络吞吐量随着请求文件大小的增大而增大，在这种情况下，磁盘IO严重滞后于网络IO和CPU的速度，所以网络吞吐量由磁盘IO的速度所决定。因为当读文件较大时，根据磁盘IO特点，磁盘吞吐量会较高，所以请求文件越大，网络吞吐量越好。当请求文件的大小较小时（如16KB和64KB），如果OS文件缓存的命中率较高，磁盘IO在整个系统中几乎没有影响，网络的吞吐量基本可以达到网卡的物理上限。但是，当OS文件缓存命中率很小时，由于磁盘IO很难高效地处理对小块数据的读，整个系统性能受制于磁盘IO，并且网络吞吐量和磁盘吞吐量都很低（4MB/S）。总得来看，无论使用哪种模型，磁盘IO都是瓶颈。

2,不分离模型的优缺点。优点：1,不分离模型的实现较为容易，可以使用sendfile等高效的系统调用。2,由于对每个并发连接不需要分配大量的内存缓冲区来缓存从磁盘读到的数据，对并发连接数的支持可以不受内存大小的限制，具有较好的伸缩性。缺点：可扩展性不足，比如对于客户端要求写文件就很难处理，而且如果加上复杂的协议分析，性能可能会大幅度下降。

3,分离模型的优缺点。优点：扩展性好，可以专门对磁盘IO进行优化，而不必考虑其对同时处理大量并发网络连接的影响；针对网络IO也可以添加复杂协议的分析，不必考虑对同时处理磁盘IO的影响。缺点：实现较为复杂，实现方案直接影响系统性能；用户接收数据的速率不平滑，有时会较长时间没有数据到达，而有时会瞬间到达很多数据，这样对于流媒体的应用，用户体验会很差。

三， 结论

针对我们的需求，决定使用分离模型。因为分离模型的扩展性很好，并且通过优化预计可以达到较高的效率。