高性能服务器模型总结

原 作者 郑天 | 发表于 | 分类于 2020级

前言

最近在看nginx源码,在看到epoll模块时,遗忘了一些知识点,刚好在这周六还有一场小知识分享,所以在这里总结一下高性能并发模型

常见的几种高性能模型

Reactor(反应堆)

就经典的Reactor模型就有以下三个:

单Reactor单线程模型

在这里插入图片描述

模型角色

  • Reactor：负责监听和分配事件，将I/O事件分派给对应的Handler。新的事件包含连接建立就绪、读就绪、写就绪等
  • Acceptor：处理客户端新连接，并分派请求到处理器链中
  • Handler：将自身与事件绑定，执行非阻塞读/写任务，完成channel的读入，完成处理业务逻辑后，负责将结果写出channel。可用资源池来管理

处理流程

  • Reactor对象通过复用器(epoll,poll,select)监控连接事件，收到事件后通过dispatch进行转发。

  • 如果是连接建立的事件，则由acceptor接受连接，并创建handler处理后续事件。

  • 如果不是建立连接事件，则Reactor会分发调用Handler来响应。

  • handler会完成read->业务处理->send的完整业务流程

特点

  • 单 Reactor 单进程的方案不适用大量并发的场景，只适用于业务处理非常快速的场景,例如redis

缺点

  • 整体操作还是单线程，不能充分利用硬件资源

  • 对于一些小容量应用场景，可以使用单Reactor单线程模型。但是对于高负载、大并发的应用场景却不合适

  • 即便Reactor线程的CPU负荷达到100%，也无法满足海量消息的编码、解码、读取和发送。

  • 当Reactor线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重Reactor线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈。

  • 一旦Reactor线程意外中断或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。

单Reactor多线程模型

在这里插入图片描述

执行过程

  • Reactor 对象通过 select （IO 多路复用接口） 监听事件，收到事件后通过 dispatch 进行分发，具体分发给 Acceptor 对象还是 Handler 对象，还要看收到的事件类型；

  • 如果是连接建立的事件，则交由 Acceptor 对象进行处理，Acceptor 对象会通过 accept 方法 获取连接，并创建一个 Handler 对象来处理后续的响应事件；

  • 如果不是连接建立事件， 则交由当前连接对应的 Handler 对象来进行响应；

  • 上面的三个步骤和单 Reactor 单线程方案是一样的，接下来的步骤就开始不一样了：

  • Handler 对象不再负责业务处理，只负责数据的接收和发送，Handler 对象通过 read 读取到数据后，会将数据发给子线程里的 Processor 对象进行业务处理；

  • 子线程里的 Processor 对象就进行业务处理，处理完后，将结果发给主线程中的 Handler 对象，接着由 Handler 通过 send 方法将响应结果发送给 client

特点

  • 其优势于之前的单Reactor单线程模型在于能够充分利用 CPU 的资源

缺点

  • 对资源共享和访问比较复杂
  • 因为一个 Reactor 对象承担所有事件的监听和响应，而且只在主线程中运行，在面对瞬间高并发的场景时，容易成为性能的瓶颈的地方

多reactor多线程模型

在这里插入图片描述

执行流程

  • 主线程中的 MainReactor 对象通过 select 监控连接建立事件，收到事件后通过 Acceptor 对象中的 accept 获取连接，将新的连接分配给某个子线程；

  • 子线程中的 SubReactor 对象将 MainReactor 对象分配的连接加入 select 继续进行监听，并创建一个 Handler 用于处理连接的响应事件。

  • 如果有新的事件发生时，SubReactor 对象会调用当前连接对应的 Handler 对象来进行响应。

  • Handler 对象通过 read -> 业务处理 -> send 的流程来完成完整的业务流程

特点

  • 主线程和子线程分工明确，主线程只负责接收新连接，子线程负责完成后续的业务处理。

  • 主线程和子线程的交互很简单，主线程只需要把新连接传给子线程，子线程无须返回数据，直接就可以在子线程将处理结果发送给客户端

应用场景:Netty,Memcache,Nginx

Proactor

在这里插入图片描述

执行流程

  • Proactor Initiator 负责创建 Proactor 和 Handler 对象，并将 Proactor 和 Handler 都通过

  • Asynchronous Operation Processor 注册到内核；

  • Asynchronous Operation Processor 负责处理注册请求，并处理 I/O 操作；

  • Asynchronous Operation Processor 完成 I/O 操作后通知 Proactor；

  • Proactor 根据不同的事件类型回调不同的 Handler 进行业务处理；

  • Handler 完成业务处理；

特点

  • 在内核中异步完成时间的读写,在用户态只提供事件完成状态响应,用户只需要进行业务处理即可
  • 很明显，异步 I/O 比同步 I/O 性能更好，因为异步 I/O 在「内核数据准备好」和「数据从内核空间拷贝到用户空间」这两个过程都不用等待。

缺陷

  • Linux 下的异步 I/O 是不完善的，aio 系列函数是由 POSIX 定义的异步操作接口，不是真正的操作系统级别支持的，而是在用户空间模拟出来的异步，并且仅仅支持基于本地文件的 aio 异步操作，网络编程中的 socket 是不支持的，这也使得基于 Linux 的高性能网络程序都是使用 Reactor 方案。但是linux内核在后来增加了io_uring,完善了之前网络异步模型,将原来很难用的AIO替换掉;还有很火的ACE框架里面也支持proactor模型

reactor与proactor对比

  • Reactor 是非阻塞同步网络模式，感知的是就绪可读写事件。在每次感知到有事件发生（比如可读就绪事件）后，就需要应用进程主动调用 read 方法来完成数据的读取，也就是要应用进程主动将 socket 接收缓存中的数据读到应用进程内存中，这个过程是同步的，读取完数据后应用进程才能处理数据

-Proactor 是异步网络模式， 感知的是已完成的读写事件。在发起异步读写请求时，需要传入数据缓冲区的地址（用来存放结果数据）等信息，这样系统内核才可以自动帮我们把数据的读写工作完成，这里的读写工作全程由操作系统来做，并不需要像 Reactor 那样还需要应用进程主动发起 read/write 来读写数据，操作系统完成读写工作后，就会通知应用进程直接处理数据

  • 无论是 Reactor，还是 Proactor，都是一种基于事件分发的网络编程模式，区别在于 Reactor 模式是基于待完成的 I/O 事件，而 Proactor 模式则是基于已完成的 I/O 事件

半同步/半异步模型

高效半同步/半异步模式

在这里插入图片描述

特点

  • 每个线程的工作都是异步模式
  • 主线程只需要监听套接字,如果有套接字新链接响应,主线程通过管道向工作线程中分发响应套接字,每个工作线程都会将分发下来的socket套接字添加到自己的epoll中,然后所有响应都会在该子工作线程中进行,这样做的好处就是主线程上的负载会减少,从而达到支持高并发,通过空间来换取时间.

半同步/半Reactor模型

在这里插入图片描述

特点

主线程来监听socket套接字,当有socket响应时主线程将读或写就绪的socket插入请求队列中,然后每个工作线程来获取到以链接的套接字在其内部进行读写操作以及业务逻辑处理,其余时间这些线程会睡眠在请求队列上,当有任务到来时他们会通过竞争锁来获取处理任务的权利

然而这种模型也可以通过模拟proactor,让读写操作都在主线程中完成,将读取的结果封装为一个任务请求插入请求队列中

缺点

  • 我们在进行添加任务和取任务的过程中都会进行加锁解锁的操作,最终会导致浪费cpu的时间
  • 每个线程只可处理一个客户请求,如果客户端比较多,例如百万并发则会导致请求队列上的任务堆积,从而客户端响应很慢,增加线程的话工作线程的切换也会浪费大量的cpu时间

领导者追随者模型

领导者/追随者模式是：多个工作线程轮流获得事件源集合，轮流监听、分发并处理事件的一种模式。
在这里插入图片描述

句柄集

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

事件处理器

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

线程集以及线程状态

线程集是所有工作线程(包括领导者和追随者)的管理者。它负责各线程之间的同步，以及新领导者线程的推选

  • Leader：领导者身份，等待句柄集上的I/O事件。当检测到新的I/O事件，可以推选新的领导者，本线程转Processing处理事件，也可能指定其他追溯者来处理事件；
  • Processing：正在处理事件；
  • Follower：追随者身份，等待成为新的领导者，也可能被当前领导者指定来处理新的任务

执行过程

  • 在线程池中会推举一个领导者来等待IO请求,其他Followers保持睡眠模式
  • 当有IO请求到来时,Old leader(原来的leader)转变为Processing状态并读取IO,并在线程池中推举出新的leader来等待下一次IO请求
  • 次i时Old leader处理完一套IO和业务请求时进入Processing状态并且转变为Follower

特点

  • 由于领导者线程自己监听I/O事件并且处理客户请求，所以在本模式中不需要在线程之间传递任何额外的数据，也不需要像半同步/半反应堆模式那样在线程之间同步对请求队列的访问。（CPU耗时低）

缺点

  • 只能支持一个事件源集合，因此无法像高效的半同步/半异步模式那样让每个工作线程独立地管理多个客户连接

参考资料