首先声明一下epoll+nonblock从宏观角度可以叫做全异步,但从微观的角度来看还是同步的IO。只是在数据到达后得到系统通知,然后同步执行recv取回数据,没有iowait。

真正的异步IO(下面会统一叫做AIO)应该像Windows IOCP一样,传入文件句柄,缓存区,尺寸等参数和一个函数指针,当操作系统真正完成了IO操作,再执行对应的函数。

实际上对于socket来说,epoll已经是最高效的模型了,虽然比AIO多一次recv系统调用,但总体来看没有任何IO等待,效率很高。而且epoll是天然的reactor模型,程序实现更容易。AIO如windows的IOCP,是异步回调的方式,开发难度很高。

为什么还是需要AIO呢,原因是文件句柄跟socket完全不同,它总是处于可读状态。不能使用epoll+nonblock来实现异步化。如果在一个epoll的全异步Server中,要读写文件那必须得使用AIO。下面说下AIO的几种实现方案。

gcc AIO
gcc遵循posix标准实现了AIO。头文件为,支持FreeBSD/Linux。是通过阻塞IO+线程池来实现的。主要的几个函数是aio_read/aio_write/aio_return。

优点:支持平台多,兼容性好,无需依赖第三方库,阻塞IO可以利用到操作系统的PageCache。

缺点:据说有一些bug和陷阱,一直未解决。不过这个都是网上文章中讲的,gcc发展这么多年,不至于还有遗留bug吧。这里有待测试。

Linux Native Aio
由操作系统内核提供的AIO,头文件为<linux/aio_abi.h>。Native Aio是真正的AIO,完全非阻塞异步的,而不是用阻塞IO和线程池模拟。主要的几个系统调用为io_submit/io_setup/io_getevents。

优点:由操作系统提供,读写操作可以直接投递到硬件,不会浪费CPU。

缺点:仅支持Linux,必须使用DirectIO,所以无法利用到操作系统的PageCache。对于写文件来说native aio的作用不大,应为本身写文件就是先写到PageCache上,直接返回,没有IO等待。

Libeio
libev的作者开发的AIO实现,与gcc aio类似也是使用阻塞IO+线程池实现的。优点与缺点参见上面。它与gcc aio的不同之处,代码更简洁,所以bug少更安全稳定。但这是一个第三方库,你的代码需要依赖libeio。

总结
如果你的程序读写的文件很大,随即性强,这样PageCache的命中率低,那可以选择Native AIO,降低CPU使用率。

如果读写的文件很小,而且是固定的一些文件,这样PageCache的命中率高,可以选择gcc aio或者libeio。

异步AIO的研究
标签: