Node的灵魂——非阻塞异步IO

「这是我参与2022首次更文挑战的第20天，活动详情查看：2022首次更文挑战」。

文章首发于公众号「蝉沐风」，认真写好每一篇文章，欢迎大家关注交流

我们以网络请求IO为例，首先介绍服务端处理一次完整的网络IO请求的典型流程：

应用程序获得一个操作结果，通常包括两个不同的阶段：

以下，我们以 recvfrom 函数为例，解释说明各种IO模型

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

阻塞调用是指调用结果返回之前，当前线程会被挂起，调用线程只有在等待系统内核层面所有操作完成之后，调用才会结束。

阻塞I/O造成了cpu的等待I/O，浪费了CPU的时间片。

相比于前者，非阻塞I/O不带数据直接返回，要获取数据，还需要通过文件描述符再次尝试读取数据

非阻塞调用得到返回（并不是真实的期待数据）之后，CPU时间片可以用于处理其他的事情，可以明显提升性能。

但是随之而来的问题是，之前的操作并不是一次完整的I/O，返回得到的结果不是期望得到的业务数据，而仅仅是异步调用状态。

为了获取完整的数据，应用程序需要重复调用IO操作来确认操作是否已经完成，这种操作我们称之为轮询，常见的几种轮询策略如下

这是最原始，也是性能最低的一种方式，通过重复调用来检查I/O状态达到获取完整数据的目的

优点：编程简单

缺点：CPU一直耗费在轮询上，同时影响服务器性能，因为你轮询之后服务器还要进行作答

在 I/O 复用模型中，会用到 Select 或 Poll 函数或 Epoll 函数(Linux 2.6 以后的内核开始支持)，这两个函数也会使进程阻塞，但是和阻塞 I/O 有所不同。

这三个函数可以同时阻塞多个 I/O 操作，而且可以同时对多个读操作，多个写操作的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操作函数。

三种I/O复用机制的区别如下

由于select采用1024长度的数组来存储文件状态，因此最多可以同时检测1024个文件描述符

相比select略有改进，采用链表避免了1024的长度限制，并且能避免不需要的遍历检查，相比select性能稍有改善

是linux下效率最高的I/O事件通知机制，轮询时如果没有检测到I/O事件，将会进行休眠，直到事件发生将线程唤醒。它是真正利用了事件通知，执行回调，而不是遍历（文件描述符）查询，因此不会浪费CPU

小结：本质上说，轮询仍然是一种同步操作，因为应用程序仍然在等待I/O完全返回，等待期间要么遍历文件描述状态，要么休眠等待事件的发生。

在信号驱动式 I/O 模型中，应用程序使用信号驱动 I/O，并安装一个信号处理函数，进程继续运行并不阻塞。

当数据准备好时，程序会收到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。

小结：到此为止，信号驱动式I/O模型是更加符合我们的异步需求的，程序会在等待数据的过程中异步执行其他的业务逻辑。

但是！！！ 在数据从内核复制到用户空间过程中依然是阻塞的，并不能算是一场彻底的革命（异步）。

我们理想中的异步I/O应该是应用程序发起非阻塞调用，无需通过轮询的方式进行数据获取，更没有必要在数据拷贝阶段进行无谓的等待，而是能够在I/O完成之后，通过信号或者回调函数的方式传递给应用程序，在此期间应用程序可以执行其他业务逻辑。

实际上，linux平台下原生支持了异步I/O（AIO），但是目前 AIO 并不完善，因此在 Linux 下实现高并发网络编程时都是以 I/O 复用模型为主。

而Windows 下通过 IOCP 实现了真正的异步 I/O。

linux平台下，Node利用线程池，通过让部分线程进行阻塞I/O或者非阻塞I/O+轮询的方式完成数据获取，让某一个单独的线程进行计算，通过线程之间的通信，将I/O结果进行传递，这样便实现了异步I/O的模拟。

其实Windows平台下的IOCP异步异步方案底层也是采用线程池的方式实现的，所不同的是，后者的线程池是由系统内核进行托管的。

我们常说Node是单线程的，但其实只能说是JS执行在单线程中，无论是*nix还是windows平台，底层都是利用线程池来完成I/O操作。