高性能网络模型学习

Posted on | In | 浏览 次
Words count in article: 5.2k | Reading time ≈ 18

本文的内容为学习自一些网上优秀的博客以及最近看的一些进阶拓展的书的笔记和总结

服务端处理网络请求

服务端处理网络请求的典型模型

服务端处理网络请求流程图

主要步骤：

  • 获取请求数据 客户端与服务器建立链接发出请求，服务器接收请求（1-3）
  • 构建响应 当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）
  • 返回数据 服务器将已构建好的响应再通过内核空间的网络I/O发还给客户端（5-7）

设计服务端并发模型时，主要有如下两个关键点：

  • 服务器如何管理连接，获取输入数据
  • 服务器如何处理请求

以上关键点最终都与操作系统的 I/O 模型以及线程（进程）模型相关，以下将会进行介绍

I/O 模型

其实之前写过的一篇博客Linux| 网络IO模型已经论述过相关的基础概念，此处仅做简单阐述以及比较优缺点。
在此之前还是需要重申一点比较重要的概念

理解同步/异步和阻塞/非阻塞的区别

理解同步/异步和阻塞/非阻塞的区别

  • 同步、异步：
    • 概念：消息的通知机制
    • 解释：涉及到IO通知机制；所谓同步，就是发起调用后，被调用者处理消息，必须等处理完才直接返回结果，没处理完之前是不返回的，调用者主动等待结果；所谓异步，就是发起调用后，被调用者直接返回，但是并没有返回结果，等处理完消息后，通过状态、通知或者回调函数来通知调用者，调用者被动接收结果。
  • 阻塞、非阻塞：
    • 概念：程序等待调用结果时的状态
    • 解释：涉及到CPU线程调度；所谓阻塞，就是调用结果返回之前，该执行线程会被挂起，不释放CPU执行权，线程不能做其它事情，只能等待，只有等到调用结果返回了，才能接着往下执行；所谓非阻塞，就是在没有获取调用结果时，不是一直等待，线程可以往下执行，如果是同步的，通过轮询的方式检查有没有调用结果返回，如果是异步的，会通知回调。
  • 经典故事案例：
    • 人物：老张
    • 道具：普通水壶（水烧开不响）；响水壶（水烧开发出响声）
    • 案例
      1. 同步阻塞
        老张在厨房用普通水壶烧水，一直在厨房等着（阻塞），盯到水烧开（同步）
      2. 异步阻塞
        老张在厨房用响水壶烧水，一直在厨房中等着（阻塞），直到水壶发出响声（异步），老张知道水烧开了；
      3. 同步非阻塞
        老张在厨房用普通水壶烧水，在烧水过程中，就到客厅去看电视（非阻塞），然后时不时去厨房看看水烧开了没（轮询检查同步结果）；
      4. 异步非阻塞
        老张在厨房用响水壶烧水，在烧水过程中，就到客厅去看电视（非阻塞），当水壶发出响声（异步），老张就知道水烧开了。
  • 阻塞与非阻塞
    阻塞和非阻塞的概念描述的是用户线程调用内核 IO 操作的方式：阻塞是指 IO 操作需要彻底完成后才返回到用户空间；而非阻塞是指 IO 操作被调用后立即返回给用户一个状态值，不需要等到IO操作彻底完成。
  • 同步与异步
    • 同步处理是指被调用方得到最终结果之后才返回给调用方
    • 异步处理是指被调用方先返回应答，然后再计算调用结果，计算完最终结果后再通知并返回给调用方

阻塞式 I/O 模型

阻塞IO模型

在阻塞式I/O模型中，应用程序在从调用recvfrom开始到它返回有数据报准备好这段时间是阻塞的，recvfrom返回成功后，应用进程开始处理数据报

优点 程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用CPU资源

缺点 每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，这种模型在实际生产中很少使用

非阻塞式 I/O 模型

非阻塞IO模型

在非阻塞式I/O模型中，应用程序把一个套接口设置为非阻塞就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误，应用程序基于I/O操作函数将不断的轮询数据是否已经准备好，如果没有准备好，继续轮询，直到数据准备好为止

优点 不会阻塞在内核的等待数据过程，每次发起的I/O请求可以立即返回，不用阻塞等待，实时性较好

缺点 轮询将会不断地询问内核，这将占用大量的CPU时间，系统资源利用率较低，所以一般Web服务器不使用这种I/O模型

I/O 复用模型

I/O复用模型

在I/O复用模型中，会用到select或poll函数或epoll函数(Linux2.6以后的内核开始支持)，这三个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这三个函数可以同时阻塞多个I/O操作，而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数

优点 可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程)，这样可以大大节省系统资源

缺点 当连接数较少时效率相比多线程+阻塞I/O模型效率较低，可能延迟更大，因为单个连接处理需要2次系统调用，占用时间会有增加

信号驱动式 I/O 模型

在信号驱动式I/O模型中，应用程序使用套接口进行信号驱动I/O，并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据

信号驱动式I/O模型

优点 线程并没有在等待数据时被阻塞，可以提高资源的利用率

缺点

  • 信号I/O在大量IO操作时可能会因为信号队列溢出导致没法通知
  • 信号驱动I/O尽管对于处理UDP套接字来说有用，即这种信号通知意味着到达一个数据报，或者返回一个异步错误。但是，对于TCP而言，信号驱动的I/O方式近乎无用，因为导致这种通知的条件为数众多，每一个来进行判别会消耗很大资源，与前几种方式相比优势尽失

异步 I/O 模型

异步I/O模型

由POSIX规范定义，应用程序告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到应用程序的缓冲区）完成后通知应用程序。异步IO模型与信号驱动模型的主要区别在于：信号驱动I/O是由内核通知应用程序何时启动一个I/O操作，而异步I/O模型是由内核通知应用程序I/O操作何时完成

优点 异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠

缺点 要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的异步 I/O，而在 Linux 系统下，Linux2.6才引入，目前 AIO 并不完善，因此在 Linux 下实现高并发网络编程时都是以IO复用模型模式为主

什么是AIO

总结

IO模型总结

五种 I/O 模型中，前四种属于同步 I/O ，因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才于POSIX定义的异步 I/O 相匹配

线程模型

介绍完服务器如何基于I/O模型管理连接，获取输入数据，下面介绍基于进程/线程模型，服务器如何处理请求
值得说明的是，具体选择线程还是进程，更多是与平台及编程语言相关，例如C语言使用线程和进程都可以(例如Nginx使用进程，Memcached使用线程)，Java语言一般使用线程(例如Netty)。

传统阻塞 I/O 服务模型

传统阻塞I/O服务模型

特点

  • 采用阻塞式 I/O 模型获取输入数据
  • 每个链接都需要独立的线程完成数据输入，业务处理，数据返回的完整操作

存在问题

  • 当并发数较大时，需要创建大量线程来处理连接，系统资源占用较大
  • 连接建立后，如果当前线程暂时没有数据可读，则线程就阻塞在read操作上，造成线程资源浪费

Reactor 模式

针对传统传统阻塞I/O服务模型的2个缺点，比较常见的有如下解决方案

  • 基于I/O复用模型，多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理
  • 基于线程池复用线程资源，不必再为每个连接创建线程，将连接完成后的业务处理任务分配给线程进行处理，一个线程可以处理多个连接的业务
    I/O复用结合线程池，这就是Reactor模式基本设计思想

Reactor模式

Reactor模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。

服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor模式也叫Dispatcher模式，即I/O多了复用统一监听事件，收到事件后分发(Dispatch给某进程)，是编写高性能网络服务器的必备技术之一

Reactor模式中有2个关键组成

  • Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对IO事件做出反应。它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人
  • Handlers 处理程序执行I/O事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际官员。Reactor通过调度适当的处理程序来响应I/O事件，处理程序执行非阻塞操作

根据Reactor的数量和处理资源池线程的数量不同，有3种典型的实现

  • 单Reactor单线程
  • 单Reactor多线程
  • 主从Reactor多线程

下面详细介绍这3种实现

单Reactor单线程

单Reactor单线程

select 可以使用其他I/O复用模型来进行替换

方案说明

  • Reactor对象通过select监控客户端请求事件，收到事件后通过dispatch进行分发
  • 如果是建立连接请求事件，则由Acceptor通过accept处理连接请求，然后创建一个Handler对象处理连接完成后的后续业务处理
  • 如果不是建立连接事件，则Reactor会分发调用连接对应的Handler来响应
  • Handler会完成read->业务处理->send的完整业务流程

优点
模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成

缺点

  • 性能问题：只有一个线程，无法完全发挥多核CPU的性能 Handler在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈
  • 可靠性问题：线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障

使用场景
客户端的数量有限，业务处理非常快速，比如Redis，业务处理的时间复杂度O(1)

单Reactor多线程

单Reactor多线程

方案说明

  • Reactor对象通过select监控客户端请求事件，收到事件后通过dispatch进行分发
  • 如果是建立连接请求事件，则由Acceptor通过accept处理连接请求，然后创建一个Handler对象处理连接完成后的续各种事件
  • 如果不是建立连接事件，则Reactor会分发调用连接对应的Handler来响应
  • Handler只负责响应事件，不做具体业务处理，通过read读取数据后，会分发给后面的Worker线程池进行业务处理
  • Worker线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给Handler进行处理
  • Handler收到响应结果后通过send将响应结果返回给client

优点
可以充分利用多核CPU的处理能力

缺点

  • 多线程数据共享和访问比较复杂
  • Reactor 承担所有事件的监听和响应，在单线程中运行，高并发场景下容易成为性能瓶颈

主从Reactor多线程

针对单Reactor多线程模型中，Reactor在单线程中运行，高并发场景下容易成为性能瓶颈，可以让Reactor在多线程中运行
主从Reactor多线程

方案说明

  • Reactor主线程MainReactor对象通过select监控建立连接事件，收到事件后通过Acceptor接收，处理建立连接事件
  • Acceptor处理建立连接事件后，MainReactor将连接分配Reactor子线程给SubReactor进行处理
  • SubReactor将连接加入连接队列进行监听，并创建一个Handler用于处理各种连接事件
  • 当有新的事件发生时，SubReactor会调用连接对应的Handler进行响应
  • Handler通过read读取数据后，会分发给后面的Worker线程池进行业务处理
  • Worker线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给Handler进行处理
  • Handler收到响应结果后通过send将响应结果返回给client

优点

  • 父线程与子线程的数据交互简单职责明确，父线程只需要接收新连接，子线程完成后续的业务处理
  • 父线程与子线程的数据交互简单，Reactor主线程只需要把新连接传给子线程，子线程无需返回数据

Reactor 总结

Reactor模式具有如下的优点

  • 响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的
  • 编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
  • 可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源
  • 可复用性，Reactor模型本身与具体事件处理逻辑无关，具有很高的复用性

Proactor模型

在Reactor模式中，Reactor等待某个事件或者可应用或个操作的状态发生（比如文件描述符可读写，或者是socket可读写），然后把这个事件传给事先注册的Handler（事件处理函数或者回调函数），由后者来做实际的读写操作，其中的读写操作都需要应用程序同步操作，所以Reactor是非阻塞同步网络模型。如果把I/O操作改为异步，即交给操作系统来完成就能进一步提升性能，这就是异步网络模型Proactor

Proactor模型

Proactor是和异步I/O相关的，详细方案如下

  • ProactorInitiator创建Proactor和Handler对象，并将Proactor和Handler都通过AsyOptProcessor（Asynchronous Operation Processor）注册到内核
  • AsyOptProcessor处理注册请求，并处理I/O操作
  • AsyOptProcessor完成I/O操作后通知Proactor
  • Proactor根据不同的事件类型回调不同的Handler进行业务处理
  • Handler完成业务处理

可以看出Proactor和Reactor的区别：Reactor是在事件发生时就通知事先注册的事件（读写在应用程序线程中处理完成）；Proactor是在事件发生时基于异步I/O完成读写操作（由内核完成），待I/O操作完成后才回调应用程序的处理器来处理进行业务处理

Reactor和Proactor对比

举例分析

Reactor模式中读取操作

  • 应用程序注册读就绪事件和相关联的事件处理器
  • 事件分离器等待事件的发生
  • 当发生读就需事件的时候，事件分离器调用第一步注册的事件处理器
  • 事件处理器首先执行实际的读取操作，然后根据读取到的内容进行进一步的处理

Proactor模式中读取操作

  • 应用程序初始化一个异步读取操作，然后注册相应的事件处理器，此时事件处理器不关注读取就绪事件，而是关注读取完成事件，这是区别于Reactor的关键
  • 事件分离器等待读取操作完成事件
  • 在事件分离器等待读取操作完成的时候，操作系统调用内核线程完成读取操作，并将读取的内容放入用户传递过来的缓存区中。这也是区别于Reactor的一点，Proactor中，应用程序需要传递缓存区
  • 事件分离器捕获到读取完成事件后，激活应用程序注册的事件处理器，事件处理器直接从缓存区读取数据，而不需要进行实际的读取操作

从上面可以看出，Reactor和Proactor模式的主要区别就是真正的读取和写入操作是有谁来完成的，Reactor中需要应用程序自己读取或者写入数据，而Proactor模式中，应用程序不需要进行实际的读写过程，它只需要从缓存区读取或者写入即可，操作系统会读取缓存区或者写入缓存区到真正的IO设备

实现

  • Reactor实现了一个被动的事件分离和分发模型，服务等待请求事件的到来，再通过不受间断的同步处理事件，从而做出反应
  • Proactor实现了一个主动的事件分离和分发模型；这种设计允许多个任务并发的执行，从而提高吞吐量；并可执行耗时长的任务（各个任务间互不影响）

优缺点

优点
Reactor实现相对简单，对于耗时短的处理场景处理高效

  • 操作系统可以在多个事件源上等待，并且避免了多线程编程相关的性能开销和编程复杂性
  • 事件的串行化对应用是透明的，可以顺序的同步执行而不需要加锁
  • 事务分离：将与应用无关的多路分解和分配机制和与应用相关的回调函数分离开来

Proactor性能更高，能够处理耗时长的并发场景；

缺点
Reactor处理耗时长的操作会造成事件分发的阻塞，影响到后续事件的处理；

Proactor实现逻辑复杂；依赖操作系统对异步的支持，目前实现了纯异步操作的操作系统少，实现优秀的如windows IOCP，但由于其windows系统用于服务器的局限性，目前应用范围较小；而Unix/Linux系统对纯异步的支持有限，应用事件驱动的主流还是通过select/epoll来实现

适用场景

Reactor：同时接收多个服务请求，并且依次同步的处理它们的事件驱动程序
Proactor：异步接收和同时处理多个服务请求的事件驱动程序

参考链接