首先声明一下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。
