I/O模型

Posted 2020-12-27

目前我们网络所面临的依然是高并发的问题，就像某cat双11时的情况，瞬间的并发量是惊人的，当然我们会有很多种方法去解决这个问题，本文我们谈论的是单台服务器，如何提高自己对并发请求的处理能力。要想解决这个问题，我们需要先理清楚Unix和类Unix系统的I/O模型。

IO也就是输入输出即读写操作，在操作系统内部逻辑上一般会分两个空间（实际是内存映射）：用户空间和内核空间。为了保证数据的安全性，只有内核才有权限从物理存储（或网络数据）上直接进行读写操作，而我们的服务进程都是处于用户空间的，所以说一次IO操作就被分为了两个阶段：1、内核从磁盘上读取数据到内核空间；2、复制内核空间中的数据到用户空间。了解这个之后我们就可以讲解下5种不同的IO模型。

阻塞IO（Blocking I/O）

阻塞IO是最早期也是原理最简单的I/O模式，应用进程发出一个I/O请求，该I/O操作不能立刻完成，它需要等待内核将数据读取出来，再等待从内核空间中将数据拷贝出来，这两个环节进行完之前，应用进程都处于阻塞状态。

非阻塞IO（Non-blocking I/O）

应用进程想内核发送一个I/O请求，如果没有可用数据，内核会向用户返回一个错误值，用户会在将来的一个合适的时候再次进行请求操作，这样就避免了进程的阻塞，这种往返的操作也被称为轮询。这里有一点需要注意的是，在Copy data from kernel user的时候进程依然是被阻塞的，之所以叫做非阻塞是因为只有在内核读写数据的阶段（上文的第一阶段）才叫做IO操作，所以在需要有大量进程并发请求时非阻塞IO模式并不比阻塞IO模式效率高，甚至更加浪费资源。

多路复用IO（I/O Multiplexing）

多路复用IO在Linux系统中一般只用于网络IO，非阻塞IO中的用户进程轮训会消耗大量的系统资源，多路复用的提出就是将这种轮训方式通过select或poll系统调用来完成，使用select/poll 操作，进程可在多个socket 上等待网络事件，当其中某个socket 发生某个网络事件时，用户可通过查看网络事件对该socket 进行I/O 操作。但当所有socket 都没有网络事件发生时，进程还会阻塞起来。所以，多路复用I/O 模型本质上还是基于阻塞I/O 的。

信号驱动式IO（Single-driven I/O）

信号驱动式IO也有叫事件驱动式IO，这种IO具有以上三种IO都不具有的优势，即当用户进程发起IO请求后即可离开，当内核将数据准备好后，将想用户进程发送一个信号以通知其来拷贝数据，第一阶段用户进程时完全的非阻塞的也不需要进行轮训，只有在第二阶段用户进程才是阻塞状态。但在多进程服务器中，信号驱动I/O 存在一个问题，即信号在产生和传递到目的进程之间，状态标志可能发生改变。

异步IO（Asynchronous I/O）

用户进程提出IO请求后即可做其他的操作，当数据准备好之后，内核会直接通知用户IO操作的结果。这种机制容易和信号驱动I/O混淆，两者的区别是：异步I/O 返回时，I/O 操作已经完成，返回的是I/O 操作的结果；信号驱动I/O 只是通知进程可以开始进行I/O 操作，进程得到这个信号后才开始I/O 操作。

五种不同IO模型的比较：

阻塞模型较为直观，服务器端为每个请求的客户连接建立一个线程或者进程，并处理这个连接数据。若有大量客户请求连接，系统就建立大量线程或者进程，线程间的上下文切换使系统性能大受影响。这种模型适合并发数不多或服务器负载不大的情况。

非阻塞I/O 主要应用在单进程服务器中。若服务器希望在当前请求的I/O 未完成时去处理其他事务，就要选择这种模型，而该模型并不知道何时再次进行I/O 请求操作，虽然可通过轮询的方法查询连接状态，但轮询操作会造成CPU 的浪费。

多路复用针对上述问题提出一种解决办法，进程可在多个描述符上等待网络I/O 事件(可读、可写)，担当没有任何网络事件发生时，进程会进入阻塞状态。因此，该模型适合多并发连接的情况，且这些并发连接大多要处于活跃状态。

信号驱动I/O的本质属于异步I/O，但这种模型存在缺点，即传统的UNIX/Linux 信号是不排队的，对于某个进程，当一个信号处于挂起状态时，若同一个信号再次产生则会被丢弃。这就不能保证每个事件的SIGIO 信号都被递送到进程。所以，当有SIGIO 到达时进程并不能确定有多少事件发生了，而要检查所有描述符；另外，SIGIO 只告诉进程有I/O 事件发生，并没有关于事件是发生在哪些描述符上的信息，所以，检查也是必须的。这种检查通常是调用select/poll 来完成的，因此，一般服务器端很少使用这种模型

Linux 以C 函数库形式提供AIO 操作函数，而C 库通过建立用户级线程实现AIO。如果应用程序请求大量异步I/O，就会产生大量线程，这些线程间的切换会导致系统性能下降。因此，AIO 适合并发数不多的服务器。

epoll 模型（poll的增强型）针对的是服务器高并发的情况。它的I/O 效率不会随连接数的增加而下降，对一个数目较大的socket 集合来说，并不一定每个socket 在任何时候都处于活跃状态，可能只有部分socket 处于活跃状态，epoll 模型并不像传统select/poll 的轮询方法那样扫描整个socket 集合，epoll 只给用户返回活跃的socket。另外，epoll 利用mmap 让内核和用户空间共用一块内存，省去了内核和用户空间间数据的拷贝，提高系统效率。这种模型适用于高并发连接服务器且活跃的连接不是很高的情况。若大部分连接都不处于活跃状态，那么这种模型的效率不一定比select/poll 高。

从上述的IO模型中我们发现在现如今常见的大量活跃并发的场景中，只有epoll模型的效率是最高的。epoll 模型通过callback 方法实现系统异步通知，socket集合中活跃的socket 通过调用callback 函数通知客户程序，省去了轮询时间，提高了网络性能，并且利用mmap 让内核和用户空间共用一块内存，省去了内核和用户空间间数据的拷贝，提高了系统效率。

PS：

用通俗的一个例子来简单描述下这几个网络IO模型：

一个钓鱼的过程，鱼钓上来放到鱼桶里是第一个阶段（鱼竿自动完成），将鱼拿到自己家的厨房是第二个几段。

阻塞IO：我们抛下鱼竿，鱼上钩放桶里再拿到厨房这个过程我们一只在这里等着，直到鱼到厨房了我们再进行其他操作。

非阻塞IO：我们抛下鱼竿，就去泡MM了，但是我们不专心泡MM，不时的回来看鱼钓上来没有，钓上来了我们就从鱼桶里的鱼拿到自己的厨房里。

多路复用IO：我们找了一个代理人，他可以一次抛下多个鱼竿，我们就看着他，一有鱼上来我们就拿走，如果所有鱼竿都没钓上来鱼，我们就等着。

信号驱动式IO：我们抛下鱼竿，然后就去泡MM了，等鱼钓上来鱼竿会给我们发短信，我们回来将桶里的鱼拿回家就行了。

异步IO：我们告诉渔场老板我们要鱼，然后就去泡MM了，等鱼钓上来后老板会直接快递到我们家。

Epoll模型：我们告诉代理人要鱼就去泡MM了，等鱼钓上来，代理人会给我们发送信息，这里的快捷地方是鱼桶就等于我们的厨房。