作者：爱多
原文：http://cnodejs.org/blog/?p=2426
在高性能的服务器编程中，IO 模型理所当然的是重中之重，需要谨慎选型的，对于网络套接字，我们可以采用epoll 的方式来轮询，尽管epoll也有一些缺陷，但总体来说还是很高效的，尤其来大量套接字的场景下；但对于Regular File 来说，是不能够用采用 poll/epoll 的，即O_NOBLOCK 方式对于传统文件句柄是无效的，也就是说我们的 open ,read, mkdir 之类的Regular File操作必定会导致阻塞.在多线程、多进程模型中，可以选择以同步阻塞的方式来进行IO操作，任务调度由操作系统来保证公平性，但在单进程/线程模型中，以nodejs 为例 ，假如 我们需要在一个用户请求中处理10个文件：
|
1
2
3
4
5
|
function
fun() {
fs.readFileSync();
fs.readFileSync();
…
}
|
这时候进程至少会阻塞10次，而这可能会导致其他的上千个用户请求得不到处理，这当然是不能接受的.
Linux AIO 早就被提上议程，目前比较知名的有 Glibc 的 AIO 与 Kernel Native AIO
Glibc AIO: http://www.ibm.com/developerworks/linux/library/l-async/
Kernel Native AIO: http://lse.sourceforge.net/io/aio.html
我们用Glibc 的AIO 做个小实验，写一个简单的程序：异步方式读取一个文件，并注册异步回调函数：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
int
main()
{
struct
aiocb my_aiocb;
fd = open(
"file.txt"
, O_RDONLY);
...
my_aiocb.aio_sigevent.sigev_notify_function = aio_completion_handler;
…
ret = aio_read(&my_aiocb);
…
write(1,
"caller thread\n"
, 14);
sleep(5);
}
void
aio_completion_handler(sigval_t sigval)
{
write(1,
"callback\n"
, 9);
struct
aiocb *req;
...
req = (
struct
aiocb *)sigval.sival_ptr;
printf
(
"data: %s\n"
,req->aio_buf);
return
;
}
|
我们用 strace 来跟踪调用，得到以下结果 （只保留主要语句）:
23908 open(“file.txt”, O_RDONLY) = 3
23908 clone(…) = 23909
23908 write(1, “caller thread\n”, 14) = 14
23908 nanosleep({5, 0}, <unfinished …>
…
23909 pread(3, “hello, world\n”, 1024, 0) = 13
23909 clone(..)= 23910
23909 futex(0x3d3a4082a4, FUTEX_WAIT_PRIVATE, 1, {0, 999942000} <unfinished …>
…
23910 write(1, “callback\n”, 9) = 9
23910 write(1, “data: hello, world\n”, 19) = 19
23910 write(1, “\n”, 1) = 1
23910 _exit(0) = ?
23909 <… futex resumed> ) = -1 ETIMEDOUT (Connection timed out)
23909 futex(0x3d3a408200, FUTEX_WAKE_PRIVATE, 1) = 0
23909 _exit(0) = ?
23908 <… nanosleep resumed> {5, 0}) = 0
23908 exit_group(0) = ?
在Glibc AIO 的实现中， 用多线程同步来模拟 异步IO ，以上述代码为例，它牵涉了3个线程，
主线程（23908）新建 一个线程（23909）来调用 阻塞的pread函数，当pread返回时，又创建了一个线程（23910）来执行我们预设的异步回调函数， 23909 等待23910结束返回，然后23909也结束执行..
实际上，为了避免线程的频繁创建、销毁，当有多个请求时，Glibc AIO 会使用线程池，但以上原理是不会变的，尤其要注意的是：我们的回调函数是在一个单独线程中执行的.
Glibc AIO 广受非议，存在一些难以忍受的缺陷和bug，饱受诟病，是极不推荐使用的.
详见：http://davmac.org/davpage/linux/async-io.html
在Linux 2.6.22+ 系统上，还有一种 Kernel AIO 的实现，与Glibc 的多线程模拟不同 ，它是真正的做到内核的异步通知，比如在较新版本的Nginx 服务器上，已经添加了AIO方式 的支持.
http://wiki.nginx.org/HttpCoreModule
aio
syntax: aio [on|off|sendfile]
default: off
context: http, server, location
This directive is usable as of Linux kernel 2.6.22. For Linux it is required to use directio, this automatically disables sendfile support.
location /video {
aio on;
directio 512;
output_buffers 1 128k;
}
听起来Kernel Native AIO 几乎提供了近乎完美的异步方式，但如果你对它抱有太高期望的话，你会再一次感到失望.
目前的Kernel AIO 仅支持 O_DIRECT 方式来对磁盘读写，这意味着，你无法利用系统的缓存，同时它要求读写的的大小和偏移要以区块的方式对齐,参考nginx 的作者 Igor Sysoev 的评论： http://forum.nginx.org/read.php?2,113524,113587#msg-113587
nginx supports file AIO only in 0.8.11+, but the file AIO is functional
on FreeBSD only. On Linux AIO is supported by nginx only on kerenl
2.6.22+ (although, CentOS 5.5 has backported the required AIO features).
Anyway, on Linux AIO works only if file offset and size are aligned
to a disk block size (usually 512 bytes) and this data can not be cached
in OS VM cache (Linux AIO requires DIRECTIO that bypass OS VM cache).
I believe a cause of so strange AIO implementaion is that AIO in Linux
was developed mainly for databases by Oracle and IBM.
同时注意上面的橙色字部分，启用AIO 就会关闭sendfile -这是显而易见的，当你用Nginx作为静态服务器，你要么选择以AIO 读取文件到用户缓冲区，然后发送到套接口，要么直接调用sendfile发送到套接口,sendfile 虽然会导致短暂的阻塞，但开启AIO 却无法充分的利用缓存，也丧失了零拷贝的特征 ;当你用Nginx作为动态服务器，比如 fastcgi + php 时，这时php脚本中文件的读写是由php 的 文件接口来操作的，这时候是多进程+同步阻塞模型，和文件异步模式扯不上关系的.
所以现在Linux 上，没有比较完美的异步文件IO 方案，这时候苦逼程序员的价值就充分体现出来了，libev 的作者 Marc Alexander Lehmann 老大就重新实现了一个AIO library ：
http://software.schmorp.de/pkg/libeio.html
其实它还是采用线程池+同步模拟出来的，和Glibc 的 AIO 比较像，用作者的话说，这个库相比与Glibc 的实现，开销更小，bug更少(不然重新造个*还有毛意义呢？反正我是信了) ，不过这个*的代码可读性实在不敢恭维，Marc 老大自己也说了：Currently in BETA! Its code, documentation, integration and portability quality is currently below that of libev, but should soon be ready for use in production environments.
（其实libev代码和文档可读性也不咋地，貌似驱动内核搞多了都这样？）好吧，腹诽完了，我们还是阅读下它的源码 ，来稍微分析一下它的原理:
(这个文章的流程图还是蛮靠谱的:http://cnodejs.org/blog/?p=244 ，此处更详细的补充一下下)
int eio_init (void (*want_poll)(void), void (*done_poll)(void))
初始化时设定两个回调函数，它有两个全局的数据结构 ： req 存放请求队列，res 存放已经完成的队列 当我，当你提交一个异步请求时(eio_submit)，其实是放入req队列中，然后向线程池中处于信号等待的线程发送信号量（如果线程池中没有线程就创建一个），获得信号的线程会执行如下代码：
|
1
2
3
4
5
6
|
ETP_EXECUTE (self, req);
X_LOCK (reslock);
++npending;
if
(!reqq_push (&res_queue, req) && want_poll_cb)
want_poll_cb ();
X_UNLOCK (reslock);
|
ETP_EXECUTE 就是实际的阻塞调用，比如read，open，，sendfile之类的，当函数返回时，表明操作完成，此时加锁方式向完成队列添加一项 ,然后调用 want_pool ,这个函数是我们eio_init时候设置的，然后释放锁。
注意：每次完成任务时，都要调用want_poll ，所以这个函数应该是线程安全且尽量短促，实际上我们为了避免陷入多线程的泥淖，我们往往配合eio使用事件轮询机制，比如：我们创建一对管道，我们把“读”端的管道加入 epoll 监控结构中，want_poll 函向“写”端管道写数入一个字节或字长 ，所以当下次epoll_wait 返回时，我们会执行 “读” 端管道的 回调函数，类似如下：
|
1
2
3
4
|
void r_pipe_cb(){
...
eio_poll();
}
|
在eio_poll 中 有类似以下代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
for
(;;){
X_LOCK (reslock);
req = reqq_shift (&res_queue);
if
(req){
if
(!res_queue.size && done_poll_cb)
done_poll_cb ();
}
X_UNLOCK (reslock);
res = ETP_FINISH (req);
...
if
(empty)
break
;
}
|
eio_poll 函数就是从完成队列res 依次shift ，依次执行我们的回调函数(ETP_FINISH 就是执行用户回调)，在取出完成队列的最后一项但还没有执行用户回调之前，调用我们设定的done_poll ,对res队列的操作当然也是加锁的，注意此时我们自定义的异步回调函数是在我们的主线程中执行的！这才是我们的最终目的！
在eio 线程池中，默认最多4个线程，在高性能的程序中，过多的进程/线程往往也是一个瓶颈，
寄存器的进出栈还是其次，进程虚存地址切换、各级cache 的miss ，这才是最昂贵的，所以，最理想的情形就是：有几个cpu ，就有同样数目的active 线程/进程，但因为io线程往往会陷入sleep模式，所以，还是需要额外的待切换的线程的，作为经验法则，线程池的数量最好是cpu 的数目 X 2（参见windows 核心编程 IOCP卷）.
libeio 虽不完美，但目前还是将就着用用吧 …