为何不选择lunix AIO
对于块设备而言，linux可以使用同步IO、POSIX IO、linux AIO、io-uring，前俩者是linux的同步IO接口，后者是linux内核提供的异步io接口，linux AIO只支持直接IO，未来趋势是io-uring。网络IO多用select/epoll，将其封装使用起来像异步IO，同步与异步区别在于是否堵塞线程，磁盘性能，同步异步IO都可以压榨完，对于同步异步的选择应该看每种IO方式的IO链路，以及对数据的拷贝次数，并结合自己场景和需求去分析，可接受应该在应用层改变。
Lunix AIO是否不成熟
glibc 的AIO，采用的是POSIX接口，无论有无bug、调试难度，API中无connect、accept、send、recv，存在的都是文件IO的使用者，数据库开发者，MySQL 5.6 innodb在lunix下已经使用native AIO实现了，innodb-use-native-aio变量默认开启。
以nginx 为例，说明nginx仅支持在读取文件时使用AIO，写入文件时往往是写入内存就立刻返回，AIO不支持缓存操作，即使需要操作的文件在linux文件缓存中存在，也不会通过操作缓存中的文件块来代替实际对磁盘的操作，会降低实际处理能力的性能。
- 仅支持direct IO 只能使用O-DIRECT，不能借助文件缓存来缓存当前的IO请求，还存在size对齐
- 仍然可能被阻塞 在系统层上events条件不成立，会进入睡眠
- 拷贝开销大 大量小io场景下 拷贝影响比较大
- API 不友好 submit wait-for-completion
- 系统调用开销大
io-uring
- 易用，对其中常用的功能进行了一次封装，提供了简单易用的接口liburing
- 可扩展，支持网络I/O等非块设备
- 高效，减少了每次调度要传的参数大小，减少系统调用次数，通过一次系统调用提交多个IO请求的方式
- 可伸缩，用户态和核心态都支持轮询，可以在不调用syscall的情况下直接处理IO请求
原理与结构
- 原理是让用户态进程与内核通过一个共享内存的无锁环形队列进行高效交互
- 共享内存，减少系统调用过程中的参数内存拷贝，将内核态地址空间映射到用户态的方式，通过用户态对io-uring fd进行mmap，可以获得io-uring相关的两个内核队列（IO请求，IO完成时间）的用户态地址，用户态程序可以直接操作俩个队列向内核发送IO请求，接收完内核完成IO事件通知，
- 无锁环形队列，单生产者与单消费者的无锁队列，来实现用户态程序与内核对共享内存的高效并发访问，生产者只修改队尾指针，消费者只修改队头指针，不会相互阻塞。
- 内存屏障与保序，保证内存操作顺序和一致性，1 修改队列状态时，保证对队列元素的写入已完成，编译器可以实现，防止编译器将修改队列的指令放到队列元素写入完成之前，2 读取队列状态时，需要获取最新写入和修改的值，保证缓存一致性刷新
轮询模式
- io-uring 提供io-uring-enter系统调用接口，用于通知内核IO请求的产生以及等待内核完成的请求，仍然需要反复调用系统调用，进行上下文切换。ioring-setup- iopoll 和 ioring-setup-sqpoll 同时设置，内核线程会同时对io-uring的队列和设备驱动队列做轮询，对请求队列、完成事件队列、设备驱动队列全部使用轮询模式，达到最优的IO性能，会产生更多的CPU开销。
调用接口
- io-uring-setup 创建接口
- io-uring-enter 通知内核有IO请求待处理，并根据参数等待请求完成
- io-uring-register 注册fd和buffer为常用对象，避免内核反复拷贝
具体实现
- 让用户态程序与内核共享内存，并发修改同一数据结构，是一种危险行为，用户态异常操作内核处理逻辑，可能让用户态程序破坏内核机制
- uring 的head/tail 指针错误，会导致内核处理没有设置过的sqe，sqe是内核预分配过的内存，不会造成内核访问非法内存地址
- uring entries被错误修改，可能会造成内核异常，在创建io-uring时就已经确定，可以为每个io-uring单独保存一份用于实际逻辑处理逻辑，而不使用共享内存中的部分。
- io-uring提供了复杂而强大的异步IO接口，又实现了liburing来屏蔽高级特性带来的复杂度，通过共享内存与无锁队列与内核进行高性能交互，而避免大量的syscall嗲来的性能开销和限制，可用于加速实时性要求不高的系统调用。
