回忆一下
我们都知道Linux的IO模型有阻塞、非阻塞、SIGIO、多路复用(select，epoll)、AIO（异步I/O）等。
数据库可能比较倾向于使用AIO。从时序上面来讲,AIO是用户应用发起IO请求io_submit()后，它就不需要去等待，让后台给它搞定读写。之后本线程或者其他线程就可以通过io_getevents()去同步I/O的结果。
这样的AIO有一个极大的好处在于，IO不会阻塞住CPU的行为，有利于充分利用硬件的资源，有利于让CPU、IO都parallel起来 。当然，同样的动作，似乎用epoll()、SIGIO也可以呈现出来。尤其是epoll()，几乎是C10K问题解决方案在Linux的代名词。epoll_wait()先等待IO请求的read、write可以发生，而后再根据返回的事件发起读写请求：
事件驱动模型libevent等，看起来是事件到来，callback被执行的Reactor模式：
但是其底层其实也是靠epoll()来实现，这个我们透过strace就可以看出。请见我的3分钟小电影：
大不一样
epoll()本质上其实还是先等待IO的读写可以发生，而后再以Linux常规read()、write() API去发起IO请求。而AIO则是不管三七二十一，直接发IO请求，但是并不等待这个请求的结束，让Linux后台自己去完成读写。我们来看一个典型的AIO编程案例：
它是通过io_submit()把IO请求发出去之后，它并不需要等IO的结束。后面用io_getevents()去同步。上面的代码中，io_getevents()的代码与io_submit()的代码摆在一起，但是其实它们并不需要一定是同一个线程。
AIO和传统epoll()的本质区别是，epoll()等方式，它只是一个事件获取机制，获取事件后，之后的read(), write()还是要走Linux的传统路线，经过Linux内核本身的各个层次（如page cache，IO调度等）。而AIO是骨子里面，自己就是一个IO的方式，最终没有经过传统的Linux read(),write()这种"all is file"的类VFS接口。Linux native的AIO本身call的函数，本身就是系统调用。strace执行AIO动作的进程得到的直接就是类似如下的结果：
strace ./aio....
...
io_setup(128, {3077799936}) = 0
io_submit(3077799936, 1, 0xbfa5e730) = 1
io_getevents(-1217167360, 1, 1, {...}NULL) = 1
在ARM Linux的系统调用表里也可以看出：
故而，AIO可以更多地把机会交给用户空间，让用户空间根据自身的IO特点来为自己量身定制IO的行为。AIO一般也直接结合DIO（direct IO）来使用，进一步绕开内核本身的IO调度和cache机制。
我中意你
那么AIO有什么可能的优势被数据库所青睐呢？
1. 透过AIO，可以屏蔽掉Linux内核底层的page cache。而制定application-level的cache机制。
我们都知道，Linux会针对每个文件对应的inode，创立一个address_space，并以Radix树来组织它的page cache命中情况，page的替换算法，整体是LRU，预测页面本身的活跃度。这个策略，固然非常符合局部性原理(Locality)，但是不能针对用户程序本身的特征，进行用户级的cache。
2.透过AIO（尤其是结合DIO），可以一定程度上，进行用户级别的IO scheduling。采用AIO，用户可以控制发送给内核的IO请求，从而控制谁比谁更重要。内核固然有它的IO调度算法，但是它是比较general的。
3. 透过AIO，可以进行用户级别的read-ahead和write-behind控制。
我们都知道，Linux内核本身会根据用户的读请求，去预测后续的读，从而在后续的读还没有发起的情况下，就提前预读。详见：《宋宝华： 文件读写（BIO）波澜壮阔的一生》，但是这种预读的page，并不一定是上层应用想要的page。而内核的write-behind机制，也可能导致内核累积到很多dirty数据后，出现写磁盘的突发性洪泛。现在AIO机制，我们把这些都交给用户。
4. 透过AIO，不阻塞地在前台线程，直接dispatch IO请求，带来很好的
scalability。在InnoDB里面，可以透过 innodb_use_native_aio来配置使用同步的IO还是AIO，而且它有一番对比，值得细细地品读。同步IO的时候，query threads是将IO请求放入queue，由InnoDB后台线程的每个线程处理一个IO请求。而AIO的时候，query threads直接发IO请求。
With synchronous I/O, query threads queue I/O requests, and InnoDB background threads retrieve the queued requests one at a time, issuing a synchronous I/O call for each. When an I/O request is completed and the I/O call returns, the InnoDB background thread that is handling the request calls an I/O completion routine and returns to process the next request. The number of requests that can be processed in parallel is n, where n is the number of InnoDB background threads. The number of InnoDB background threads is controlled by innodb_read_io_threads and innodb_write_io_threads.
With native AIO, query threads dispatch I/O requests directly to the operating system, thereby removing the limit imposed by the number of background threads. InnoDB background threads wait for I/O events to signal completed requests. When a request is completed, a background thread calls an I/O completion routine and resumes waiting for I/O events.
参考阅读
https://dev.mysql.com/doc/refman/8.0/en/innodb-linux-native-aio.html
https://www.scylladb.com/2017/10/05/io-access-methods-scylla/
https://blog.pythian.com/importance-oracle-database-related-kernel-parameters-aio-max-nr-bonus-track/
(打赏的童鞋请在打赏的时候留言让在下知道是谁并感恩)
查看"Linux阅码场"精华技术文章请移步:
扫描二维码关注"Linux阅码场"