高性能服务器框架

主要由I/O单元，逻辑单元和网络存储单元组成，其中每个单元之间通过请求队列进行通信，从而协同完成任务。

其中

• I/O单元用于处理客户端连接，读写网络数据；

• 逻辑单元用于处理业务逻辑的线程；

• 网络存储单元指本地数据库和文件等。

 

1、服务器模型

C/S模型

特点：

逻辑简单。

工作流程：

TCP/IP协议在设计和实现上并没有客户端和服务器的概念，在通信过程中所有机器都是对等的。但由于资源都被数据提供者所垄断，所以几乎所有的网络应用程序都很自然地采用了C/S模型：所有客户端通过访问服务器来获取所需的服务。

服务器启动后，首先创建一个或多个监听socket，并调用bind函数将其绑定到服务器感兴趣的端口上，然后调用listen函数等待客户端连接。服务器稳定运行之后，客户端就可以调用connect函数向服务器发起连接了。

由于客户连接请求是随机到达的异步事件，服务器需要使用某种I/O模型来监听这一事件。I/O模型有多种

图8.2中，服务器使用的是I/O复用技术之一的select系统调用。当监听到连接请求后，服务器就调用accept函数接受它，并分配一个逻辑单元为新的连接服务。

逻辑单元可以是新创建的子进程、子线程或者其他。图8.2中，服务器给客户端分配的逻辑单元是由fork系统调用创建的子进程。

逻辑单元读取客户请求，处理该请求，然后将处理结果返回给客户端。客户端接收到服务器反馈的结果之后，可以继续向服务器发送请求，也可以立即主动关闭连接。如果客户端主动关闭连接，则服务器执行被动关闭连接。

C/S模型非常适合资源相对集中的场合，并且它的实现也很简单，

但其缺点也很明显：服务器是通信的中心，当访问量过大时，可能所有客户将得到很慢的响应。P2P模型解决了这个问题。

P2P模型

P2P模型模型比C/S模型更符合网络通信的实际情况。它摒弃了以往以服务器为中心的格局，让网络上所有主机重新回归对等的地位。

P2P模型使得每台机器在消耗服务的同时也给别人提供服务，这样自愿能够充分、自由地共享。云计算机群可以看做P2P模型的典范。但P2P模型的缺点也很明显：当用户之间传输的请求过多时，网络的负载将加重。

实际使用的P2P模型通常带有一个专门的发现服务器，如图8-3所示。发现服务器通常还提供查找服务，使每个客户都能尽快找到自己需要的资源。

从编程角度来看，P2P模型可以看做是C/S模型的扩展：每台主机既是客户端，又是服务器。

2、服务器编程框架

主要由I/O单元，逻辑单元和网络存储单元组成，其中每个单元之间通过请求队列进行通信，从而协同完成任务。

其中

• I/O单元用于处理客户端连接，读写网络数据；

• 逻辑单元用于处理业务逻辑的线程；

• 网络存储单元指本地数据库和文件等。

I/O处理单元

是服务器管理客户连接的模块。它通常要完成以下工作：等待并接受新的客户端连接，接收客户数据，将服务器响应数据返回给客户端。

但是，数据的收发不一定在I/O处理单元中执行，也可能在逻辑单元中执行，具体在何处执行取决于事件处理模式。对于一个服务器机群来说，I/O处理单元是一个专门的接入服务器。它实现负载均衡，从所有逻辑服务器中选取负荷最小的一台来为新客户服务。

逻辑单元

通常是一个进程或线程。它分析并处理客户数据，然后将结果传递给I/O处理单元或者直接发送给客户端。

对服务器机群而言，一个逻辑单元本身就是一台逻辑服务器。服务器通常拥有多个逻辑单元，以实现对多个客户任务的并行处理。

网络存储单元

可以是数据库、缓存和文件，甚至是一台独立的服务器。但它不是必须的，比如ssh、telnet等登录服务就不需要这个单元。

请求队列

是各单元之间的通信方式的抽象。I/O处理单元接收到客户请求时，需要以某种方式通知一个逻辑单元来处理该请求。

同样，多个逻辑单元同时访问一个存储单元时，也需要采用某种机制协调处理竞态条件。请求队列通常被实现为池的一部分。对于服务器机群而言，请求队列是各台服务器之间预先建立的、静态的、永久的TCP连接。这种TCP连接能提高服务器之间交换数据的效率，因为它避免了动态建立TCP连接导致的额外的系统开销。 ————————————————

3、I/O模型

阻塞I/O

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

阻塞和非阻塞的概念能应用于所有文件文件描述符，而不仅仅是socket。

• 我们称阻塞的文件描述符为阻塞I/O，

• 称非阻塞的文件描述符为非阻塞I/O。

 

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

比如客户端通过connect向服务器发起连接时，connect将首先发送同步报文段给服务器，然后等待服务器返回确认报文段。如果服务器的确认报文段没有立即到达客户端，则connect调用将被挂起，直到客户端收到确认报文段并唤醒connect调用。

socket的基础I/O中，可能被阻塞的系统调用包括accept、send、recv和connect。

非阻塞I/O

针对非阻塞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。I/O复用本身是阻塞的，它们能提高程序效率的原因在于它们能同时监听多个I/O事件的能力。

SIGIO/信号驱动I/O

SIGIO信号也可以用来报告I/O事件。我们可以给一个目标文件描述符指定宿主进程，那么被指定的宿主进程将捕获到SIGIO信号。这样，当目标文件描述符上有事件发生时，SIGIO信号的信号处理函数将被触发，我们可以再该信号处理函数中对目标文件描述符执行非阻塞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操作（将数据从内核缓冲区读入用户缓冲区，或将数据从用户缓冲区写入内核缓冲区）

• 而异步I/O机制则由内核来执行I/O操作（数据在内核缓冲区和用户缓冲区之间的移动是由内核在“后台”完成的）。

可以这样认为，同步I/O向应用程序通知的是I/O就绪事件，而异步I/O向应用程序通知的是I/O完成事件。

总结

五种I/O模型

• 阻塞IO:调用者调用了某个函数，等待这个函数返回，期间什么也不做，不停的去检查这个函数有没有返回，必须等这个函数返回才能进行下一步动作

• 非阻塞IO:非阻塞等待，每隔一段时间就去检测IO事件是否就绪。没有就绪就可以做其他事。非阻塞I/O执行系统调用总是立即返回，不管时间是否已经发生，若时间没有发生，则返回-1，此时可以根据errno区分这两种情况，对于accept，recv和send，事件未发生时，errno通常被设置成eagain

• 信号驱动IO: linux用套接口进行信号驱动IO，安装一个信号处理函数，进程继续运行并不阻塞，当IO时间就绪，进程收到SIGIO信号。然后处理IO事件。

• IO复用:linux用select/poll函数实现IO复用模型，这两个函数也会使进程阻塞，但是和阻塞IO所不同的是这两个函数可以同时阻塞多个IO操作。而且可以同时对多个读操作、写操作的IO函数进行检测。知道有数据可读或可写时，才真正调用IO操作函数

• 异步IO: linux中，可以调用aio_read函数告诉内核描述字缓冲区指针和缓冲区的大小、文件偏移及通知的方式，然后立即返回，当内核将数据拷贝到缓冲区后，再通知应用程序。

4、事件处理模式

服务器程序通常需要处理三类事件：I/O事件、信号及定时事件。 同步I/O模型通常用于实现Reactor模式，异步I/O则用于实现Proactor模式。

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上写入服务器处理客户请求的结果。

 

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

对于可读事件，执行读数据和处理请求的操作；

对于可写事件，执行写数据的操作。

因此，在Reactor模式中，没必要区分所谓的“读工作线程”和“写工作线程”。

Proactor模式

与Reactor模式不同，Proactor模式将所有I/O操作都交给主线程和内核来处理，工作线程仅仅负责业务逻辑。 使用异步I/O模型（以aio_read和aio_write为例）实现的Proactor模式的工作流程是：

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

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

模拟Proactor模式

使用同步I/O方式模拟出Proactor模式。

总结

• reactor模式中，主线程(I/O处理单元)只负责监听文件描述符上是否有事件发生，有的话立即通知工作线程(逻辑单元 )，读写数据、接受新连接及处理客户请求均在工作线程中完成。通常由同步I/O实现。

• proactor模式中，主线程和内核负责处理读写数据、接受新连接等I/O操作，工作线程仅负责业务逻辑，如处理客户请求。通常由异步I/O实现。

同步I/O模拟proactor模式

由于异步I/O并不成熟，实际中使用较少，这里将使用同步I/O模拟实现proactor模式。

同步I/O模型的工作流程如下（epoll_wait为例）：

原理是：

主线程执行数据的读写操作，读写完成之后，主线程向工作线程通知这一“完成事件”。那么从工作线程的角度来

看，它们就直接获得了数据读写的结果，接下来要做的只是对读写的结果进行逻辑处理。

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

2）主线程调用epoll_wait等待socket上有数据可读。

3）当socket上有数据可读时，epoll_wait通知主线程。主线程从socket循环读取数据，直到没有更多的数据可读，然后将读取到的数据封装成一个请求对象并插入到请求队列。

4）睡眠在请求队列上的某个线程被唤醒，它获得请求对象并处理客户请求，然后往epoll内核事件表中注册epoll_wait等待socket可写。

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

6）当socket可写时，epoll_wait通知主线程。主线程往socket上写入服务器处理客户请求的结果。

5、并发模式

并发编程方法的实现有多线程和多进程两种，但这里涉及的并发模式指I/O处理单元与逻辑单元的协同完成任务的方法。

• 半同步/半异步模式

• 领导者/追随者模式

并发编程的目的是让程序“同时”执行多个任务。

• 如果程序是计算密集型的，并发编程并没有优势，反而由于任务的切换使效率降低。

• 但如果程序是I/O密集型的，比如经常读写文件，访问数据库等，则情况就不同了。

由于I/O操作的速度远没有CPU的计算速度快，所以让程序阻塞于I/O操作将浪费大量的CPU事件。

如果程序有多个执行线程，则当前被I/O操作所阻塞的执行线程可主动放弃CPU（或由操作系统来调度），并将执行权转移到其他线程。这样一来，CPU就可以用来做更多有意义的事情（除非所有的线程都同时被I/O操作所阻塞），而不是等待I/O操作完成，因此CPU的利用率显著提升。

半同步/半异步模式

半同步/半异步模式中的“同步”和“异步”与I/O模型中的“同步”和“异步”是完全不同的概念。

• 在I/O模型中，“同步”和“异步”区分的是内核向应用程序通知的是何种I/O事件（是就绪事件还是完成事件），以及该由谁来完成I/O读写（应用程序还是内核）。

• 在并发模式中，“同步”指的是程序完全按照代码序列的顺序执行；“异步”指的是程序的执行顺序需要由系统事件来驱动。常见的系统事件包括终端、信号等。

按照同步方式运行的线程称为同步线程，按照异步方式运行的线程称为异步线程。

优缺点

异步线程的执行效率高，实时性强，这是很多嵌入式程序采用的模型。但编写以异步方式执行的程序相对复杂，难于调试和扩展，而且不适合于大量的并发。

同步线程则相反，它虽然效率低，实时性较差，但逻辑简单。

因此，对于向服务器这种既要求较好的实时性，又要求同时处理多个客户请求的应用程序，我们就应该同时使用同步线程和异步线程来实现，即采用半同步/半异步模式来实现。

半同步/半异步模式中，同步线程用于处理客户逻辑，相当于图8-4中的逻辑单元；异步线程用于处理I/O事件，相当于图8-4中的I/O处理单元。

异步线程监听到客户请求后，就将其封装成请求对象并插入请求队列中。请求队列将通知某个工作在同步模式的工作线程来读取并处理该请求对象。具体选择哪个工作线程来为新的客户服务，则取决于请求队列的设计。比如最简单的轮流选取工作线程的Round Robin算法，也可以通过条件变量或信号量来随机地选择一个工作线程。 ————————————————

 

一种半同步/半异步的变体称为半同步/半反应堆模式。

半同步/半反应堆模式。

---

图8-10中，异步线程只有一个，由主线程充当。它负责监听所有socket上的事件。

如果监听socket上有可读事件发生，即有新的连接请求到来，主线程就接受之以得到新的连接socket，

然后往epoll内核事件表中注册该socket上的读写事件。如果连接socket上有读写事件发生，即有新的客户请求到来或有数据要发送至客户端，主线程就将该连接socket插入请求队列中。

所有工作线程都睡眠在请求队列上，当有任务到来时，它们将通过竞争（比如申请互斥锁）获得任务的接管权。这种竞争机制使得只有空闲的工作线程才有机会来处理新任务，这是很合理的。

半同步/半反应堆模式存在如下缺点：

• 1、主线程和工作线程共享请求队列。主线程往请求队列中添加任务，或者工作线程从请求队列中取出任务，都需要对请求队列加锁保护，从而白白耗费CPU时间。

• 2、每个工作线程在同一时间只能处理一个客户请求。如果客户数量较多，而工作线程较少，则请求队列中将堆积很多任务对象，客户端的响应速度将越来越慢。如果通过增加工作线程来解决这一问题，则工作线程的切换也会耗费大量CPU时间。

总结

半同步/半异步模式工作流程

• 同步线程用于处理客户逻辑

• 异步线程用于处理I/O事件

• 异步线程监听到客户请求后，就将其封装成请求对象并插入请求队列中

• 请求队列将通知某个工作在同步模式的工作线程来读取并处理该请求对象

半同步/半反应堆工作流程（以Proactor模式为例）

• 主线程充当异步线程，负责监听所有socket上的事件

• 若有新请求到来，主线程接收之以得到新的连接socket，然后往epoll内核事件表中注册该socket上的读写事件

• 如果连接socket上有读写事件发生，主线程从socket上接收数据，并将数据封装成请求对象插入到请求队列中

• 所有工作线程睡眠在请求队列上，当有任务到来时，通过竞争（如互斥锁）获得任务的接管权

 

新的半同步/半异步模式

图8-11描述了一种相对高效的半同步/半异步模式，它的每个工作线程都能同时处理多个客户连接。

主线程只管监听socket，连接socket由工作线程来管理。

当有新的连接到来时，主线程就接受之并将新返回的连接socket派发给某个工作线程，此后该新socket上的任何I/O操作都由被选中的工作线程来处理，直到客户关闭连接。

主线程向工作线程派发socket的最简单的方式，是往它和工作线程之间的管道里写数据工作线程检测到管道有数据可读时，就分析是否是一个新的客户连接请求到来。如果是，则把该新socket上的读写事件注册到自己的epoll内核事件表中。

每个线程（主线程和工作线程）都维持自己的事件循环，它们各自独立地监听不同的事件。因此，在这种高效的半同步/半异步模式中，每个线程都工作在异步模式，所以它并非严格意义上的半同步/半异步模式。

领导者/追随者模式

领导者/追随者模式是多个工作线程轮流获得事件源集合，轮流监听、分发并处理事件的一种模式。

在任何时间点，程序都仅有一个领导者线程，它负责监听I/O事件。而其他线程则都是追随者，它们休眠在线程池中等待成为新的领导者。

当前的领导者如果检测到I/O事件，首先要从线程池中推选出新的领导者线程，然后处理I/O事件。此时，新的领导者等待新的I/O事件，而原来的领导者则处理I/O事件，二者实现了并发。

在任意时间点，程序都仅有一个领导者线程， 它负责监听I/O事件，而其他线程都是追随者，它们休眠在进程池等待成为新的领导者。当前领导者如果检测到I/O事件，首先要从线程池中推选出新的领导者线程，然后处理I/O事件。

句柄集：表示I/O资源，在Linux下通常就是一个文件描述符。

线程集：所有工作线程的管理者。负责各线程之间的同步和新领导者线程的推选。

事件处理器及其子类： 用回调函数的方式处理某事件发生时对应的业务。