分布式&高可用Java技术升华程序员

理解高性能网络模型

2018-09-05  本文已影响5人  caison 
文章首发于51CTO技术栈公众号
作者 陈彩华
文章转载交流请联系 caison@aliyun.com

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

1 服务端处理网络请求

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

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

可以看到，主要处理步骤包括：

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

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

2 I/O模型

2.1 概念理论

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

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

一个输入操作通常包括两个不同的阶段

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

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

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

阻塞式I/O模型

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

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

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

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

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

非阻塞式I/O模型

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

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

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

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

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

I/O复用模型

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

比喻
鱼竿上系了个铃铛，当铃铛响，就知道鱼上钩，然后可以专心玩手机

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

缺点

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

异步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服务模型

特点

存在问题

3.2 Reactor模式

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

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

Reactor

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

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

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

下面详细介绍这3种实现

3.2.1 单Reactor单线程

单Reactor单线程

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

方案说明

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

缺点

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

3.2.2 单Reactor多线程

单Reactor多线程

方案说明

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

缺点

3.2.3 主从Reactor多线程

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

主从Reactor多线程

方案说明

优点

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

3.2.4 总结

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

Reactor模式具有如下的优点：

3.3 Proactor模型

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

Proactor

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

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

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

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

参考

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

技术: Linux网络IO模型

多线程网络服务模型

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

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

异步网络模型

上一篇 下一篇

猜你喜欢

热点阅读