单服务器高性能：PPC、TPC、epoll、Reactor、Proactor

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

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

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

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

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

PPC

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

说明：父进程接受连接（图中 accept），父进程“fork”子进程（图中 fork），子进程处理连接的读写请求（图中子进程 read、业务处理、write），子进程关闭连接（图中子进程中的 close）。
注意：父进程“fork”子进程后，直接调用了 close，看起来好像是关闭了连接，其实只是将连接的文件描述符引用计数减一，真正的关闭连接是等子进程也调用 close 后，连接对应的文件描述符引用计数变为 0 后，操作系统才会真正关闭连接。

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

fork代价高，需要分配很多内核资源，需要将内存映像从父进程复制到子进程；
父子进程通信复杂，需要采用 IPC（Interprocess Communication）之类的进程通信方案。
支持并发连接数量有限，如果每个连接存活时间比较长，而且新的连接又源源不断的进来，则进程数量会越来越多，操作系统进程调度和切换的频率也越来越高，系统的压力也会越来越大。因此，一般情况下，PPC 方案能处理的并发连接数量最大也就几百。

prefork

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

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

惊群：指虽然只有一个子进程能 accept 成功，但所有阻塞在 accept 上的子进程都会被唤醒，这样就导致了不必要的进程调度和上下文切换(Linux 2.6 版本后内核已经解决了 accept 惊群问题)

prefork 模式和 PPC 一样，还是存在父子进程通信复杂、支持的并发连接数量有限的问题，因此目前实际应用也不多。

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

TPC

TPC 是 Thread Per Connection 的缩写，其含义是指每次有新的连接就新建一个线程去专门处理这个连接的请求。

与进程相比，线程更轻量级，创建线程的消耗比进程要少得多；同时多线程是共享进程内存空间的，线程通信相比进程通信更简单。

TPC 实际上是解决或者弱化了 PPC fork 代价高的问题和父子进程通信复杂的问题。

TPC 的基本流程是：

说明：父进程接受连接（图中 accept），父进程创建子线程（图中 pthread），子线程处理连接的读写请求（图中子线程 read、业务处理、write），子线程关闭连接（图中子线程中的 close）。
注意：和 PPC 相比，主进程不用close连接了。原因是在于子线程是共享主进程的进程空间的，连接的文件描述符并没有被复制，因此只需要一次 close 即可。

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

创建线程虽然比创建进程代价低，但并不是没有代价，高并发时还是有性能问题；
无需进程间通信，但是线程间的互斥和共享又引入了新的复杂度，可能一不小心就导致了死锁问题；
多线程会出现互相影响的问题，某个线程出现异常时，可能导致整个进程退出；

除了引入了新的问题，TPC 还是存在 CPU 线程调度和切换代价的问题。

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

prethread

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

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

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

Apache 服务器的 MPM worker 模式本质上就是一种 prethread 方案，但稍微做了改进。Apache 服务器会首先创建多个进程，每个进程里面再创建多个线程，这样做主要是为了考虑稳定性，即：即使某个子进程里面的某个线程异常导致整个子进程退出，还会有其他子进程继续提供服务，不会导致整个服务器全部挂掉。

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

海量连接（成千上万）海量请求：例如抢购，双十一等

常量连接（几十上百）海量请求：例如中间件

海量连接常量请求：例如门户网站

常量连接常量请求：例如内部运营系统，管理系统

PPC和TPC对那些吞吐量比较大，长连接且连接数不多的系统应该比较适用。

bio：阻塞io，PPC和TPC属于这种
nio：多路复用io，reactor基于这种技术
aio：异步io，Proactor基于这种技术

I/O多路复用

上述模式中，一个连接需要一个进程或线程，连接结束后进程(线程)就销毁了，然后新连接来了继续创建资源(进程或线程)与之关联，创建销毁在频繁短连接这类场景中是很大的浪费，可以将资源(进程或线程)与连接两者"分离"，即不再单独为每个连接创建资源，而是创建一个资源池，将连接分配给池中的一个资源，连接对资源(进程或线程)而言只是生命中的一个过客。
这时候可能会堵车，如资源调用连接的read(),连接半天就是过不来(网路故障)又或着连接发送方出了点事情耽搁一下，资源(进程或线程)需要死等吗？
如这次的疫情，地铁口需要检查健康码通行，一位旅客手机卡住或者还未注册，这时候铁警会让这位旅客靠边操作，下一位旅客上来。
回到正文：编码解决这个问题的最简单的方式是将 read 操作改为非阻塞，然后资源不断地轮询多个连接，谁可读谁先来。但并不是最好的：首先，轮询是要消耗 CPU 的；其次，如果一个进程处理几千上万的连接，则轮询的效率是很低的。如此引入I/O多路复用技术：

I/O多路复用就是通过一种机制，一个进程/线程可以监视多个连接，一旦某个连接就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。
IO复用就是同时等待多个文件描述符就绪，以系统调用的形式提供。如果所有文件描述符都没有就绪的话，该系统调用阻塞，否则调用返回，允许用户进行后续的操作。

当多条连接共用一个阻塞对象后，进程只需要在一个阻塞对象上等待，而无须再轮询所有连接，常见的实现方式有 select、epoll、kqueue 等。

select，epoll本质上是同步I/O，需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间

当某条连接有新的数据可以处理时，操作系统会通知进程(或线程)，进程(或线程)从阻塞状态返回，开始进行业务处理。

select、epoll

epoll是Linux下的一种IO多路复用技术，可以非常高效的处理数以百万计的socket句柄。

在 select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描；

select/poll是收到通知后轮询socket列表看看哪个socket可以读，普通的socket轮询是指重复调用read操作

epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait() 时便得到通知(相比select去掉了遍历文件描述符，而是通过监听回调的的机制)

两者区别：

select的句柄数目受限，在linux/posix_types.h头文件有这样的声明：#define __FD_SETSIZE 1024 ，表示select最多同时监听1024个fd，而epoll没有，它的限制是最大的打开文件句柄数目。
epoll的最大好处是不会随着FD的数目增长而降低效率，在selec中采用轮询处理，其中的数据结构类似一个数组的数据结构，而epoll是维护一个队列，直接看队列是不是空就可以了。epoll只会对"活跃"的socket进行操作(在内核实现中epoll是根据每个fd上面的callback函数实现的)，只有"活跃"的socket才会主动的去调用 callback函数（把这个句柄加入队列），其他idle状态句柄则不会。

如果没有大量的idle -connection或者dead-connection，epoll的效率并不会比select/poll高很多

使用mmap加速内核与用户空间的消息传递。无论是select/poll还是epoll都需要内核把fd消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核与用户空间mmap同一块内存实现的。

epoll内部实现

c封装的3个epoll系统调用:

int epoll_create(int size)
创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/pid/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
epoll的事件注册函数，第一个参数是epoll_create()的返回值，第二个参数表示动作，用三个宏来表示：
EPOLL_CTL_ADD：注册新的fd到epfd中；
EPOLL_CTL_MOD：修改已经注册的fd的监听事件；
EPOLL_CTL_DEL：从epfd中删除一个fd；
第三个参数是需要监听的fd，第四个参数是告诉内核需要监听什么事件。
int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout)
等待事件的产生，所监控的句柄中有事件发生时，就返回用户态的进程。参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大，这个maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1永久阻塞）。

epoll内部实现(对应上述三个系统调用)：

epoll初始化时，会向内核注册一个文件系统，用于存储被监控的句柄文件，调用epoll_create时，会在这个文件系统中创建一个file节点。同时epoll会开辟自己的内核高速缓存区，以红黑树的结构保存句柄，以支持快速的查找、插入、删除。还会再建立一个list链表，用于存储准备就绪的事件。
当执行epoll_ctl时，除了把socket句柄放到epoll文件系统里file对象对应的红黑树上之外，还会给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。所以，当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后，就把socket插入到就绪链表里。
当epoll_wait调用时，仅仅观察就绪链表里有没有数据，如果有数据就返回，否则就sleep，超时时立刻返回。

epoll的两种工作模式

LT：level-trigger，水平触发模式，是缺省的工作方式，并且同时支持block和no-block socket。在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表(JDK的NIO)。
ET：edge-trigger，边缘触发模式，是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了，但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)，如Netty的epoll。

图片来自：https://www.jianshu.com/p/2b71ea919d49

Reactor

I/O 多路复用结合线程池，完美地解决了 PPC 和 TPC 的问题，而且“大神们”给它取了一个很牛的名字：Reactor。Reactor 模式也叫 Dispatcher 模式（在很多开源的系统里面会看到这个名称的类，其实就是实现 Reactor 模式的），更加贴近模式本身的含义，即 I/O 多路复用统一监听事件，收到事件后分配（Dispatch）给某个进程。

Reactor 模式的核心组成部分包括 Reactor 和处理资源池（进程池或线程池），其中 Reactor 负责监听和分配事件，处理资源池负责处理事件。

结合不同业务场景，模式具体实现方案可以灵活多变，如：

单 Reactor 单进程(线程);
单 Reactor 多进程(线程);
多 Reactor 多进程(线程);
多Reactor 单进程/线程(无意义)；

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

单Reactor单进程(线程)

select、accept、read、send 是标准的网络编程 API，dispatch 和业务处理是需要完成的操作

过程说明：

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

优点：模式很简单，没有进程间通信，没有进程竞争；
缺点：只有一个进程，无法发挥多核 CPU 的性能；Handler 在处理某个连接上的业务时，整个进程无法处理其他连接的事件，很容易导致性能瓶颈。

适用场景：只适用于业务处理非常快速的场景，目前比较著名的开源软件中使用单 Reactor 单进程的是 Redis。

单Reactor多线程

过程说明：

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

虽然克服了克服单 Reactor 单进程 / 线程方案的缺点，能够充分利用多核多 CPU 的处理能力，但同时也存在下面的问题：

多线程数据共享和访问比较复杂，涉及共享数据的互斥和保护机制；
Reactor 承担所有事件的监听和响应，只在主线程中运行，瞬间高并发时会成为性能瓶颈；

单 Reactor 多进程方案：

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

多 Reactor 多进程 / 线程

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

过程说明：

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

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

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

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

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

Proactor

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

过程说明：

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，操作系统需要做大量的工作。

DMA:Direct Memory Access(直接存储器访问) 是所有现代电脑的重要特色，它允许不同速度的硬件装置来沟通，而不需要依赖于 CPU 的大量中断负载;
目前 Windows 下通过 IOCP 实现了真正的异步 I/O，而在 Linux 系统下的 AIO 并不完善

--------来源《极客课程》∙ 学习摘要