首页 > 代码库 > Node.js异步IO
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
- 假设业务线上有一组互不相关的任务需要完成，现行的主流方法有以下两种：
异步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操作的初始操作。
- 请求对象：以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属性作为方法，然后调用执行，以此达到执行回调函数的目的。
注：IOCP是windows下得异步I/O解决方案
总结
JavaScript是单线程的，但Node本身其实是多线程的，除了用户代码无法并行执行外，所有的I/O请求是可以并行执行的。事件循环是Node异步I/O实现的核心，Node通过事件驱动的方式处理请求，使得其无须为每个请求创建额外的线程，省掉了创建和销毁线程的开销。同时也因为线程数较少，不受线程上下文切换的影响，维持了Node的高性能。
Node.js异步IO