[系统运维]Linux高性能之服务框架（11）

前言

I/O处理单元：本博客将介绍IO处理单元的四种IO模型和两种高效事件处理模式。逻辑单元。本章将介绍逻辑单元的两种高效并发模式，以及高效的逻辑处理方式——有限状态机。
存储单元：本博客不讨论存储单元，下一个讨论，因为它只是服务器程序的可选模块，而且其内容与网络编程本身无关。

服务器模型

C/S模型

最重要：C/S模型非常适应于资源相对集中的场合
缺点：当访问量过大时，可能client都会得到很慢的响应

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

C/S模型的逻辑很简单。服务器启动后，首先创建一个（或多个）监听socket，并调用bind函数将其绑定到服务器感兴趣的端口上，然后调用listen函数等待客户连接。服务器稳定运行之后，客户端就可以调用connect 函数向服务器发起连接了。由于客户连接请求是随机到达的异步事件，服务器需要使用某种IO模型来监听这一事件。IO模型有多种，下图，服务器使用的是I/O复用技术之一的select系统调用。当监听到连接请求后，服务器就调用accept 函数接受它，并分配一个逻辑单元为新的连接服务。逻辑单元可以是新创建的子进程、子线程或者其他。下图，服务器给客户端分配的逻辑单元是由fork 系统调用创建的子进程。逻辑单元读取客户请求，处理该请求，然后将处理结果返回给客户端。客户端接收到服务器反馈的结果之后，可以继续向服务器发送请求，也可以主动关闭连接。如果客户端主动关闭连接，则服务器执行被动关闭连接。至此，双方的通信结束。需要注意的是，服务器在处理一个客户请求的同时还会继续监听其他客户请求，否则就变成了效率低下的串行服务器了（必须先处理完前一个客户的请求，才能继续处理下一个客户请求)。下图，服务器同时监听多个客户请求是通过select系统调用实现的。

P2P

P2P(Peer to Peer，点对点）模型比CIS模型更符合网络通信的实际情况。它摒弃了以服务器为中心的格局，让网络上所有主机重新回归对等的地位。
P2P模型使得每台机器在消耗服务的同时也给别人提供服务，这样资源能够充分、自由地共享。云计算机群可以看作P2P模型的一个典范。
但P2P模型的缺点也很明显﹔当用户之间传输的请求过多时，网络的负载将加重。
图a：普通模型
提问？如果相互发现不了主机怎么办？
用的P2P模型通常带有-一个专门的发现服务器，如图b所示。这个发现服务器通常还提供查找服务（甚至还可以提供内容服务)，使每个客户都能尽快地找到自己需要的资源。

服务器编程框架

各部件作用：
I/O处理单元是服务器管理客户连接的模块。它通常要完成以下工作:等待并接受新的客户连接，接收客户数据，将服务器响应数据返回给客户端。但是，数据的收发不一定在IО处理单元中执行，也可能在逻辑单元中执行，具体在何处执行取决于事件处理模式（见后文)。对于一个服务器机群来说，I/O处理单元是一个专门的接入服务器**。它实现负载均衡,从所有逻辑服务器中选取负荷最小的一台来为新客户服务**。

一个逻辑单元通常是一个进程或线程。它分析并处理客户数据，然后将结果传递给IO处理单元或者直接发送给客户端（具体使用哪种方式取决于事件处理模式)。对服务器机群而言，一个逻辑单元本身就是一台逻辑服务器。服务器通常拥有多个逻辑单元，以实现对多个客户任务的并行外理。

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

请求队列是各单元之间的通信方式的抽象。IO处理单元接收到客户请求时，需要以某种方式通知一个逻辑单元来处理该请求。同样，多个逻辑单元同时访问一个存储单元时，也需要采用某种机制来协调处理竞态条件**。请**求队列通常被实现为池的一部分，我们将在后面讨论池的概念。对于服务器机群而言，请求队列是各台服务器之间预先建立的、静态的、永久的TCP连接。这种TCP连接能提高服务器之间交换数据的效率，因为它避免了动态建立TCP连接导致的额外的系统开销。

I/O模型

这篇博客讲到，socket在创建的时候默认是阻塞的。我们可以给socket系统调用的第2个参数传递SOCK_NONBLOCK标志，或者通过fcntl系统调用的F_SETFL命令，将其设置为非阻塞的。阻塞和非阻塞的概念能应用于所有文件描述符，而不仅仅是socket。我们称阻塞的文件描述符为阻塞I/O，称非阻塞的文件描述符为非阻塞IO.

针对阻塞IO执行的系统调用可能因为无法立即完成而被操作系统挂起，直到等待的事件发生为止。比如，客户端通过conncct向服务器发起连接时，connect将首先发送同步报文段给服务器，然后等待服务器返回确认报文段。如果服务器的确认报文段没有立即到达客户端，则connect调用将被挂起，直到客户端收到确认报文段并唤醒conncct调用。socket 的基础API中，可能被阻塞的系统调用包括accept、send、recv和 connect。

针对非阻塞IO执行的系统调用则总是立即返回，而不管事件是否已经发生。如果事件没有立即发生，这些系统调用就返回-1，和出错的情况一样。此时我们必须根据errno来区分这两种情况。
对accept.send和 recv而言，事件未发生时errno通常被设置成EAGAIN（意为“再来一次”)或者EWOULDBLOCK（意为“期望阻塞”)﹔
对connect而言，errno则被设置成EINPROGRESS（意为“在处理中")。

结论：很显然，我们只有在事件已经发生的情况下操作非阻塞IO（读、写等)，才能提高程序的效率。因此，非阻塞IO通常要和其他IO通知机制一起使用，比如IO复用和SIGIO信号。

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

SIGIO信号也可以用来报告IO事件。这个博客的最后一段提到，我们可以为一个目标文件描述符指定宿主进程，那么被指定的宿主进程将捕获到SIGIO信号。这样，当目标文件描述符上有事件发生时，SIGIO信号的信号处理函数将被触发，我们也就可以在该信号处理函数中对目标文件描述符执行非阻塞IO操作了。

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

两种高效的事件处理方式

前言

服务器程序通常需要处理三类事件**:IO事件、信号及定时事件**。我们将在后续博客依次讨论这三种类型的事件，这一节先从整体上介绍一下两种高效的事件处理模式: Reactor和Proactor.
应用场景：
Reactor ：主要用于实现 同步IO
Proactor：异步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上写入服务器处理客户请求的结果。

Proactor(siganl)

使用异步IO模型（以aio_read和aio_write为例）实现的Proactor模式的工作流程是:
1）主线程调用aio_read函数向内核注册socket 上的读完成事件，并告诉内核用户读缓冲区的位置，以及读操作完成时如何通知应用程序（这里以信号为例，详情请参考sigevent的 man手册)。
2)主线程继续处理其他逻辑。
3）当socket 上的数据被读入用户缓冲区后，内核将向应用程序发送一个信号，以通知应用程序数据已经可用。
4）应用程序预先定义好的信号处理函数选择一个工作线程来处理客户请求。工作线程处理完客户请求之后，调用aio_write函数向内核注册socket上的写完成事件，并告诉内核用户写缓冲区的位置，以及写操作完成时如何通知应用程序（仍然以信号为例)。
5)主线程继续处理其他逻辑。
6）当用户缓冲区的数据被写入socket之后，内核将向应用程序发送一个信号，以通知应用程序数据已经发送完毕。
7〉应用程序预先定义好的信号处理函数选择一个工作线程来做善后处理，比如决定是否关闭socket。
图示：

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

模拟Proactor

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

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

两种高效的并发模式

并发编程的目的是让程序“同时”执行多个任务。
如果程序是计算密集型的，并发编程并没有优势，反而由于任务的切换使效率降低。
但如果程序是I/O密集型的，比如经常读写文件，访问数据库等，则情况就不同了。由于IO操作的速度远没有CPU的计算速度快，所以让程序阻塞于IO操作将浪费大量的CPU时间。如果程序有多个执行线程，则当前被IO操作所阻塞的执行线程可主动放弃CPU（或由操作系统来调度)，并将执行权转移到其他线程。这样一来，CPU就可以用来做更加有意义的事情（除非所有线程都同时被IO操作所阻塞)，而不是等待IO操作完成，因此CPU的利用率显著提升。

半同步/半异步模式

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

按照同步方式运行的线程称为同步线程，按照异步方式运行的线程称为异步线程。显然**，异步线程的执行效率高，实时性强，这是很多嵌入式程序采用的模型**。但编写以异步方式执行的程序相对复杂，难于调试和扩展，而且不适合于大量的并发。而同步线程则相反，它虽然效率相对较低，实时性较差，但逻辑简单。因此，对于像服务器这种既要求较好的实时性，又要求能同时处理多个客户请求的应用程序，我们就应该同时使用同步线程和异步线程来实现，即采用半同步/半异步模式来实现。

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

I/0模型和集中处理模式搭配 则会半同步/半异步就会存在多种变体
简介一下：半同步/半反应堆

异步线程只有一个，由主线程来充当。它负责监听所有socket 上的事件。如果监听socket 上有可读事件发生，即有新的连接请求到来，主线程就接受之以得到新的连接socket，然后往 epoll 内核事件表中注册该socket 上的读写事件。如果连接socket 上有读写事件发生，即有新的客户请求到来或有数据要发送至客户端，主线程就将该连接socket插入请求队列中。所有工作线程都睡眠在请求队列上，当有任务到来时，它们将通过竞争（比如申请互斥锁）获得任务的接管权。这种竞争机制使得只有空闲的工作线程才有机会来处理新任务，这具很合理的
主线程和工作线程共享请求队列。主线程往请求队列中添加任务，或者工作线程从请求队列中取出任务，都需要对请求队列加锁保护，从而白白耗费CPU时间。
每个工作线程在同一时间只能处理一个客户请求。如果客户数量较多，而工作线程较少，则请求队列中将堆积很多任务对象，客户端的响应速度将越来越慢。如果通过增加工作线程来解决这一问题，则工作线程的切换也将耗费大量CPU时间。

升级相对高效半同步/半异步的模式

主线程只管理监听socket，连接socket由工作线程来管理。当有新的连接到来时，主线程就接受之并将新返回的连接socket派发给某个工作线程，此后该新socket 上的任何IO操作都由被选中的工作线程来处理，直到客户关闭连接。主线程向工作线程派发socket 的最简单的方式，是往它和工作线程之间的管道里写数据。工作线程检测到管道上有数据可读时，就分析是否是一个新的客户连接请求到来。如果是，则把该新socket 上的读写事件注册到自己的epoll 内核事件表中。

领导者模式/追随者模式

领导者/追随者模式是多个工作线程轮流获得事件源集合，轮流监听、分发并处理事件的一种模式。在任意时间点，程序都仅有一个领导者线程，它负责监听IO事件。而其他线程则都是追随者，它们休眠在线程池中等待成为新的领导者。当前的领导者如果检测到IO事件，首先要从线程池中推选出新的领导者线程，然后处理IO事件。此时，新的领导者等待新的IO事件，而原来的领导者则处理IO事件，二者实现了并发。

领导者/追随者模式包含如下几个组件:句柄集（HandleSet)、线程集（ThreadSet)、事件处理器（EventHandler）和具体的事件处理器（ConcreteEventHandler)。它们的关系如下：

1.句柄集
句柄（Handle）用于表示IO资源，在Linux下通常就是一个文件描述符。句柄集管理众多句柄，它使用wait_for_event方法来监听这些句柄上的IO事件，并将其中的就绪事件通知给领导者线程。领导者则调用绑定到Handle 上的事件处理器来处理事件。领导者将Handle和事件处理器绑定是通过调用句柄集中的register_handle方法实现的。

2.线程集
这个组件是所有工作线程（包括领导者线程和追随者线程）的管理者。它负责各线程之间的同步，以及新领导者线程的推选。线程集中的线程在任一时间必处于如下三种状态之一:

**Leader:**线程当前处于领导者身份，负责等待句柄集上的IO事件。
Processing :线程正在处理事件。领导者检测到I/O事件之后，可以转移到Processing状态来处理该事件，并调用promote_new_leader方法推选新的领导者;也可以指定其他追随者来处理事件（Event Handoff)，此时领导者的地位不变。当处于Processing状态的线程处理完事件之后，如果当前线程集中没有领导者，则它将成为新的领导者，否则它就直接转变为追随者。
Follower:线程当前处于追随者身份，通过调用线程集的ioin方法等待成为新的领导

3.事件处理器和具体的事件处理器
事件处理器通常包含一个或多个回调函数 handle_event。这些回调函数用于处理事件对应的业务逻辑。事件处理器在使用前需要被绑定到某个句柄上，当该句柄上有事件发生时，领导者就执行与之绑定的事件处理器中的回调函数。具体的事件处理器是事件处理器的派生类。它们必须重新实现基类的handle_event方法，以处理特定的任务。

缺点：无法每个工作线程独立地管理多个客户连接