Node.js异步IO原理剖析

为什么要异步I/O？

从用户体验角度讲，异步IO可以消除UI阻塞，快速响应资源
- JavaScript是单线程的，它与UI渲染共用一个线程。所以在JavaScript执行的时候，UI渲染将处于停顿的状态，用户体验较差。而异步请求可以在下载资源的时候，JavaScript和UI渲染都同时执行，消除UI阻塞，降低响应资源需要的时间开销。
- 假如一个资源来自两个不同位置的数据的返回，第一个资源需要M毫秒的耗时，第二个资源需要N毫秒的耗时。当采用同步的方式，总耗时为（M+N）毫秒，代码大致如下：
```
//耗时为M毫秒

getData('from_db');

//耗时为N毫秒

getData('from_remote_api');
```
  当采用异步的方式，总耗时为max（M，N），代码大致如下：
```
getData('from_db',function(result){

  //消费时间为M

});

getData('from_remote_api',function(result){

  //消费时间为N

});
```
  随着应用的复杂性，情景会变成M+N+...和max（M，N，...），此时同步和异步的优劣就会更加凸显。另一方面，随着网站和应用的扩展，数据往往会分布到多台服务器上，而分布意味着M和N的值会线性增长，这也会放大异步和同步在性能上的差异。总之，IO是昂贵的，分布式IO是更昂贵的！

从资源分配角度讲，异步IO可以让单线程远离阻塞，以更好地利用CPU
- 假设业务线上有一组互不相关的任务需要完成，现行的主流方法有以下两种：
  - 单线程同步执行：会阻塞IO导致硬件资源和CPU得不到更优的使用
  - 多线程并发执行：会出现死锁、状态同步等问题
- Node的解决方案
  - 利用单线程，远离多线程的死锁、状态同步等问题；
  - 利用异步I/O，让单线程远离阻塞，更好的利CPU

　　　　　　　　　　图1-异步I/O调用示意图

异步IO实现现状？

I/O的阻塞与非阻塞：IO对于操作系统内核而言，只有阻塞与非阻塞两种方式。阻塞模式的I/O会造成应用程序等待，直到I/O完成，会造成CPU等待IO，浪费等待时间，CPU的处理能力不能充分利用。同时操作系统也支持将I/O操作设置为非阻塞模式，这时应用程序的调用将可能在没有拿到真正数据时就立即返回了，为此应用程序需要多次调用才能确认I/O操作完全完成，但由于IO并没有完成，立即返回的并不是业务层期望的数据，仅仅是当前调用的状态。
I/O的同步与异步：I/O的同步与异步出现在应用程序中。如果做阻塞I/O调用，应用程序等待调用的完成的过程就是一种同步状况。相反，I/O为非阻塞模式时，应用程序则是异步的。

图2-阻塞IO调用示意图图3-非阻塞IO调用示意图

为了获取完整的数据，应用程序需要重复调用IO操作来确认是否完成，叫做轮询。轮询技术主要有以下这些：

read：它是最原始，性能最低的一种。
select：在read基础上的改进方案，通过对文件描述符上的事件状态进行判断。
poll：较select有所改进，采用链表的方式避免数据长度的限制，其次它能避免不必要的检查。但在文件描述符过多时，性能十分低下。
epoll：该方案是Linux下效率最高的IO事件通知机制，具体方法见图。

　　　　　　　　图4-read方式图5-select方式

图6-poll方式图7-epoll方式

尽管epoll已经利用事件来降低了CPU的耗用，但是休眠期间CPU是闲置的，对于当前线程而言利用率不够。那么，是否有一种理想的异步I/O呢？

答案是当然有！理想的异步I/O实现如下图所示：

图8-理想中的异步IO方式示意图

天真的程序员们曾经幻想：我们可以通过信号或回调将数据传递给应用程序啊！

　的确，Linux下提供了一种异步IO的方式（AIO），它就是通过信号或回调传递数据的。

　但不幸的是，只有Linux下有，而且还存在一些如系统缓存无法利用的缺陷。

后来，经过反复的思考与实践，现实中的异步IO是这样实现的：

图9-现实中的异步IO示意图

其核心思想是：利用多线程，主线程负责计算，IO线程负责IO操作，线程间通过信号进行通信。

聪明的你也许会问：Node不是单线程吗，如何实现多线程呢？

　其实，Node底层是可以实现多线程的，只是上层提供给用户的JavaScript是单线程的。而这里，我们探讨的正是Node底层是如何实现异步IO的？

如果再细一点，其实Linux是利用如上的多线程创建线程池实现的，而Windows则是利用IOCP创建的。

　　　　图10-Node异步IO底层实现框架图

Node异步IO的实现？

在清楚了Node底层对异步IO的实现原理后，我们就可以进一步理解一个Node进程是如何实现完整的异步IO的了！

Node的异步I/O模型：事件循环、观察者、请求对象、执行回调是四个核心概念。
- 事件循环：进程启动时，Node会创建一个类似while（true）的循环，判断是否有事件需要处理，若有，取出事件并执行回调函数。

　　　　　　　　　　　　　　图11-Node事件循环示意图

- 观察者：观察者是用来判断是否有事件需要处理。事件循环中有一到多个观察者，判断过程会向观察者询问是否有需要处理的事件。这个过程类似于饭店的厨师与前台服务员的关系。厨师每做完一轮菜，就会向前台服务员询问是否有要做的菜，如果有就继续做，没有的话就下班了。这一过程中，前台服务员就相当于观察者，她收到的顾客点单就是回调函数。

　　　　注：事件循环是一个典型的生产者/消费者模型。异步I/O、网络请求是生产者，而事件循环则从观察者那里取出事件并处理。

- 请求对象：实际上，从JavaScript发起调用到内核执行完I/O操作的过渡过程中，存在一种中间产物，叫做请求对象。以fs.open( )方法为例，
```
fs.open = function(path, flags, mode, callback) {

//...

binding.open(pathModule._makeLong(path),

stringToFlags(flags),

mode,

callback);

};
```
  　　
  
  这个函数的作用是根据指定的路径和参数去打开一个文件，从而得到一个文件描述符，是后续所有I/O操作的初始操作。

图12-fs.open调用示意图

整个调用过程：JavaScript -> Node核心模块 -> C++内建模块 -> libuv系统调用

　　　　　在uv_fs_open的调用过程中，Node.js创建了一个FSReqWrap请求对象。从JavaScript传入的参数和当前方法都被封装在这个请求对象中，其中回调函数则被设置在这个对象的oncomplete_sym属性上。

　　　　　　 req_wrap->object_->Set(oncomplete_sym, callback);

对象包装完毕后，调用QueueUserWorkItem方法将这个FSReqWrap对象推入线程池中等待执行。

QueueUserWorkItem(&uv_fs_thread_proc, req, WT_EXECUTELONGFUNCTION)

QueueUserWorkItem接受三个参数，第一个是要执行的方法，第二个是方法的上下文，第三个是执行的标志。

至此，由JavaScript层面发起的异步调用第一阶段就此结束。

- 执行回调：组装好请求对象，送入I/O线程池等待执行，实际上完成了异步I/O的第一部分，回调通知是第二部分。当线程池中有可用线程的时候调用uv_fs_thread_proc方法执行。该方法会根据传入的类型调用相应的底层函数，以uv_fs_open为例，实际会调用到fs__open方法。调用完毕之后，会将获取的结果设置在req->result上。然后调用PostQueuedCompletionStatus通知我们的IOCP*对象操作已经完成，并将线程归还给线程池。

PostQueuedCompletionStatus((loop)->iocp, 0, 0, &((req)->overlapped)

　　　　　 PostQueuedCompletionStatus方法的作用是向创建的IOCP上相关的线程通信，线程根据执行状况和传入的参数判定退出。

在这一过程中，每次事件循环会调用GetQueuedCompletionStatus（）方法检查线程池中是否有执行完的请求，若有，会将请求对象加入到I/O观察者的队列中，将其作为事件处理。

I/O观察者回调函数的行为就是取出请求对象的result属性作为参数，取出oncomplete_sym属性作为方法，然后调用执行，以此达到执行回调函数的目的。

　　　　　　　　　　图13-Node整个异步IO流程示意图

总结

JavaScript是单线程的，但Node本身其实是多线程的，除了用户代码无法并行执行外，所有的I/O请求是可以并行执行的。
事件循环是Node异步I/O实现的核心，Node通过事件驱动的方式处理请求，使得其无须为每个请求创建额外的线程，省掉了创建和销毁线程的开销。同时也因为线程数较少，不受线程上下文切换的影响，维持了Node的高性能。
Node异步IO、非阻塞的特性，使它非常适用于IO密集、高并发的应用场景。