nodejs异步IO的实现

红薯 发布于 2011/03/20 04:18
阅读 2K+
收藏 5
本文为原创文章,出自http://cnodejs.org,转载请注明出处和作者
作者:changlin
原文:http://cnodejs.org/blog/?p=244

nodejs的核心之一就是非阻塞的异步IO,于是想知道它是怎么实现的,挖了下nodejs源码,找到些答案,在此跟大家分享下。首先,我用了一段js代码test-fs-read.js做测试,代码如下:

var path = require('path'),
fs = require('fs'),
filepath = path.join(__dirname, 'experiment.log'),
fd = fs.openSync(filepath, 'r');
 
fs.read(fd, 12*1024*1024, 0, 'utf-8', function(err, str, bytesRead) {
    console.log('[main thread] execute read callback');
});
console.log('[main thread] execute operation after read');

 

 

这段代码的异步IO操作就在fs.read的调用上,读取的experiment.log是一个12M的文本文件,所谓的异步,大家大概能想得到运行时会先打印
[main thread] execute operation after read
然后打印回调函数中的
[main thread] execute read callback

但大家也许还听说过,nodejs是单线程的,那又是怎么实现异步IO的呢?读文件操作是在哪里执行的呢?读完又是怎么调用回调函数的呢?猜想读文 件可能是在另一个线程中完成的,读完后通过事件通知nodejs执行回调。为了一探究竟,debug了一把nodejs和libeio源码,重新编译后, 运行测试代码node test-fs-read.js,输出如下:

可以看到,nodejs的IO操作是通过调用libeio库完成的,debug从fs.read开始,js代码经过v8编译后,fs.read会调用node_file.cc中的Read方法,测试代码的运行经历了以下步骤:

1 node_file.cc中的Read方法调用libeio(eio.c)的eio_read, read请求被放入请求队列req_queue中。

2 主线程创建了1个eio线程,此时主线程的read调用返回。

3 eio线程从req_queue中取出1个请求,开始执行read IO

4 主线程继续执行read调用后的其它操作。

5 主线程poll eio,从响应队列res_queue取已经完成的请求,此时res_queue为空,主线程stop poll

6 eio线程完成了read IO,read请求被放入响应队列res_queue中,并且向主线程发送libev事件want_poll(通过主线程初始化eio时提供的回调函数)。

7 eio线程从req_queue中取下一个请求,此时已经没有请求。

8 主线程响应want_poll事件,从res_queue中取出1个请求,取出请求后res_queue变为空,主线程发送done_poll事件。

9 主线程执行请求的callback函数。

还需要说明的是,当同时有多个IO请求时,主线程会创建多个eio线程,以提高IO请求的处理速度。
为了更清晰的看到nodejs的IO执行过程,图示如下,序号仅用来标示流程,与上述步骤序号并无对应关系。

最后总结几条,不当之处还请大家指正。

1 nodejs通过libev事件得到IO执行状态,而不是轮询,提高了CPU利用率。

2 虽然nodejs是单线程的,但它的IO操作是多线程的,多个IO请求会创建多个libeio线程(最多4个),使通常情况的IO操作性能得到提高。

3 但是当IO操作情况比较复杂的时候,有可能造成线程竞争状态,导致IO性能降低;而且libeio最多创建4个线程,当同时有大量IO请求时,实际性能有 待测量。另外,由于每个IO请求对应一个libeio的数据结构,当同时有大量IO操作驻留在系统中时候,会增加内存开销。

4 Libeio为了实现异步IO功能,带来了额外的管理,当IO数据量比较小的时候,整体性能不一定比同步IO好。

加载中
返回顶部
顶部