CN101256505A - 基于io事件通知机制的单进程内容服务器装置及方法 - Google Patents

Abstract

本发明公开了一种基于IO事件通知机制的单进程高性能内容服务器IO装置，包括请求队列，还包括前台线程、后台线程池和IO事件通知机制；其中，所述的前台线程与所述的请求队列、IO事件通知机制相连，所述的请求队列和所述的IO事件通知机制还连接到所述的后台线程池上，所述的前台线程还与外部的客户端连接。本发明还公开了一种实现IO请求处理的方法。本发明不仅减少了上下文切换和进程间通信和共享资源的开销，而且消除了创建线程的开销，并做到了线程数和连接数无关，从而可以达到高并发和高扩展性，满足大规模用户数的内容分发服务。

Description

基于IO事件通知机制的单进程内容服务器装置及方法

技术领域

本发明涉及单进程高性能内容服务器的输入输出，特别涉及一种基于IO事件通知机制的单进程高性能内容服务器IO装置及方法。

背景技术

内容分发服务器主要存储多媒体文档，如图形图像，媒体文件等。一个服务器在工作时通常会面对互联网上上万的并发请求，因此对服务器的网络IO(输入输出)和磁盘IO性能要求都很高。

常见的内容服务器IO一般使用多进程或多线程架构。这样做的主要原因是，网络IO和磁盘IO一般都是阻塞同步的，一个进程或线程执行一个连接上的IO操作时，整个进程或线程就被阻塞，无法同时处理其他连接，如果使用多个进程或线程，每个进程或线程对应一个连接，就可以实现并发处理，充分利用CPU资源。

附图1说明了多进程和多线程服务器的一般架构方式。服务器在初始化阶段预先创建多个进程或线程，形成进程池或线程池，其中一个进程或线程是主控进程或主控线程，其他进程或线程为工作进程或工作线程。主控进程或主控线程负责接收网络上到达的客户请求，并将请求分配给进程池或线程池中的工作进程或工作线程处理。工作进程或工作线程处理完毕后等待下一次主控进程或主控线程的调配。这种服务器的代表是Apache，它是目前最流行的Web内容服务器，可以在多进程和多线程两种模式下运行。

多进程服务器可以避免不断创建进程所带来的系统开销。但由于处理请求时它用一个进程来处理一个请求，如果要使服务器能够处理较高的负载，就必须加大预先创建的进程数，而预先创建进程数的上限会受到系统的限制，且进程间切换的开销比较大。另外，在多进程服务器中，进程间的通信和资源共享也很困难。

多线程服务器的优势体现在：一个进程的多个线程在同一进程的地址空间中，容易实现线程间的数据共享；在工作时，创建一个线程比创建一个进程的开销要小；线程的上下文切换发生在同一个进程内，所花费的开销比进程间切换的开销要少。与多进程服务器相比，由于多线程服务器消耗的资源要少，因此多线程服务器的扩展性要高很多。然而，由于在很多操作系统中，比较多数量的用户级线程复用了较少数量的内核执行体。当一个用户级线程调用了一个阻塞的系统调用，它对应的内核执行体也会被阻塞，会导致复用同一个执行体的其他用户级线程也阻塞，影响了系统性能，多线程的服务器的扩展性受到了限制。

由上述说明可见，多进程和多线程服务器都存在不同程度的缺点。于是操作系统提供了一种IO事件通知机制使得在一个线程之内可以并发处理多个网络IO请求。应用程序可以通过这种机制同时监听多个网络套接字，当某个套接字上有IO事件发生时，比如有新数据到达，这个套接字就有可读事件，这个事件及其相关信息可以通过一个系统调用返回到用户空间。结合非阻塞的网络IO，这个机制就能在单个进程或线程内完成并发处理。附图2说明了这种机制的使用流程。Linux/Unix/Windows中的select和poll系统调用、Linux中的epoll系统调用、FreeBSD中的kqueue系统调用都是IO事件通知机制。Lighttpd是单线程Web内容服务器的代表，其性能高于Apache。

由于没有了进程和线程的维护开销，基于IO事件通知机制的单线程服务器克服了前面所述的多进程和多线程服务器的缺点，可以达到很高的扩展性。但是，这种IO事件通知机制一般只能处理网络套接字的事件，不适用于磁盘文件描述符。而目前的服务器所服务的内容越来越大，无法存放在内存中，因此大量的磁盘IO在服务器中是不可避免的。但是当前操作系统中的磁盘IO一般都是同步阻塞的，所以单线程的服务器会因为磁盘IO而阻塞，服务器无法处理其他请求，使得服务器的性能下降。

发明内容

本发明的目的是克服单线程的服务器会因为磁盘IO而阻塞，服务器无法处理其他请求，使得服务器性能下降的缺陷，从而提供一种单进程高性能内容服务器的IO装置。

为了实现上述目的，本发明提供了一种基于IO事件通知机制的单进程高性能内容服务器IO装置，包括请求队列，还包括前台线程、后台线程池和IO事件通知机制；其中，所述的前台线程与所述的请求队列、IO事件通知机制相连，所述的请求队列和所述的IO事件通知机制还连接到所述的后台线程池上，所述的前台线程还与外部的客户端连接。

上述技术方案中，所述的前台线程是一个单一的线程，所述的前台线程负责接受外部客户端发来的新的网络连接，还负责发送和接收网络协议数据。

上述技术方案中，所述的后台线程池包括一个以上的工作线程，所述工作线程用于处理磁盘的IO操作。

上述技术方案中，所述的IO事件通知机制采用Linux中的epoll系统调用。

本发明还提供了一种在所述的基于IO事件通知机制的单进程高性能内容服务器IO装置中实现IO请求处理的方法，包括以下步骤：

步骤10)、所述前台线程等待外部客户端发来的IO事件通知；

步骤20)、所述前台线程读取客户端发来的IO请求，并解析该请求；

步骤30)、所述前台线程将解析后的请求放入所述的请求队列中；

步骤40)、所述请求队列中的新请求唤醒所述后台线程池中的一个空闲的工作线程，该工作线程根据请求的IO信息同步和阻塞地执行磁盘IO操作；

步骤50)、磁盘IO操作完成后，把操作结果写到一个管道中，所述的IO事件通知机制得到管道可读事件，并通知所述的前台线程；

步骤60)、所述的前台线程得到最终的结果，并将结果返回给客户端。

本发明结合了IO事件通知机制对于网络IO的处理优势和多线程对于同步阻塞的磁盘IO处理优势，有效地解决了内容服务器中高密集的网络IO和磁盘IO性能问题。较之背景技术中介绍的服务器架构，不仅减少了上下文切换和进程间通信和共享资源的开销，而且消除了创建线程的开销，并做到了线程数和连接数无关，从而可以达到高并发和高扩展性，满足大规模用户数的内容分发服务。

附图说明

图1是现有技术中多进程和多线程的服务器的工作流程图；

图2是现有技术中基于IO事件通知机制的单线程服务器的工作流程图；

图3是本发明的基于IO事件通知机制的单进程高性能内容服务器IO装置的结构图；

图4是本发明中IO请求处理方法的流程图；

图5是实施例边缘服务器的主控模块控制流程图；

图6是边缘服务器中所采用的epoll机制的循环控制流图。

具体实施方式

下面结合附图和具体实施方式对本发明作进一步详细描述：

如图3所示，本发明的单进程高性能内容服务器的输入输出部分包括：前台线程302、请求队列303、后台线程池304和IO事件通知机制305；其中，前台线程302与请求队列303、IO事件通知机制305相连，请求队列303和IO事件通知机制305还连接到后台线程池304上。

前台线程302是一个单一的线程，该线程主要用于处理网络IO，在具体实现时，前台线程不仅要负责接受新的网络连接，也要负责发送和接收网络协议数据。与背景技术中提到的多线程服务器相比，多线程服务器中的主控进程仅用于接收新的网络连接，并不对网络数据进行处理，这与前台线程302有着明显的区别。

后台线程池304中有多个工作线程，后台线程池304用于处理磁盘IO。

在前台线程302中，网络IO都被设置为非阻塞状态，所有的连接都在一个线程中被处理。操作系统提供IO事件通知方式305来告诉应用程序有哪些连接在什么时刻要求服务。为此，应用程序必须向操作系统声明一组自己感兴趣的网络套接字。操作系统将负责监视这些套接字，一旦有与套接字中的描述符相对应的网络连接有读或写事件发生。内核便会以事件的方式通知应用程序。依赖于这种事件通知机制，操作系统向应用层提供一组描述符所对应的事件的通知，进而支持所有的连接在单个线程中被处理。在前述的说明中已经提到，在本实施例中，所述的IO事件通知机制305采用Linux中的epoll系统调用。Epoll系统调用较之过去的select和poll，只返回有事件到达的描述符，这样就省去了遍历所有描述符来探测是否就绪的开销。在互联网环境中，面对大量质量不高的连接并发的情况下，可以提高性能。和实时信号相比，epoll也没有信号溢出的问题，适合于高并发的环境。

请求队列303是一个与后台线程共享的队列，请求队列303从前台线程302中接收外界的请求并存储，供后台线程池做后续操作。

在上述实现的基础上，本发明还提供了一种处理IO请求的方法，如图4所示，包含以下步骤：

步骤10、前台线程302等待客户端发来的IO事件通知；

步骤20、前台线程302读取客户端发来的请求，并解析该请求；

步骤30、前台线程302将解析后的请求放入请求队列303中；

步骤40、请求队列303中的新请求唤醒后台线程池304中的某一个工作线程，该工作线程根据请求的IO信息同步和阻塞地执行磁盘IO操作；

步骤50、步骤40中的操作完成后，把操作结果写到管道310中，IO事件通知机制305得到管道可读事件，并通知前台线程302；

步骤60、前台线程302得到最终的结果，并将结果写到网络套接字，返回给客户端。

在上述方法中，前台线程302在把磁盘IO请求放入请求队列303后就不需要阻塞地等待磁盘IO的完成，可以继续处理其他的网络IO。当磁盘IO完成后又可以通过IO事件通知机制及时获得结果。

在一个实施例中，以边缘服务器(ESP，Edge Service Provider)为例，对本发明作详细的说明。该边缘服务器运行在Linux操作系统上，采用Linux 2.6版本内核中的epoll作为IO事件通知机制。

ESP主要分为以下几个模块：

主控模块：系统的主线程，负责调度其他模块。其中负责前台监听事件的是EpollEventScheduler类，它负责EpollEvent事件的调度。

ContentRouter协议处理模块：处理与ContentRouter的交互。ContenRouter是用在内容分发系统协调ESP工作的模块。

下载协议处理模块：当用户需要从系统下载时，处理与用户的交互。

CMiddleServer模块：接受请求，将请求交由PPIO模块处理，从PPIO模块获得处理完的请求后再返回给提出请求的模块。

PPIO模块：底层文件系统负责实际的文件读写操作。即后台多线程处理磁盘IO。

下面分别对上述模块的具体实现进行说明：

A)、主控模块

主控模块是由CEspServer类实现，主要的类接口函数是CEspServer::Run()，采用EPOLL调度方式，当有套接字有事件到达时，调用套接字所对应对象的套接字处理函数进行处理，当套接字可写，会调用套接字所属对象的SendData()函数将输出缓冲区的数据向套接字写，当套接字可读，会调用套接字所属对象的RevData()函数从套接字接收数据到缓冲区，当遍历完所有有事件发生的套接字后，判断CCRAgent的输出缓冲区是否有数据，如果有数据就往CCRAgent的套接字写。然后判断aio_req_len＜MAXREQNUM，如果是则调用MiddleServer.WakeUpAgent()唤醒上次iosart失败的agent。

在CEspServer类中实现了一个超时处理机制：链表_timeList(C++STL List类型，元素是一个二元组结构<CAgent对象地址，到期时间>)，每当epoll返回时，会遍历这个链表，当发现到期时间大于当前时间时，则会调用CAgent(CBtAgent，CCPAgent)对象的超时处理函数。整个流程如附图5所示。

B)、EpollEventScheduler：Epoll调度模块，负责处理epoll事件。

EpollEventScheduler类负责EpollEvent事件的调度，主要的类接口函数有EpollEventScheduler::doEvent()负责注册EpollEvent，EpollEventScheduler::Run()采用EPOLL调度方式，当有EpollEvent有事件到达时，调用套接字所对应对象EpollEventHandler处理套接字事件，如果是写事件，调用EpollEventHandler的SendData()函数处理；如果是读事件，调用EpollEventHandler的RevData()函数处理，当遍历完所有有事件发生的套接字后调用Timer::Check()检查是否有定时器事件发生，然后调用MiddleServer::Check()处理未请求成功的ReqHandler对象。整个流程如附图6所示。

C)、PPIO模块

PPIO类作为ESP系统的一个子模块，其主要作用就是为上层MiddlerServer提供快速，高效的文件读写，查询，删除的功能。它利用C++中面向对象的思想，将各种实现封装起来，仅给用户提供必要的接口。用户通过接口实现对下层文件的操作。

在用户层实现了异步IO。本申请中的异步IO主要框架是采用预先创建线程，形成线程池。处理流程：对于Relay Server IO请求，通过Epoll获知有读事件，我们读socket，形成请求的数据结构，先把请求放入到请求队列上去，线程池里面的线程等待在条件锁上，当有请求到来的时候，线程池中的工作线程被唤醒，他们通过互斥锁到请求队列上面取回请求，工作线程采用同步的read/write系统调用处理IO，工作线程做完IO后通过一个管道向epoll发送一个数据结构的指针地址，这个数据结构里面包括了读回内容的Buf，返回的状态信息等，epoll收到通知后，调用read操作，从管道中读出数据结构的指针地址，通过这个指针，获取AIO完成后的结果信息，比如读请求的话，就获取结果Buf里面的内容，然后通过Socket把它发送到Relay Server。根据我们的性能比较，这种方式比前面几种实现性能都要高，而且实现起来比较容易。所以我们对磁盘IO的处理主要采用这种方式。

如果多个线程同时使用同一个文件描述符来进行I/O操作，你会发现传统的UNIX I/O接口不安全。在非串行的I/O(即并发)发生时会有问题。它使用lseek系统调用来为后续的read和write函数设置文件偏移量。如果两个或更多的线程使用lseek来移动同一个文件描述符，就会发生冲突。

为了避免冲突，使用新的pread和pwrite系统调用。

这些调用效果类似于read和write，不同之处在于多了一个参数，文件偏移量。用这个参数，你可以用不着用lseek(2)指定偏移量，多线程可以对同一个文件描述符进行安全的操作。因此在线程读写的时候，在我们程序里面尽量采用pread，pwrite的方式代替传统的read，write，保证线程读写的安全，而开始的时候我们采用的方式是用flock的方式先锁定文件描述符，然后进行IO操作，操作完成之后再解锁。用了pread，pwrite之后就不用我们来加锁了，因为lseek和读写的操作变成了一个原子操作，就不存在多个线程改变文件偏移量的而导致错误的担心。

ESP可以按照BitTorrent协议分发内容，测试表明在三千以上并发用户的随机磁盘访问请求下，在普通入门级服务器上运行的ESP只占用很低的CPU就可以充分利用磁盘能力和网络能力，到达10MB/s以上的网络吞吐率。

上述实施例是以ESP说明的，本发明也同样适用与其他类型的内容服务器。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行修改或者等同替换，都不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。

Claims (5)

1. 一种基于IO事件通知机制的单进程高性能内容服务器IO装置，包括请求队列，其特征在于，还包括前台线程、后台线程池和IO事件通知机制；其中，所述的前台线程与所述的请求队列、IO事件通知机制相连，所述的请求队列和所述的IO事件通知机制还连接到所述的后台线程池上，所述的前台线程还与外部的客户端连接。

2. 根据权利要求1所述的基于IO事件通知机制的单进程高性能内容服务器IO装置，其特征在于，所述的前台线程是一个单一的线程，所述的前台线程负责接受外部客户端发来的新的网络连接，还负责发送和接收网络协议数据。

3. 根据权利要求1所述的基于IO事件通知机制的单进程高性能内容服务器IO装置，其特征在于，所述的后台线程池包括一个以上的工作线程，所述工作线程用于处理磁盘的IO操作。

4. 根据权利要求1所述的基于IO事件通知机制的单进程高性能内容服务器IO装置，其特征在于，所述的IO事件通知机制采用Linux中的epoll系统调用。

5. 一种在权利要求1所述的基于IO事件通知机制的单进程高性能内容服务器IO装置中实现IO请求处理的方法，包括以下步骤：

步骤10)、所述前台线程等待外部客户端发来的IO事件通知；

步骤20)、所述前台线程读取客户端发来的IO请求，并解析该请求；

步骤30)、所述前台线程将解析后的请求放入所述的请求队列中；

步骤40)、所述请求队列中的新请求唤醒所述后台线程池中的一个空闲的工作线程，该工作线程根据请求的IO信息同步和阻塞地执行磁盘IO操作；

步骤50)、磁盘IO操作完成后，把操作结果写到一个管道中，所述的IO事件通知机制得到管道可读事件，并通知所述的前台线程；

步骤60)、所述的前台线程得到最终的结果，并将结果返回给客户端。

Images