架构师修炼系列【计算高性能[单服务器高性能]】

以你之姓@ 2022-12-06 05:48 202阅读 0赞

架构师的视角当然需要特别关注高性能架构的设计，而高性能架构设计主要集中在两方面：

*  尽量提升单服务器的性能，将单服务器的性能发挥到极致
 *  如果单服务器无法支撑性能，设计服务器集群方案

除了以上两点，最终系统能否实现高性能，还和具体的实现及编码相关 。但架构设计是高性能的基础，如果架构设计没有做到高性能，则后面的具体实现和编码能提升的空间是有限的 。形象地说，架构设计决定了系统性能的上限，实现细节决定了系统性能的下限

## 单服务器高性能 ##

单服务器高性能的关键之一就是服务器采用的网络编程模式，网络编程模式的设计有两个关键点：

*  服务器如何管理链接
 *  服务器如何处理请求

而这两点最终都和操作系统的I/O模型及进程模型相关：

*  I/O模型：阻塞、非阻塞、同步、异步
 *  进程模型：单进程、多进程、多线程、单线程

### PPC ###

PPC 是 Process per Connection 的缩写 ，其含义是指每次有新的连接就新建一个进程去专 门 处理这个连接的请求 ，这是传统的 UNIX 网络服务器所采用的模型，其基本的流程是这样的：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center]

>  *  父进程接受链接，然后fork子进程
>  *  子进程处理链接相关请求，然后子进程关闭连接
>  *  父进程fork子进程后，调用了close，实际上并不是关闭连接，而是将连接的文件描述符引用计数减一，真正的关闭连接时等子进程也调用了close之后，链接对应的文件描述符引用计数变为0后，操作系统才会真正的关闭连接

PPC 模式实现简单，比较适合服务器的连接数没那么多的情况。例如，数据库服务器。对 于普通的业务服务器，在互联网兴起之前，由于服务器的访问量和并发量并没有那么大，这种 模式其实运作得也挺好 。而互联网 兴起后，服务器的并发和访 问 量从几十剧增到成千上万，这 种模式的弊端就凸显出来了，主要体现在如下几个方面：

*  fork 代价高 ：站在操作系统的角度，创建一个进程的代价是很高的，需要分配很多内 核资源，需要将内存映像从父进程复制到子进程。即使现在的操作系统在复制内存映像时用到 了 Copy on Write （写时复制）技术，总体来说创建进程的代价还是很大的
 *  父子进程通信复杂 ： 父进程“ fork ” 子进程时，文件描述符可以通过内存映像复制从 父进程传到子进程，但“ fork ” 完成后，父子进程通信就比较麻烦了，需要采用 IPC ( Interprocess Communication ）之类的进程通信方案 。例如 ， 子进程需要在 close 之前告诉父进程自己处理了 多少个请求以支撑父进程进行全局的统计，那么子进程和父进程必须采用 IPC 方案来传递信息
 *  进程数量增大后对操作系统压力较大：如果每个连接存活时间比较长 ，而且新的连接 又源源不断的进来 ，则进程数量会越来越多，操作系统进程调度和切换的频率也越来越高，系 统的压力也会越来越大。因此，一般情况下， PPC 方案能处理的并发连接数量最大也就几百

### prefork ###

针对 PPC 模式不同的缺点，产生了不同的解决方案 ，在 PPC 模式中，当连接进来时才“ fork ” 新进程来处理连接请求，由于“ fork ＂进程代价高，用户访问时可能感觉比较慢， prefork 模式的出现就是为了解决这个问题，prefork 就是提前创建进程（pre- fork） 系统在启动的时候就预先创建好进程， 然后才开始接受用户的请求，当有新的连接进来的时候，就可以省去“ fork ”进程的操作，让用户的访问更快、体验更好， prefork 的基本示意图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 1]

*  prefork 的 实现关键就是多个子进程都accept同一个 socket，当有新的连接进入时，操作系统保证只有一个进程能最后accept成功，但这里也存在一个问 题： “惊群”现象，就是指虽然只有一个子进程能accept成功，但所有阻塞在accept上的子进程都会被唤醒，这样就导致了不必要的进程调度和上下文切换，操作系统可以解决这个问题，在Linux2.6版本后内核己经解决了accept 惊群 问题
 *  prefork模式和PPC一样，还是存在父子进程通信复杂以及支持的并发连接数量有限的问题， 因此目前实际应用也不多
 *  Apache服务器提供了MPM prefork模式，推荐在需要可靠性或与旧软件兼容的站点时采用这种模式， 默认情况下最大支持 256个并发连接

### TPC ###

TPC是Thread per Connection的缩写 ，其含义是指每次有新的连接就新建一个线程去专门处理这个连接的请求。与进程相比，线程更轻量级，创建线程的消耗比进程要少得多；同时多线程是共享进程内存空间的， 线程通信相比进程通信更简单。 因此，TPC 实际上是解决或弱化了PPC的fork代价高的问题和父子进程通信复杂的问题

> TPC 的基本流程如下 ：
> 
>  *  父进程接受连接(图中accept)
>  *  父进程创建子线程(图中 pthread)
>  *  子线程处理连接的读写请求(图中子线程read 、业务处理、write)
>  *  子线程关闭连接(图中子线程中的close)

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 2]  
不难发现，和PPC相比，主进程不用close链接了，原因在于子线程是共享主进程的进程空间的，连接的文件描述符并没有被复制，因此只需要一次close即可

TPC 虽然解决了 fork 代价高和进程通信复杂 的问题，但是也引入了新的问题：

*  首先 ，创建线程虽然比创建进程代价低 ，但并不是没有代价，高并发时（例如每秒上万连接）还是有性能问题
 *  其次，无须进程间通信，但是线程间的互斥和共享又引入了复杂度，可能一不小心就导致了死锁问题
 *  最后，多线程会出现互相影响的情况，某个线程出现异常时，可能导致整个进程退出（例如内存越界）
 *  除了引入了新的问题，TPC 还是存在CPU线程调度和切换代价的问题。因此，TPC 方案本质上和 PPC 方案基本类似，在并发几百连接的场景下，反而更多的是采用 PPC的方案，因为 PPC 方案不会有死锁的风险，也不会多进程互相影响，稳定性更高

### prethread ###

*  在TPC模式中，当连接进来时才创建新的线程来处理连接请求，虽然创建线程比创建进程要更加轻量级，但还是有一定的代价，而prethread模式就是为了解决这个问题
 *  和prefork类似，prethread模式会预先创建线程，然后才开始接受用户的请求，当有新的连接进来的时候，就可以省去创建线程的操作，让用户感觉更快、体验更好
 *  由于多线程之间数据共享和通信比较方便，因此实际上prethread的实现方式相比prefork要灵活一些，常见的实现方式有下面几种：
    
     *  主进程 accept ， 然后将连接交给某个线程处理
     *  子线程都尝试去 accept ，最终只有一个钱程 accept 成功，方案的基本示意图如下  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 3]  
        Apache 服务器的MPM worker模式本质上就是一种prethread 方案，但稍微做了改进，Apache 服务器会创建多个进程，每个进程里面再创建多个线程，这样做主要是考虑稳定性，即使某个子进程里面的某个线程异常导致整个子进程退出，还会有其他子进程继续提供服务，不会导致整个服务器全部挂掉 。  
        prethread理论上可以比 prefork支持更多的并发连接，Apache服务器MPM worker模式默认支持 16 × 25 = 400 个并发处理线程

### Reactor ###

> PPC方案最主要的问题就是每个连接都要创建进程,连接结束后进程就销毁了，这样做其实是很大的浪费,为了解决这个问题，一个自然而然的想法就是资源复用，即不再单独为每个连接创建进程，而是创建一个进程池，将连接分配给进程，一个进程可以处理多个连接的业务

>  *  引入资源池的处理方式后，会引出 一个新的问题：进程如何才能高效地处理多个连接的业务？当一个连接一个进程时，进程可以采用“ read->业务处理-> write ”的处理流程，如果当前连接没有数据可以读，则进程就阻塞在read操作上,这种阻塞的方式在一个连接一个进程的场景下没有问题，但如果一个进程处理多个连接，进程阻塞在某个连接的read操作上，此时即使其他连接有数据可读，进程也无法去处理，很显然这样是无法做到高性能的
>  *  解决这个问题的最简单的方式是将read 操作改为非阻塞，然后进程不断地轮询多个连接。这种方式能够解决阻塞的问题，但解决的方式并不优雅。首先轮询是要消耗CPU的；其次如果一个进程处理几千上万的连接，则轮询的效率是很低的

为了能够更好地解决上述问题，一种自然而然的想法就是只有当连接上有数据的时候进程才去处理，这就是 I/O多路复用技术的来源,I/O多路复用这个术语在通信行业比较常见。例如，时分复用(GSM)、码分复用(CDMA)、 频分复用(GSM)等，其含义是“在一个信道上传输多路信号或数据流的过程和技术”，但如果拿这个含义套到计算机领域中就会导致混淆，因为单纯从表面含义来看，通信领域的“信道” 和计算机领域的“连接”是类似的，通信领域的“数据流”和计算机领域的“数据”是类似的。 如果直接照搬通信领域的多路复用定义到计算机领域，就会将多路复用理解为“一条连接上传输多种数据飞这与事实上的 I/O 多路复用含义相差太大。计算机网络领域的 I/O 多路复用，其中的“多路”，就是指多条连接，“复用”指的是多条连接复用同一个阻塞对象，这个阻塞对象和具体的实现有关。以 Linux 为例，如果使用select ，则这个公共的阻塞到象就是select用到的fd\_set ，如果使用 epoll ，就是 epoll\_create创建的文件描述符

I/O 多路复用技术归纳起来有如下两个关键实现点：

*  当多条连接共用一个阻塞对象后，进程只需要在一个阻塞对象上等待 ，而无须再轮询所有连接
 *  当某条连接有新的数据可以处理时，操作系统会通知进程，进程从阻塞状态返回，开始进行业务处理

I/O 多路复用结合线程池，完美地解决了 PPC 和 TPC 模型的问题，而且“大神们”给它取了一个很牛的名字：Reactor，中文是“反应堆”,实际上这里的“反应”是“ 事件反应” 的意思，可以通俗地理解为“来了一个事件我就有相应的反应”。 Reactor 模式也叫Dispatcher模式(很多开源的系统里面会看到这个名称的类，其实就是实现 Reactor模式的)，更加贴近模式本身的含义，即I/O多路复用统一监昕事件，收到事件后分配(Dispatch)给某个进程  
Reactor模式的核心组成部分包括Reactor和处理资源池(进程池或线程池)，其中Reactor负责监听和分配事件，处理资源池负责处理事件，初看Reactor的实现是比较简单的，但实际上结合不同的业务场景，Reactor 模式的具体实现方案灵活多变，主要体现在如下两点：

*  Reactor的数量可以变化 ： 可以是一个Reactor，也可以是多个Reactor
 *  资源池的数量可以变化：以进程为例，可以是单个进程，也可以是多个进程（线程类似）

将以上两个因素排列组合一下，理论上可以有4种选择，但由于“多 Reactor 单进程”实现方案相比“单Reactor单进程”方案， 既复杂又没有性能优势，因此“ 多 Reactor 单进程”方案 仅仅是一个理论上的方案 ， 实际没有应用，最终 Reactor 模式有如下三种典型的实现方案 ：

*  单 Reactor 单进程／单线程
 *  单 Reactor 多线程
 *  多 Reactor 多进程／线程。

以上方案具体选择进程还是线程， 更多的是和编程语言及平台相关。 例如， Java 语言一般使用线程（例如， Netty), C语言使用进程和线程都可以（例如， Nginx 使用进程 ， Memcache 使用线程） 。

#### 单Reactor单进程／线程 ####

单 Reactor 单进程／线程的方案示意图如下（以进程为例）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 4]  
select、accept、read、send是标准的网络编程API，dispatch和“业务处理”是徐娅哦完成的操作  
方案详细说明如下：

*  Reactor 对象通过 select 监控连接事件 ，收到事件后通过 dispatch 进行分发
 *  如果是连接建立的事件 ，则由 Acceptor 处理， Acceptor 通过 accept 接受连接，并创 建一个 Handler 来处理连接后续的各种事件
 *  如果不是连接建立事件 ，则 Reactor 会调用连接对应的 Handler （第 2 步中创建的 Handler )来进行响应
 *  Handler 会完成 read-＞业务处理-＞send的完整业务流程

单Reactor单进程的模式优点就是很简单，没有进程间通信，没有进程竞争，全部都在同一个进程内完成 。 但其缺点也是非常明显，具体表现如下:

*  只有一个进程 ，无法发挥多核CPU的性能；只能采取部署多个系统来利用多核CPU, 但这样会带来运维复杂度，本来只要维护一个系统，用这种方式需要在一台机器上维护多套系统
 *  Handler在处理某个连接上的业务时，整个进程无法处理其他连接的事件， 很容易导致性能瓶颈

因此，单 Reac tor 单进程的方案在实践中应用场景不多，只适用于业务处理非常快速的场景， 目前比较著名的开源软件中使用单 Reactor 单进程的是 Redis 。

> C语言编写系统的一般使用单Reactor单进程，因为没有必要在进程中再创建线程； 而Java语言编写的一般使用单Reactor单线程，因为Java虚拟机是一个进程，虚拟机中有很多线程，业务线程只是其中的一个线程而已

#### 单 Reactor 多线程 ####

为了避免单 Reactor 单进程／线程方案 的缺点，引入多进程／多线程是显而易见的，这就产生了第二个方案 ： 单Reactor多钱程  
单Reactor多线程方案示意图如下:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 5]  
方案详细说明如下：

*  主线程 中， Reactor 对象通过 select 监控连接事件 ，收到事件后通过 dispatch 进行分发
 *  如果是连接建立的事件，则由 Acceptor 处理， Acceptor 通过 accept 接受连接，并创 建一个 Handler 来处理连接后续的各种事件
 *  如果不是连接建立事件 ，则Reactor会调用连接对应的Handler （第 2 步中 创建的 Handler) 来进行响应
 *  Handler 只负责响应事件，不进行业务处理； Handler 通过read读取到数据后， 会发给 Processor 进行业务处理
 *  Processor 会在独立的子钱程中完成真正 的业务处理，然后将响应结果发给主进程的 Handler 处理； Handler收到响应后通过 send 将响应结果返回给client

单 Reactor 多线程方案能够充分利用 多核多 CPU 的处理能力，但同时也存在如下问题：

*  多线程数据共享和访问比较复杂 。 例如，子线程完成业务处理后，要把结果传递给主线程的Reactor进行发送，这里涉及共享数据的互斥和保护机制。 以 Java的NIO为例，Selector是线程安全的，但是通过Selector.selectKeys()返回的键的集合是非线程安全的，对selected keys的处理必须单线程处理或采取同步措施进行保护
 *  Reactor 承担所有事件的监昕和响应，只在主线程中运行，瞬间高并发时会成为性能瓶颈

> 这里说了“单 Reactor 多线程” 方案，而没说“单 Reactor多进程 ” 方案,主要原因在于如果采用多进程，子进程完成业 务处理后，将结果返回给父进程，并通知父进程发送给哪个client ， 则是很麻烦的事情, 因为父进程只是通过Reactor监听各个连接上的事件然后进行分配，子进程与父进程通信时并不是一个连接。如果要将父进程和子进程之间的通信模拟为一个连接，并加入Reactor进行监听，则是比较复杂的 。而采用多线程时，因为多线程是共享数据的，因此线程间通信是非常方便的,虽然要额外考虑线程间共享数据时的同步问题，但这个复杂度比上述进程间通信的复杂度要低很多

#### 多 Reactor 多进程／线程 ####

为了解决单 Reactor 多线程的问题，最直观的方法就是将单 Reactor 改为多 Reactor ，这就产生了第三个方案 ： 多 Reactor 多进程／线程。  
多 Reactor 多进程／线程方案示意图如下(以进程为例)  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 6]  
方案详细说明如下：

*  父进程中 mainReactor 对象通过 select 监控连接建立事件 ，收到事件后通过Acceptor接收，将新的连接分配给某个子进程
 *  子进程的subReactor将mainReactor分配的连接加入连接队列进行监听，并创建一个Handler 用于处理连接的各种事件
 *  当有新的事件发生时， subReactor会调用连接对应的 Handler （即第 2 步 中创建的 Handler)来进行响应
 *  Handler 完成 read ->业务处理->send 的完整业务流程

多Reactor多进程／线程的方案看起来比单Reactor多线程要复杂，但实际实现时反而更加简 单，主要原因如下:

*  父进程和子进程的职责非常明确，父进程只负责接收新连接，子进程负责完成后续的业务处理
 *  父进程和子进程的交互很简单，父进程只需要把新连接传给子进程，子进程无须返回数据
 *  子进程之间是互相独立 的，无须同步共享之类 的处理(这里仅限于网络模型相关的select 、read、send等无须同步共享，“业务处理”还是有可能需要同步共享的）

目前采用多Reactor多进程实现的著名的开源系统是Nginx,采用多Reactor多线程实现有Memcache和Netty

> Nginx 采用的是多Reactor多进程的模式，但方案与标准的多Reactor多进程有差异 。具体差异表现为主进程中仅仅创建了监听端口，并没有创建mainReactor来“ accept ”连接,而是由子进程的Reactor来“ accept ”连接，通过锁来控制一次只有一个子进程进行“accept ”,子进程“accept ”新连接后就放到自己的Reactor进行处理，不会再分配给其他子进程

### Proactor ###

> Reactor是非阻塞同步网络模型 ，因为真正的read和send操作都需要用户进程同步操作。这里的“同步”指用户进程在执行read和send这类I/O操作的时候是同步的，如果把 I/O 操作改为异步就能够进一步提升性能 ， 这就是异步网络模型 Proactor

> Proactor中文翻译为“前摄器”比较难理解，与其类似的单词是proactive， 含义为“主动的”，因此我们照猫画虎翻译为“主动器”反而更好理解。 Reactor可以理解为“来了事件我通知你， 你来处理”，而 Proactor可以理解为“来了事件我来处理，处理完了我通知你”。这里的“我” 就是操作系统内核，“ 事件”就是有新连接、有数据可读 、有数据可写这些I/O事件

Proactor模型示意图:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 7]

> 方案详细说明如下：
> 
>  *  Proactor Initiator 负责创建Proactor和Handler，并将Proactor和Handler都通过Asynchronous Operation Processor 注册到内核
>  *  Asynchronous Operation Processor负责处理注册请求，并完成I/O操作
>  *  Asynchronous Operation Processor完成I/O操作后通知Proactor
>  *  Proactor根据不同的事件类型回调不同的 Handler 进行业务处理
>  *  Handler完成业务处理， Handler也可以注册新的Handler到内核进程

理论上Proactor比Reactor效率要高一些 ， 异步 I /O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠。 但实现真正的异步I/O ，操作系统需要做大量的工作，目前Windows下通过 IOCP实现了真正的异步I/O ，而在Linux系统下的AIO并不完善，因此在Linux 下实现高并发网络编程时都是以Reactor模式为主。所以即使boost asio号称实现了proactor模型，其实它在 Windows 下采用IOCP，而在 Linux 下是用Reactor模式(采用epoll)模拟出来的异步模型

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/ec7d5f0b363040588285d032646d38dc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/a43a811124f74aebb33c79f064d64d44.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/529ab6d993604077a8904bd1c21808f4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/6dcb2f92276a4fa689ff510dff76c635.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/7e13b8c958fa41f08771c70f8a857fb0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/8b73ac828254497dbe32a88c13091f6f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/b944042c3d364247baab9f96b210df39.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhd2VpX3lhbmcwMDAwMDA_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221123/1cba3f41f5104db4bb49ed0fdebfdeb2.png