理解高性能网络模型

文章首发于51CTO技术栈公众号
做者 陈彩华
文章转载交流请联系 caison@aliyun.com
复制代码

随着互联网的发展，面对海量用户高并发业务，传统的阻塞式的服务端架构模式已经无能为力，由此，本文旨在为你们提供有用的概览以及网络服务模型的比较，以揭开设计和实现高性能网络架构的神秘面纱

1 服务端处理网络请求

首先看看服务端处理网络请求的典型过程：

能够看到，主要处理步骤包括：

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

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

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

以上两个关键点最终都与操做系统的I/O模型以及线程(进程)模型相关，下面详细介绍这两个模型

2 I/O模型

2.1 概念理论

介绍操做系统的I/O模型以前，先了解一下几个概念：

• 阻塞调用与非阻塞调用
  • 阻塞调用是指调用结果返回以前，当前线程会被挂起。调用线程只有在获得结果以后才会返回
  • 非阻塞调用指在不能马上获得结果以前，该调用不会阻塞当前线程

二者的最大区别在于被调用方在收到请求到返回结果以前的这段时间内，调用方是否一直在等待。阻塞是指调用方一直在等待并且别的事情什么都不作。非阻塞是指调用方先去忙别的事情

• 同步处理与异步处理

  • 同步处理是指被调用方获得最终结果以后才返回给调用方
  • 异步处理是指被调用方先返回应答，而后再计算调用结果，计算完最终结果后再通知并返回给调用方

• 阻塞、非阻塞和同步、异步的区别 阻塞、非阻塞和同步、异步其实针对的对象是不同的： 阻塞、非阻塞的讨论对象是调用者 同步、异步的讨论对象是被调用者

• recvfrom函数 recvfrom函数(经socket接收数据)，这里把它视为系统调用

一个输入操做一般包括两个不一样的阶段

• 等待数据准备好
• 从内核向进程复制数据

对于一个套接字上的输入操做，第一步一般涉及等待数据从网络中到达。当所等待分组到达时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到应用进程缓冲区

实际应用程序在系统调用完成上面2步操做时，调用方式的阻塞、非阻塞，操做系统在处理应用程序请求时处理方式的同步、异步处理的不一样，参考**《UNIX网络编程卷1》**，能够分为5种I/O模型

2.2 阻塞式I/O模型(blocking I/O）

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

比喻 一我的在钓鱼，当没鱼上钩时，就坐在岸边一直等

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

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

2.3 非阻塞式I/O模型(non-blocking I/O）

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

比喻 边钓鱼边玩手机，隔会再看看有没有鱼上钩，有的话就迅速拉杆

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

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

2.4 I/O复用模型(I/O multiplexing）

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

比喻 放了一堆鱼竿，在岸边一直守着这堆鱼竿，有鱼上钩就玩手机

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

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

2.5 信号驱动式I/O模型（signal-driven I/O)

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

比喻 鱼竿上系了个铃铛，当铃铛响，就知道鱼上钩，而后能够专心玩手机

优势 线程并无在等待数据时被阻塞，能够提升资源的利用率

缺点

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

2.6 异步I/O模型（asynchronous I/O）

简介 由POSIX规范定义，应用程序告知内核启动某个操做，并让内核在整个操做（包括将数据从内核拷贝到应用程序的缓冲区）完成后通知应用程序。这种模型与信号驱动模型的主要区别在于：信号驱动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复用模型模式为主

2.5 5种I/O模型总结

从上图中咱们能够看出，能够看出，越日后，阻塞越少，理论上效率也是最优。其五种I/O模型中，前四种属于同步I/O，由于其中真正的I/O操做(recvfrom)将阻塞进程/线程，只有异步I/O模型才于POSIX定义的异步I/O相匹配

3 线程模型

介绍完服务器如何基于I/O模型管理链接，获取输入数据，下面介绍基于进程/线程模型，服务器如何处理请求

值得说明的是，具体选择线程仍是进程，更可能是与平台及编程语言相关，例如C语言使用线程和进程均可以(例如Nginx使用进程，Memcached使用线程)，Java语言通常使用线程(例如Netty)，为了描述方便，下面都使用线程来进程描述

3.1 传统阻塞I/O服务模型

特色

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

存在问题

• 当并发数较大时，须要建立大量线程来处理链接，系统资源占用较大
• 链接创建后，若是当前线程暂时没有数据可读，则线程就阻塞在read操做上，形成线程资源浪费

3.2 Reactor模式

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

• 基于I/O复用模型，多个链接共用一个阻塞对象，应用程序只须要在一个阻塞对象上等待，无需阻塞等待全部链接。当某条链接有新的数据能够处理时，操做系统通知应用程序，线程从阻塞状态返回，开始进行业务处理
• 基于线程池复用线程资源，没必要再为每一个链接建立线程，将链接完成后的业务处理任务分配给线程进行处理，一个线程能够处理多个链接的业务

I/O复用结合线程池，这就是Reactor模式基本设计思想

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

Reactor模式中有2个关键组成：

• Reactor Reactor在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对IO事件作出反应。 它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人

• Handlers 处理程序执行I/O事件要完成的实际事件，相似于客户想要与之交谈的公司中的实际官员。Reactor经过调度适当的处理程序来响应I/O事件，处理程序执行非阻塞操做

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

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

下面详细介绍这3种实现

3.2.1 单Reactor单线程

其中，select是前面I/O复用模型介绍的标准网络编程API，能够实现应用程序经过一个阻塞对象监听多路链接请求，其余方案示意图相似

方案说明

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

优势 模型简单，没有多线程、进程通讯、竞争的问题，所有都在一个线程中完成

缺点

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

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

3.2.2 单Reactor多线程

方案说明

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

优势 能够充分利用多核CPU的处理能力

缺点

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

3.2.3 主从Reactor多线程

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

方案说明

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

优势

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

这种模型在许多项目中普遍使用，包括Nginx主从Reactor多进程模型，Memcached主从多线程，Netty主从多线程模型的支持

3.2.4 总结

3种模式能够用个比喻来理解： 餐厅经常雇佣接待员负责迎接顾客，当顾客入坐后，侍应生专门为这张桌子服务

• 单Reactor单线程 接待员和侍应生是同一我的，全程为顾客服务
• 单Reactor多线程 1个接待员，多个侍应生，接待员只负责接待
• 主从Reactor多线程 多个接待员，多个侍应生

Reactor模式具备以下的优势：

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

3.3 Proactor模型

在Reactor模式中，Reactor等待某个事件或者可应用或个操做的状态发生（好比文件描述符可读写，或者是socket可读写），而后把这个事件传给事先注册的Handler（事件处理函数或者回调函数），由后者来作实际的读写操做，其中的读写操做都须要应用程序同步操做，因此Reactor是非阻塞同步网络模型。若是把I/O操做改成异步，即交给操做系统来完成就能进一步提高性能，这就是异步网络模型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操做完成后才回调应用程序的处理器来处理进行业务处理

理论上Proactor比Reactor效率更高，异步I/O更加充分发挥DMA(Direct Memory Access，直接内存存取)的优点，可是有以下缺点：

• 编程复杂性 因为异步操做流程的事件的初始化和事件完成在时间和空间上都是相互分离的，所以开发异步应用程序更加复杂。应用程序还可能由于反向的流控而变得更加难以Debug
• 内存使用 缓冲区在读或写操做的时间段内必须保持住，可能形成持续的不肯定性，而且每一个并发操做都要求有独立的缓存，相比Reactor模式，在socket已经准备好读或写前，是不要求开辟缓存的
• 操做系统支持 Windows 下经过 IOCP 实现了真正的异步 I/O，而在 Linux 系统下，Linux2.6才引入，目前异步I/O还不完善

所以在Linux下实现高并发网络编程都是以Reactor模型为主

参考

从0开始学架构 —— Alibaba技术专家李运华

技术: Linux网络IO模型

多线程网络服务模型

IO中的阻塞、非阻塞、同步、异步

UNIX网络编程卷1：套接字联网API（第3版）

异步网络模型