小编给大家分享一下Nodejs中异步I/O的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！

创新互联-专业网站定制、快速模板网站建设、高性价比荔浦网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式荔浦网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖荔浦地区。费用合理售后完善，10余年实体公司更值得信赖。

“异步”这个名词其实在Node之前就已经诞生了。但是在绝大多数高级编程语言中，异步并不多见。在众多高级语言或运行平台中，将异步作为主要编程方式和设计理念的，Node是首个。【相关推荐：《nodejs 教程》】

异步I/O、事件驱动和单线程构成了Node的基调，而Nginx与Node的事件驱动、异步I/O设计理念比较相近。Nginx采用纯C编写，性能表现非常优异，具备面向客户端管理连接的强大能力，但是它的背后依然受限于各种同步方式的编程语言。但Node是全方位的，既可以作为服务器端去处理客户端带来的大量并发请求，也能作为客户端向网络中的各个应用进行并发请求。

为什么要异步I/O

---

为什么异步I/O在Node中如此重要，这是因为Node面向网络设计，在跨网络的结构下，并发已经是现代编程中的标准配备了。

用户体验

《高性能JavaScript》中提到过，如果脚本的执行时间超过100毫秒，用户就会感到页面卡顿，以为页面停止响应。而在B/S模型中，网络速度的限制给网页的实时体验造成很大的麻烦。

如果网页临时需要获取一个资源，通过同步的方式获取，那么JavaScript则需要等待资源完全从服务器端获取后才能继续执行，这期间UI停顿，不响应用户的交互行为。这样用户体验将会极差。而采用异步请求，在下载资源期间，JavaScript和UI的执行都不会处于等待状态，可以继续响应用户的交互行为。

同理，前端通过异步可以消除掉UI阻塞现象，但是前端获取资源的速度也取决于后端的响应速度。假如一个资源来自于两个不同位置的数据的返回，第一个资源消耗M毫秒，第二个资源消耗N毫秒。如果采用同步的方式，获取两个资源消耗的的时间为M+N毫秒。而采用异步的方式，第一个资源的获取并不会阻塞第二个资源的获取，消耗的时间为max(M,N)。

随着网站或应用不断膨胀，M与N的值会线性增长，那么异步的性能将比同步更加优越。

资源分配

假设业务场景中有一组互不相关的任务需要完成，有以下两种主流的方法：

• 单线程串行一次执行

• 多线程并行完成

如果创建多线程的开销小于并行执行，那么多线程是首选的，但是多线程在创建线程和执行期线程上下文切换的开销较大，而且多线程编程经常面临锁、状态同步等问题。

单线程顺序执行任务的缺点在于性能，任意一个略慢的任务都会导致后续执行代码被阻塞。在计算机资源中，通常I/O与CPU计算之间是可以并行执行的，但是同步的编程模型导致I/O的进行会让后续任务等待，造成资源不能被更好的利用。

Node利用单线程，远离多线程死锁、状态同步等问题；利用异步I/O，让单线程远离阻塞，更好的利用CPU。

异步I/O实现

---

异步I/O在Node中应用最为广泛，但是它并不是Node的原创。

异步I/O与非阻塞I/O

对于计算机内核I/O而言，异步/同步和阻塞/非阻塞是两码事。

操作系统对于I/O只有两种方式：阻塞和非阻塞。在调用阻塞I/O时，应用程序需要等待I/O完成才返回结果。

阻塞I/O的一个特点是调用之后一定要等到系统内核层面完成所有操作之后，调用才结束。阻塞I/O造成CPU等待I/O，浪费等待时间，CPU的处理能力不能得到充分利用。

为了提高性能，内核提供了非阻塞I/O。非阻塞I/O跟阻塞I/O的差别为调用之后会立即返回，非阻塞I/O返回之后，CPU的时间片可以用来处理其他事物，此时提升性能是明显的，但是由于完成的I/O并没有完成，立即返回的并不是业务层期望的数据，而仅仅是当前的调用状态。

为了获取完整的数据，应用程序需要重复调用I/O操作来确认是否完成。这种重复调用判断操作是否完成的技术叫做轮询。

现存的轮询技术主要有read、select、poll、epoll和kqueue。这里只讲一下epoll的轮询原理。

epoll是Linux下效率最高的I/O事件通知机制，在进入轮询的时候，如果没有检查到I/O事件，将会进行休眠，直到事件发生将它唤醒。它是真实利用了事件的通知、执行回调的方式，而不是遍历查询，所以不会浪费CPU，执行效率较高。

轮询技术满足了非阻塞I/O确保获取完整数据的需求，但是对于程序而言，它仍然算是一种同步，因为应用程序仍然需要等待I/O完全返回，依旧花费了很多时间等待。等待期间，CPU要么用于遍历文件描述符，要么用于休眠等待时间发生。

现实的异步I/O

通过让部分线程进行阻塞I/O或者非阻塞I/O加轮询技术来完成数据获取，让一个线程进行计算处理，通过线程之间的通信将I/O得到的数据进行传递，这就轻松实现了异步I/O（虽然这是模拟的）

但是最初，Node在*nix 平台下采用了libeio配合libev实现I/O部分，实现了异步I/O。在Node v0.9.3中，自行实现了线程池来完成异步I/O。

而Windows下的IOCP在某种程度上提供了黎翔的异步I/O：调用异步方法，等待I/O完成之后的通知，执行回调，用户无需考虑轮询。但是它的内部其实依然是线程池原理，不同之处在于这些线程池有系统内核接手管理。

由于Windows平台和*nix平台的差异，Node提供了libuv作为抽象封装层，使得所有平台兼容性的判断都由这一层来完成，并保证上层的Node与下层的自定义线程池及IOCP之间个字独立。

我们时常提到Node是单线程的，这里的单线程仅仅只是JavaScript执行在单线程中。在Node中，无论是*nix还是Windows平台，内部完成I/O任务的另有线程池。

Node的异步I/O

---

完成整个异步I/O环节的有事件循环、观察者和请求对象等。

事件循环

事件循环是Node自身的执行模型，正式它使得回调函数十分普遍。

在进程启动时，Node便会创建一个类似于while(true)的循环，每执行一次循环体的过程我们称为Tick。每个Tick的过程就是查看是否有事件待处理，如果有就取出事件及其相关的回调函数。如果存在关联的回调函数，就执行他们。然后进入下个循环，如果不再有事件处理，就退出进程。

观察者

每个事件循环中有一个或者多个观察者，而判断是否有事件要处理的过程就是向这些观察者询问是否有要处理的事件。

在Node中，事件主要来源于网络请求、文件I/O等，这些时间对应的观察者有文件I/O观察者、网络I/O观察者等。观察者将事件进行了分类。

事件循环是一个典型的生产者/消费者模型。异步I/O、网络请求等则是事件的生产者，不断为Node提供不同类型的事件，这些事件被传递到对应的观察者那里，事件循环则从观察者那里取出事件并处理。

请求对象

对于Node的异步I/O调用而言，回调函数不由开发者来调用。从JavaScript发起调用到内核执行完I/O操作的过渡过程中，存在一种产物，叫做请求对象

下面用fs.open()方法作为一个小小的例子。

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

fs.open()的作用是根据指定路径和参数去打开一个文件，从而得到一个文件描述符，这是后续所有I/O操作的初试操作。JavaScript层面的代码通过调用C++核心模块进行下层的操作。

从事JavaScript调用Node的核心模块，核心模块调用C++模块，内建模块通过libuv进行系统调用，这里是Node里经典的调用方式。这里libuv作为封装层，有两个平台的实现，实质上是调用了uv_fs_open()方法。在uv_fs_open()的调用过程中，将从JavaScript层传入的参数和当前方法都封装在一个请求对象中，回调函数则被设置在这个对象的属性上。对象包装完毕后，将对象推入线程池等待执行。

至此，JavaScript调用立即返回，由JavaScript层面发起的异步调用的第一阶段就此结束。JavaScript线程可以继续执行当前任务的后续操作。

请求对象是异步I/O过程中的重要中间产物，所有的状态都保存在这个对象中，包括送入线程池等待执行以及I/O操作完毕后的回调处理。

执行回调

组装好请求对象、送入I/O线程池等待执行，只是完成一部I/O的第一部分，回调通知是第二部分。

线程池中的I/O操作调用完毕之后，会将获取的结果存储在req->result属性上，然后调用PostQueueCompletionStatus()通知IOCP，告知当前对象操作已经完成。

至此，整个异步I/O的流程完全结束。

事件循环、观察者、请求对象、I/O线程池这四者共同构成了Node异步I/O模型的基本要素。

以上是“Nodejs中异步I/O的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！

当前名称：Nodejs中异步I/O的示例分析
地址分享：http://azwzsj.com/article/ggiopp.html