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密集、高并发的应用场景。

 

 

原文地址:https://www.cnblogs.com/tangzhirong/p/6910776.html