I/O模型简述

最新推荐文章于 2023-07-10 11:01:59 发布

转载最新推荐文章于 2023-07-10 11:01:59 发布 · 854 阅读

文章标签：

#I/O #模型

Java 专栏收录该内容

673 篇文章

订阅专栏

1. 前言

最近在学习 Java NIO 方面的知识，为了加深理解。特地去看了 Unix/Linux I/O 方面的知识，并写了一些代码进行验证。在本文接下来的一章中，我将通过举例的方式向大家介绍五种 I/O 模型。如果大家是第一次了解 I/O 模型方面的知识，理解起来会有一定的难度。所以在看文章的同时，我更建议大家动手去实现这些 I/O 模型，感觉会不一样。好了，下面咱们一起进入正题吧。

2. I/O 模型

本章将向大家介绍五种 I/O 模型，包括阻塞 I/O、非阻塞 I/O、I/O 复用、信号驱动式 I/O 、异步 I/O 等。本文的内容参考了《UNIX网络编程》，文中所用部分图片也是来自于本书。关于《UNIX网络编程》这本书，我想就不用多说了。很多写网络编程方面的文章一般都会参考该书，本文也不例外。如果大家想进深入学习网络编程，建议去读读这本书。

2.1 阻塞 I/O 模型

阻塞 I/O 是最简单的 I/O 模型，一般表现为进程或线程等待某个条件，如果条件不满足，则一直等下去。条件满足，则进行下一步操作。相关示意图如下：

上图中，应用进程通过系统调用 recvfrom 接收数据，但由于内核还未准备好数据报，应用进程就阻塞住了。直到内核准备好数据报，recvfrom 完成数据报复制工作，应用进程才能结束阻塞状态。

这里简单解释一下应用进程和内核的关系。内核即操作系统内核，用于控制计算机硬件。同时将用户态的程序和底层硬件隔离开，以保障整个计算机系统的稳定运转（如果用户态的程序可以控制底层硬件，那么一些病毒就会针对硬件进行破坏，比如 CIH 病毒）。应用进程即用户态进程，运行于操作系统之上，通过系统调用与操作系统进行交互。上图中，内核指的是 TCP/IP 等协议及相关驱动程序。客户端发送的请求，并不是直接送达给应用程序，而是要先经过内核。内核将请求数据缓存在内核空间，应用进程通过 recvfrom 调用，将数据从内核空间拷贝到自己的进程空间内。大致示意图如下：

阻塞 I/O 理解起来并不难，不过这里还是举个例子类比一下。假设大家日常工作流程设这样的（其实就是我日常工作的流程?），我们写好代码后，本地测试无误，通过邮件的方式，告知运维同学发布服务。运维同学通过发布脚本打包代码，重启服务（心疼我司的人肉运维）。一般项目比较大时，重启一次比较耗时。而运维同学又有点死脑筋，非要等这个服务重启好，再去做其他事。结果一天等待的时间比真正工作的时间还要长，然后就被开了。运维同学用这个例子告诉我们，阻塞式 I/O 效率不太好。

2.2 非阻塞 I/O 模型

与阻塞 I/O 模型相反，在非阻塞 I/O 模型下。应用进程与内核交互，目的未达到时，不再一味的等着，而是直接返回。然后通过轮询的方式，不停的去问内核数据准备好没。示意图如下：

上图中，应用进程通过 recvfrom 系统调用不停的去和内核交互，直到内核准备好数据报。从上面的流程中可以看出，应用进程进入轮询状态时等同于阻塞，所以非阻塞的 I/O 似乎并没有提高进程工作效率。

再用上面的例子进行类比。公司辞退了上一个怠工的运维同学后，又招了一个运维同学。这个运维同学每次重启服务，隔一分钟去看一下，然后进入发呆状态。虽然真正的工作时间增加了，但是没用啊，等待的时间还是太长了。被公司发现后，又被辞了。

2.3 I/O 复用模型

Unix/Linux 环境下的 I/O 复用模型包含三组系统调用，分别是 select、poll 和 epoll（FreeBSD 中则为 kqueue）。select 出现的时间最早，在 BSD 4.2中被引入。poll 则是在 AT&T System V UNIX 版本中被引入（详情请参考 UNIX man-page）。epoll 出现在 Linux kernel 2.5.44 版本中，与之对应的 kqueue 调用则出现在 FreeBSD 4.1，早于 epoll。select 和 poll 出现的时间比较早，在当时也是比较先进的 I/O 模型了，满足了当时的需求。不过随着因特网用户的增长，C10K 问题出现。select 和 poll 已经不能满足需求了，研发更加高效的 I/O 模型迫在眉睫。到了 2000 年，FreeBSD 率先发布了 select、poll 的改进版 kqueue。Linux 平台则在 2002 年 2.5.44 中发布了 epoll。好了，关于三者的一些历史就说到这里。本节接下来将以 select 函数为例，简述该函数的使用过程。

select 有三个文件描述符集（readfds），分别是可读文件描述符集（writefds）、可写文件描述符集和异常文件描述符集（exceptfds）。应用程序可将某个 socket （文件描述符）设置到感兴趣的文件描述符集中，并调用 select 等待所感兴趣的事件发生。比如某个 socket 处于可读状态了，此时应用进程就可调用 recvfrom 函数把数据从内核空间拷贝到进程空间内，无需再等待内核准备数据了。示意图如下：

一般情况下，应用进程会将多个 socket 设置到感兴趣的文件描述符集中，并调用 select 等待所关注的事件（比如可读、可写）处于就绪状态。当某些 socket 处于就绪状态后，select 返回处于就绪状态的 sockct 数量。注意这里返回的是 socket 的数量，并不是具体的 socket。应用程序需要自己去确定哪些 socket 处于就绪状态了，确定之后即可进行后续操作。

I/O 复用本身不是很好理解，所以这里还是举例说明吧。话说公司的运维部连续辞退两个运维同学后，运维部的 leader 觉得需要亲自监督一下大家工作。于是 leader 在周会上和大家说，从下周开始，所有的发布邮件都由他接收，并由他转发给相关运维同学，同时也由他重启服务。各位运维同学需要告诉 leader 各自所负责监控的项目，服务重启好后，leader 会通过内部沟通工具通知相关运维同学。至于服务重启的结果（成功或失败），leader 不关心，需要运维同学自己去看。运维同学看好后，需要把结果回复给开发同学。

上面的流程可能有点啰嗦，所以还是看图吧。

把上面的流程进行分步，如下：

开发同学将发布邮件发送给运维 leader，并指明这个邮件应该转发给谁
运维告诉 leader，如果有发给我的邮件，请发送给我
leader 把邮件转发给相关的运维同学，并着手重启服务
运维同学看完邮件，告诉 leader 某某服务重启好后，请告诉我
服务重启好，leader 通知运维同学xx服务启动好了
运维同学查看服务启动情况，并返回信息给开发同学

这种方式为什么可以提高工作效率呢？原因在于运维同学一股脑把他所负责的几十个项目都告诉了 leader，由 leader 重启服务，并通知运维同学。运维同学这个时候等待 leader 的通知，只要其中一个或几个服务重启好了，运维同学就回接到通知，然后就可去干活了。而不是像以前一样，非要等某个服务重启好再进行后面的工作。

说一下上面例子的角色扮演。开发同学是客户端，leader 是内核。开发同学发的邮件相当于网络请求，leader 接收邮件，并重启服务，相当于内核准备数据。运维同学是服务端应用进程，告诉 leader 自己感兴趣的事情，并在最后将事情的处理结果返回给开发同学。

不知道大家有没有理解上面的例子，I/O 复用本身可能就不太好理解，所以看不懂也不要气馁。另外，上面的例子只是为了说明情况，现实中并不会是这样干，不然 leader 要累死了。如果大家觉得上面的例子不太好，我建议大家去看看权威资料《UNIX网络编程》。同时，如果能用 select 写个简单的 tcp 服务器，有助于加深对 I/O 复用的理解。如果不会写，也可以参考我写的代码 select_server.c。

2.4 信号驱动式 I/O 模型

信号驱动式 I/O 模型是指，应用进程告诉内核，如果某个 socket 的某个事件发生时，请向我发一个信号。在收到信号后，信号对应的处理函数会进行后续处理。示意图如下：

再用之前的例子进行说明。某个运维同学比较聪明，他写了一个监控系统。重启服务的过程由监控系统来做，做好后，监控系统会给他发个通知。在此之前，运维同学可以去做其他的事情，不用一直发呆等着了。运维同学收到通知后，首先去检查服务重启情况，接着再给开发同学回复邮件就行了。

相比之前的工作方式，是不是感觉这种方式更合理。从流程上来说，这种方式确实更合理。进程在信号到来之前，可以去做其他事情，而不用忙等。但现实中，这种 I/O 模型用的并不多。

2.5 异步 I/O 模型

异步 I/O 是指应用进程把文件描述符传给内核后，啥都不管了，完全由内核去操作这个文件描述符。内核完成相关操作后，会发信号告诉应用进程，某某 I/O 操作我完成了，你现在可以进行后续操作了。示意图如下：

上图通过 aio_read 把文件描述符、数据缓存空间，以及信号告诉内核，当文件描述符处于可读状态时，内核会亲自将数据从内核空间拷贝到应用进程指定的缓存空间呢。拷贝完在告诉进程 I/O 操作结束，你可以直接使用数据了。

接着上一节的例子进行类比，运维小哥升级了他的监控系统。此时，监控系统不光可以监控服务重启状态，还能把重启结果整理好，发送给开发小哥。而运维小哥要做的事情就更简单了，收收邮件，点点监控系统上的发布按钮。然后就可以悠哉悠哉的继续睡觉了，一天一天的就这么过去了。

2.6 总结

上面介绍了5种 I/O 模型，也通过举例的形式对每种模型进行了补充说明，不知道大家看懂没。抛开上面的 I/O 模型不谈，如果某种 I/O 模型能让进程的工作的时间大于等待的时间，那么这种模型就是高效的模型。在服务端请求量变大时，通过 I/O 复用模型可以让进程进入繁忙的工作状态中，减少忙等，进而提高了效率。

I/O 复用模型结果数次改进，目前性能已经很好了，也得到了广泛应用。像 Nginx，lighttd 等服务器软件都选用该模型。好了，关于 I/O 模型就说到这里。

最后附一张几种 I/O 模型的对比图：

3. 写在最后

前面简述了几种 I/O 模型，并辅以例子进行说明。关于 I/O 模型的文章，网上有很多。大家也是各开脑洞，用了不同的例子进行类比说明，包括但不限于送外卖、送快递、飞机调度等等。在写这篇文章前，我也是绞尽脑汁，希望想一个不同的例子，不然如果和别人的太像，免不了有抄袭的嫌疑。除此之外，举的例子还要尽量是大家都知道的，同时又能说明问题。所以这篇文章想例子想的也是挺累的。另外，限于本人语言水平，文中有些地方可能未能描述清楚。如果给大家造成了困扰，在这里说声抱歉。最后声明一下，本文的例子拿运维同学举例，本人并无意黑运维同学。我们公司运维自动化程度不高，运维同事们还是很辛苦的，心疼5分钟。

好了，本文到这里就结束了，谢谢大家阅读！