04 单服务器高性能

磁盘、操作系统、CPU、内存、缓存、网络、编程语言、架构等，每个都有可能影响系统达到高性能。

  • 一行不恰当的 debug 日志，就可能将服务器的性能从 TPS 30000 降低到 8000
  • 一个 tcp_nodelay 参数，就可能将响应时间从 2 毫秒延长到 40 毫秒

高性能架构设计主要集中在两方面：

  • 将单服务器的性能发挥到极致
  • 单服务器无法支撑性能，则设计服务器集群方案

除了以上两点，最终系统能否实现高性能，还和具体的实现及编码相关。

  • 架构设计决定了系统性能的上限
  • 实现细节决定了系统性能的下限

单服务器高性能的关键之一就是服务器采取的并发模型，并发模型有如下两个关键设计点：

  • 服务器如何管理连接。
  • 服务器如何处理请求。

以上两个设计点最终都和操作系统的 I/O 模型及进程模型相关。

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

0.1. PPC（Process Per Connection）

PPC的含义是指每次有新的连接就新建一个进程去专门处理这个连接的请求，这是传统的 UNIX 网络服务器所采用的模型。基本流程如下所示：

image

  1. 父进程接受连接（accept）
  2. 父进程fork子进程
  3. 子进程处理连接的读写请求（read、业务处理、write）
  4. 子进程关闭连接（close）

注意，图中父进程fork子进程后，直接调用了close，只是将连接的文件描述符引用计数减1（因为子进程复制了文件描述符），真正的关闭连接是等子进程也调用close后，连接对应的文件描述符引用计数变为0后，操作系统才会真正关闭连接。

PPC 模式实现简单，比较适合服务器的连接数没那么多的情况，例如数据库服务器。

互联网兴起后，服务器的并发和访问量剧增成千上万，PPC的弊端就凸显出来了：

  • fork代价高：操作系统创建一个进程的代价是很高的，需要分配很多内核资源，需要将内存映像从父进程复制到子进程。（即使现在的操作系统在复制内存映像时用到了 Copy on Write（写时复制）技术，总体来说创建进程的代价还是很大的）。
  • 父子进程通信复杂：父进程“fork”子进程时，文件描述符可以通过内存映像复制从父进程传到子进程，但“fork”完成后，父子进程通信就需要采用 IPC（Interprocess Communication）之类的进程通信方案。
  • 支持的并发连接数量有限：如果每个连接存活时间比较长，而且新的连接又源源不断的进来，则进程数量会越来越多，操作系统进程调度和切换的频率也越来越高，系统的压力也会越来越大。

在架构设计时，PPC方案能处理的并发连接数量最大也就几百。

0.1.1. Prefork

PPC 模式中，当连接进来时才 fork 新进程来处理连接请求，由于 fork 进程代价高，用户访问时可能感觉比较慢，prefork 模式的出现就是为了解决这个问题。

系统在启动时预先创建好进程，然后开始接受用户的请求，当有新的连接进来时，可以省去 fork 进程的操作，让用户访问更快、体验更好。prefork 的基本示意图是：

image

prefork 的实现关键就是多个子进程都 accept 同一个 socket，当有新的连接进入时，操作系统保证只有一个进程能最后 accept 成功。

注意：一个小问题“惊群”现象，虽然只有一个子进程能 accept 成功，但所有阻塞在 accept 上的子进程都会被唤醒，这样就导致了不必要的进程调度和上下文切换了。幸运的是，操作系统可以解决这个问题，例如 Linux 2.6 版本后内核已经解决了 accept 惊群问题。

prefork 模式和 PPC 一样，还是存在：

  • 父子进程通信复杂
  • 支持的并发连接数量有限的问题

因此目前实际应用也不多。

Apache 服务器提供了 MPM prefork 模式，推荐在需要可靠性或者与旧软件兼容的站点时采用这种模式，默认情况下最大支持 256 个并发连接。

0.2. TPC（Thread Per Connection）

TPC的含义是指每次有新的连接就新建一个线程去专门处理这个连接的请求。

与进程相比，线程更轻量级，创建线程的消耗比进程要少得多；同时多线程是共享进程内存空间的，线程通信相比进程通信更简单。因此，TPC 实际上是解决或者弱化了 PPC fork 代价高的问题和父子进程通信复杂的问题。

TPC 的基本流程是：

image

  1. 父进程接受连接（accept）
  2. 父进程创建子线程（pthread）
  3. 子线程处理连接的读写请求（read、业务处理、write）
  4. 子线程关闭连接（close）

注意：和 PPC 相比，主进程不用“close”连接了。原因是在于子线程是共享主进程的进程空间的，连接的文件描述符并没有被复制，因此只需要一次 close 即可。

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

  • 创建线程依然有代价，高并发时（每秒上万连接）还是有性能问题
  • 无须进程间通信，但是线程间的互斥和共享又引入了复杂度，可能一不小心就导致了死锁问题
  • 多线程会出现互相影响的情况，某个线程出现异常时，可能导致整个进程退出（例如内存越界）

除了上述问题，TPC 还存在 CPU 线程调度和切换代价的问题。

因此，TPC 方案本质上和 PPC 方案基本类似，在并发几百连接的场景下，反而更多地是采用 PPC 的方案，因为 PPC 方案不会有死锁的风险，也不会多进程互相影响，稳定性更高。

0.2.1. prethread

TPC 模式中，当连接进来时才创建新的线程来处理连接请求，虽然创建线程更加轻量级，但还是有一定的代价，prethread 模式就是为了解决这个问题。

prethread 模式预先创建线程，然后开始接受用户请求，当有新的连接进来时，省去创建线程的操作，让用户感觉更快、体验更好。

由于多线程之间数据共享和通信比较方便，因此实际上 prethread 的实现方式相比 prefork 要灵活一些，常见的实现方式有下面几种：

  • 主进程 accept，然后将连接交给某个线程处理
  • 子线程都尝试 accept，最终只有一个线程 accept 成功，方案的基本示意图如下

image

Apache 服务器会首先创建多个进程，每个进程里面再创建多个线程，这样做主要考虑稳定性，即使某个子进程里面的某个线程异常导致整个子进程退出，还会有其他子进程继续提供服务，不会导致整个服务器全部挂掉。prethread 理论上可以比 prefork 支持更多的并发连接，Apache 服务器 MPM worker 模式默认支持 16×25=400 个并发处理线程。

0.3. 并发模式的选择

不同并发模式的选择，还要考察三个指标：

  • 响应时间（RT）
  • 并发数（Concurrency）
  • 吞吐量（TPS）

三者关系，吞吐量=并发数/平均响应时间。

不同类型的系统，对这三个指标的要求不一样。

  • 三高系统，比如秒杀、即时通信，不能使用并发模式
  • 三低系统，比如ToB系统，运营类、管理类系统，一般可以使用并发模式
  • 高吞吐系统：
    • 如果是内存计算为主的，一般可以使用并发模式
    • 如果是网络I/O为主的，一般不能使用并发模式

高并发需要根据两个条件划分：连接数量，请求数量。

  1. 海量连接海量请求：例如抢购，双十一等（成千上万连接）
  2. 常量连接海量请求：例如中间件（几十上百连接）
  3. 海量连接常量请求：例如门户网站
  4. 常量连接常量请求：例如内部运营系统，管理系统

因此，常量连接海量请求和常量连接常量请求比较适合使用并发模式，因为PPC和TPC能够支持的最大连接数差不多是几百个。

单服务器高性能的 PPC 和 TPC 模式的优点是实现简单，缺点是无法支撑高并发的场景，尤其是互联网发展到现在，各种海量用户业务的出现，PPC 和 TPC 完全无能为力。

应对高并发场景的单服务器高性能架构模式：Reactor 和 Proactor。

0.4. Reactor

PPC/TPC 模式最主要的问题就是每个连接都要创建进程/线程，连接结束后进程/线程就销毁了，这样做其实是很大的浪费。

为了解决这个问题，自然就想到资源复用，不再单独为每个连接创建进程，而是创建一个进程池，将连接分配给进程，一个进程可以处理多个连接的业务。

引入资源池的处理方式后，会引出一个新的问题：进程如何才能高效地处理多个连接的业务？

当一个连接一个进程时，进程可以采用“read -> 业务处理 -> write”的处理流程，如果当前连接没有数据可以读，则进程就阻塞在 read 操作上。

这种阻塞的方式在一个连接一个进程的场景下没有问题，但如果一个进程处理多个连接，进程阻塞在某个连接的 read 操作上，此时即使其他连接有数据可读，进程也无法去处理，很显然这样是无法做到高性能的。

解决这个问题：

  1. 最简单的方式是将 read 操作改为非阻塞，然后进程不断地轮询多个连接。这种方式能够解决阻塞的问题，但解决的方式并不优雅。

    • 首先，轮询是要消耗 CPU 的；
    • 其次，如果一个进程处理几千上万的连接，则轮询的效率是很低的。

  2. 只有当连接上有数据的时候进程才去处理，这就是 I/O 多路复用技术的来源。I/O 多路复用技术归纳起来有两个关键实现点：

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

I/O 多路复用结合线程池，完美地解决了 PPC 和 TPC 的问题，称为Reactor，中文是“反应堆”。来了一个事件Reactor就根据事件类型来调用相应的代码进行处理。也叫Dispatcher，即 I/O 多路复用统一监听事件，收到事件后分配（Dispatch）给某个进程。

Reactor 模式的核心组成部分包括 Reactor 和处理资源池（进程池或线程池）：

  • 其中 Reactor 负责监听和分配事件
  • 处理资源池负责处理事件

初看 Reactor 的实现是比较简单的，但实际上结合不同的业务场景，Reactor 模式的具体实现方案灵活多变，主要体现在：

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

因此，Reactor 模式有这三种典型的实现方案：

  1. 单 Reactor 单进程/线程
  2. 单 Reactor 多线程
  3. 多 Reactor 多进程/线程

以上方案具体选择进程还是线程，更多地是和编程语言及平台相关。

  • Java 语言一般使用线程（例如，Netty）
  • C 语言使用进程和线程都可以
    • Nginx（C语言实现） 使用进程
    • Memcache（C语言实现） 使用线程

0.4.1. 单 Reactor 单进程/线程

以进程为例：

image

注意，select、accept、read、send 是标准的网络编程 API，dispatch 和“业务处理”是需要完成的操作，其他方案示意图类似。

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

单 Reactor 单进程的模式优点：

  • 简单，
  • 没有进程间通信，没有进程竞争，全部都在同一个进程内完成。

缺点：

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

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

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

0.4.2. 单 Reactor 多线程

为了克服单 Reactor 单进程/线程方案的缺点，引入多进程/多线程是显而易见的。

image

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

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

  • 多线程数据共享和访问比较复杂。例如，子线程完成业务处理后，要把结果传递给主线程的 Reactor 进行发送，这里涉及共享数据的互斥和保护机制。
  • Reactor 承担所有事件的监听和响应，只在主线程中运行，瞬间高并发时会成为性能瓶颈。

如果采用多进程，子进程完成业务处理后，将结果返回给父进程，并通知父进程发送给哪个 client，这是很麻烦的事情。因为父进程只是通过 Reactor 监听各个连接上的事件然后进行分配，子进程与父进程通信时并不是一个连接。如果要将父进程和子进程之间的通信模拟为一个连接，并加入 Reactor 进行监听，则是比较复杂的。

采用多线程时，因为多线程是共享数据的，因此线程间通信是非常方便的。虽然要额外考虑线程间共享数据时的同步问题，但这个复杂度比进程间通信的复杂度要低很多。

0.4.3. 多 Reactor 多进程/线程

为了解决单 Reactor 多线程的问题，最直观的方法就是将单 Reactor 改为多 Reactor。

以进程为例：

image

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

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

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

Nginx 采用的是多 Reactor 多进程的模式，与标准的多 Reactor 多进程有差异，表现为主进程中仅仅创建了监听端口，并没有创建 mainReactor 来“accept”连接，而是由子进程的 Reactor 来“accept”连接，通过锁来控制一次只有一个子进程进行“accept”，子进程“accept”新连接后就放到自己的 Reactor 进行处理，不会再分配给其他子进程，更多细节请查阅相关资料或阅读 Nginx 源码。

0.5. Proactor

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

  • Reactor 可以理解为“来了事件操作系内核通知业务程序来处理”，
  • Proactor 可以理解为“来了事件操作系统内核来处理，处理完了操作系统内核通知业务程序”。

这里的“事件”就是有新连接、有数据可读、有数据可写的这些 I/O 事件。

image

  1. Proactor Initiator 负责创建 Proactor 和 Handler，并将 Proactor 和 Handler 都通过 Asynchronous Operation Processor 注册到内核。
  2. Asynchronous Operation Processor 负责处理注册请求，并完成 I/O 操作。
  3. Asynchronous Operation Processor 完成 I/O 操作后通知 Proactor。Proactor 根据不同的事件类型回调不同的 Handler 进行业务处理。
  4. 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）模拟出来的异步模型。

上次修改: 2 June 2020