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.1-异步I/O调用示意图

异步IO实现现状？

I/O的阻塞与非阻塞：IO对于操作系统内核而言，只有阻塞与非阻塞两种方式。阻塞模式的I/O会造成应用程序等待，直到I/O完成。同时操作系统也支持将I/O操作设置为非阻塞模式，这时应用程序的调用将可能在没有拿到真正数据时就立即返回了，为此应用程序需要多次调用才能确认I/O操作完全完成。这种重复调用判断操作是否完成的技术叫做“轮询”。

I/O的同步与异步：I/O的同步与异步出现在应用程序中。如果做阻塞I/O调用，应用程序等待调用的完成的过程就是一种同步状况。相反，I/O为非阻塞模式时，应用程序则是异步的。

• 调用阻塞IO：会造成CPU等待IO，浪费等待时间，CPU的处理能力不能充分利用：

• 调用非阻塞IO：虽然不会阻塞IO，但由于IO并没有完成，立即返回的并不是业务层期望的数据，仅仅是当前调用的状态
• 。

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

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

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

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

聪明的你想到了：我们可以通过信号或回调将数据传递给应用程序啊！

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

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

所以，在现实中的异步IO是这样实现的：

我们利用多线程，主线程负责计算，IO线程负责IO操作，线程间通过信号进行通信。

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

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

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

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

• Node的异步I/O模型：
  • 事件循环：进程启动时，Node会创建一个类似while（true）的循环，判断是否有事件需要处理

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

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

• • 请求对象：以fs.open( )方法为例，

    fs.open = function(path, flags, mode, callback) {
    
    //...
    
    binding.open(pathModule._makeLong(path),
    
    stringToFlags(flags),
    
    mode,
    
    callback);
    
    };
    

    　　

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

图1.2-调用示意图

整个调用过程：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属性作为方法，然后调用执行，以此达到执行回调函数的目的。

注：IOCP是windows下得异步I/O解决方案

总结

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