io_uring：Linux 异步 I/O 的范式转变与深度实战

Linux 内核 5.1 引入了一个改变游戏规则的子系统 —— io_uring。它不是对老旧 Linux AIO 的修修补补，而是一次从零设计的异步 I/O 接口革新。本文将深入剖析 io_uring 的设计哲学、核心架构、实战用法以及生产环境中的最佳实践。

为什么需要 io_uring？

在 io_uring 之前，Linux 的异步 I/O 方案经历了一段坎坷的演进历程。

POSIX AIO（aio_read/aio_write）是最初的标准，但存在严重限制：仅支持 O_DIRECT 模式的文件 I/O，不支持网络 I/O，且实际实现往往是伪异步（在 glibc 中用线程池模拟）。

Linux Native AIO（io_submit）看起来更底层，但同样问题重重：

• 仅 O_DIRECT 路径才是真异步，否则可能阻塞
• 每次操作需要两次系统调用（io_submit + io_getevents）
• 缓冲区对齐要求苛刻（必须 512 字节对齐）
• 不支持套接字，生态系统支持极差

这一切的根源在于：共享状态的异步模型与 Linux 的系统调用模型根本不匹配。io_uring 的作者 Jens Axboe（也是内核块 I/O 子系统的维护者）从中汲取教训，提出了一个全新设计。

核心架构：基于共享内存的双队列模型

io_uring 的核心设计极其优雅 —— 用户态和内核态通过共享内存通信，实现零系统调用的 I/O 提交与收割。

整体架构如下：

┌─────────────────────────────────────────────────────────────┐
│                        用户态进程                             │
│  ┌──────────────┐          ┌──────────────────────────────┐ │
│  │  Submission   │          │    Completion Queue (CQ)     │ │
│  │  Queue (SQ)   │          │  ┌────┬────┬────┬────┬────┐  │ │
│  │  ┌──┬──┬──┬──┐│          │  │ CQE│ CQE│ CQE│ CQE│ CQE│  │ │
│  │  │SQ│SQ│SQ│SQ││          │  └────┴────┴────┴────┴────┘  │ │
│  │  │E1│E2│E3│E4││          │          ↓                   │ │
│  │  └──┴──┴──┴──┘│          │    用户态读取完成事件          │ │
│  └───────┬───────┘          └──────────────────────────────┘ │
│          │ 写入门铃                                                │
├──────────┼───────────────────────────────────────────────────┤
│          │ 内核态                                                │
│          ▼                                                        │
│  ┌──────────────────────────────┐                              │
│  │       io_uring 实例           │                              │
│  │  ┌──────────┐ ┌──────────┐  │                              │
│  │  │  工作线程 │ │  轮询线程 │  │                              │
│  │  │ (io-wq)  │ │ (SQPOLL) │  │                              │
│  │  └──────────┘ └──────────┘  │                              │
│  └──────────────────────────────┘                              │
└─────────────────────────────────────────────────────────────┘

提交队列 (SQ) 与完成队列 (CQ)

io_uring 维护两个环形缓冲区：

Submission Queue (SQ) - 提交队列：用户态写入 SQE（Submission Queue Entry），每个 SQE 描述一个待执行的 I/O 操作（读、写、connect、accept 等）。写入完成后通过一次 io_uring_enter 系统调用通知内核。

Completion Queue (CQ) - 完成队列：内核完成操作后将 CQE（Completion Queue Entry）写入 CQ。用户态可以直接从 CQ 读取完成事件，无需任何系统调用。

这两个队列都是无锁的单生产者单消费者环形缓冲区，通过头尾指针管理。这种设计使得在开启 IORING_SETUP_SQPOLL（内核轮询模式）后，整个 I/O 生命周期完全可以避免系统调用，实现真正的零开销异步。

基本操作模式

用户通过 io_uring_setup 创建实例，获取一个文件描述符和 mmap 映射的两块共享内存区域（SQ 和 CQ）。对于高频场景，还可以预分配一组不透明的文件索引（Fixed Files）和预注册缓冲区（Fixed Buffers），进一步减少 per-IO 开销。

与 传统方案的性能对比

让我们通过一个简单的测试来感受 io_uring 的优势。任务是：对同一个文件进行 100 次 4KB 随机读取。

方案 1：传统 pread 同步 I/O

每次读取触发一次 pread 系统调用，共 100 次上下文切换。在 NVMe SSD 上，纯系统调用开销就能消耗数百微秒。

方案 2：Linux AIO (io_submit)

每次 submit + getevents 需要 2 次系统调用，且受 O_DIRECT 对齐限制，实际使用中经常回退同步。

方案 3：io_uring 轮询模式

在 URING_SETUP_SQPOLL 模式下，提交侧零 syscalls，完成侧从共享内存读取 CQ，同样是零 syscalls。当使用IORING_SETUP_IOPOLL时，还可以在块设备层做轮询，规避中断延迟。

实测数据（Jens Axboe 官方 benchmark，SATA SSD）：

可以看到，io_uring 不仅吞吐量大幅提升，更关键的是大幅降低了每操作的系统调用次数，在高 IOPS 场景下这直接转化为延迟优势和 CPU 效率提升。

核心 API 深度解析

用户态一般不直接使用原始系统调用，而是通过 liburing 库，它提供了更友好的封装。

初始化与销毁

#include <liburing.h>

struct io_uring ring;

// 初始化一个 1024 深度的 io_uring 实例
int ret = io_uring_queue_init(1024, &ring, 0);
if (ret < 0) {
    fprintf(stderr, "queue_init: %s\n", strerror(-ret));
    return 1;
}

// 使用完毕
io_uring_queue_exit(&ring);

提交一次读操作

// 1. 获取一个 SQE
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
if (!sqe) {
    // 提交队列已满，先收割完成事件
    io_uring_submit(&ring);
    sqe = io_uring_get_sqe(&ring);
}

// 2. 准备读操作：从 fd 读 4096 字节到 buf，偏移 0
io_uring_prep_read(sqe, fd, buf, 4096, 0);

// 3. 设置 user_data 用于完成事件识别
io_uring_sqe_set_data(sqe, (void*)my_request_ctx);

// 4. 提交所有 SQE 到内核（一次 io_uring_enter）
io_uring_submit(&ring);

收割完成事件

struct io_uring_cqe *cqe;

// 阻塞等待至少一个完成事件
int ret = io_uring_wait_cqe(&ring, &cqe);
if (ret < 0) {
    fprintf(stderr, "wait_cqe: %s\n", strerror(-ret));
    return 1;
}

// 读取结果
if (cqe->res < 0) {
    fprintf(stderr, "I/O error: %s\n", strerror(-cqe->res));
} else {
    printf("Read %d bytes\n", cqe->res);
}

// 上下文数据
my_request_ctx = io_uring_cqe_get_data(cqe);

// 标记已消费，io_uring 才能复用槽位
io_uring_cq_advance(&ring, 1);

可以看到，一个完整的异步操作链条非常清晰：get_sqe -> prep_op -> submit -> wait_cqe -> process -> advance。

链接操作：保证执行顺序

io_uring 支持通过 IOSQE_IO_LINK 标志链接多个操作，内核保证它们按顺序执行，前一个失败则跳过后续：

struct io_uring_sqe *sqe1 = io_uring_get_sqe(&ring);
io_uring_prep_write(sqe1, fd, header_buf, header_len, 0);
sqe1->flags |= IOSQE_IO_LINK;  // 链接到下一个

struct io_uring_sqe *sqe2 = io_uring_get_sqe(&ring);
io_uring_prep_write(sqe2, fd, data_buf, data_len, header_len);
sqe2->flags |= IOSQE_IO_LINK;

struct io_uring_sqe *sqe3 = io_uring_sqe(&ring);
io_uring_prep_fsync(sqe3, fd);  // 最后执行 fsync

io_uring_submit(&ring);

这非常适合日志系统的双写缓冲（先写 WAL 再写数据最后 fsync），减少了应用程序层的序列化代码。

高级特性：性能极致化

1. 缓冲区注册 (Registered Buffles)

O_DIRECT 模式下，每次 I/O 的缓冲区在内核中需要 pin 住内存（get_user_pages）。对于高频操作，pin/unpin 的开销变得显著。io_uring 允许预注册一块内存区域，内核预先建立映射，后续 O_DIRECT I/O 直接使用：

// 注册 16MB 缓冲区
struct iovec iov = {
    .iov_base = buf,
    .iov_len = 16 * 1024 * 1024
};
int ret = io_uring_register_buffers(&ring, &iov, 1);

// 后续使用 registered buffer 读写
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_read_fixed(sqe, fd, buf, len, offset, buf_index);

搭配固定缓冲区，io_uring 还能对 buffer 做更激进的优化 —— 预读和缓存，避免每请求的 map/unmap。

2. 文件注册 (Fixed Files)

每次 open/close 伴随 fd 更新。对于固定工作集中需要用到的文件，可以注册到 io_uring 的 fd table，后续操作直接用索引（0 ~ NR_OPEN-1），避免每次 fd 的引用计数变动。

int fds[] = { fd1, fd2 };
int ret = io_uring_register_files(&ring, fds, 2);

struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
sqe->fd = 0;          // 使用注册 fd 索引 0
sqe->flags |= IOSQE_FIXED_FILE;  // 标记为固定文件
io_uring_prep_read(sqe, fd, buf, len, 0);

3. 内核轮询 (SQPOLL)

默认模式下，用户态通过 io_uring_enter 告知内核有新请求。开启 IORING_SETUP_SQPOLL 后，io_uring 会创建一个内核线程，周期性地检查 SQ 是否有新条目，并主动处理。这意味着：

• 用户态不再需要 io_uring_enter 系统调用
• 对于高速 I/O 场景，每百万 I/O 操作节省数千万次系统调用

代价是 CPU 开销 —— 轮询线程会占用一个核心。在高 IOPS 的 NVMe 或网络场景下，这个代价值得支付。

struct io_uring_params params = { };
params.flags = IORING_SETUP_SQPOLL;
params.sq_thread_idle = 2000;  // 空闲 2s 后线程休眠

int ret = io_uring_queue_init_params(1024, &ring, &params);

4. IOPOLL 模式

与 NVMe 的 poll 队列搭配，在 IORING_SETUP_IOPOLL 模式下，io_uring 绕过内核的块层中断处理，直接轮询完成队列。对于 NVMe 设备，这意味着延迟进一步降低。

params.flags = IORING_SETUP_IOPOLL;
io_uring_queue_init_params(QUEUE_DEPTH, &ring, &params);

实战：构建高性能网络服务器

io_uring 不止于磁盘文件。从 5.5 内核开始，io_uring 支持 accept/connect/send/recv 等网络操作，这让构建统一的网络+磁盘异步框架成为可能 —— 这是 libuv/io_uring 之前的任何方案做不到的。

下面是一个简单的 TCP echo server 的 io_uring 版本骨架，展示如何用 io_uring 统一处理 accept 和 recv/send：

#include <liburing.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>

#define BUF_SIZE 2048
#define MAX_CONNECTIONS 4096

struct conn_info {
    int fd;
    unsigned int buf_size;
};

enum {
    OP_READ = 1,
    OP_WRITE,
    OP_ACCEPT,
};

struct conn_buf {
    char buf[BUF_SIZE];
};

static struct conn_buf conn_array[MAX_CONNECTIONS];

// 非阻塞 accept
static int setup_listening_socket(int port) {
    int sock = socket(AF_INET, SOCK_STREAM, 0);
    int optval = 1;
    setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval));
    struct sockaddr_in srv_addr = {
        .sin_family = AF_INET,
        .sin_port = htons(port),
        .sin_addr.s_addr = INADDR_ANY
    };
    bind(sock, (struct sockaddr*)&srv_addr, sizeof(srv_addr));
    listen(sock, SOMAXCONN);
    return sock;
}

// 提交一个 accept 请求
static void submit_accept(struct io_uring *ring, int server_fd) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    struct conn_info *ci = malloc(sizeof(struct conn_info));
    ci->fd = server_fd;
    ci->buf_size = BUF_SIZE;
    
    io_uring_prep_accept(sqe, server_fd, NULL, NULL, SOCK_NONBLOCK);
    io_uring_sqe_set_data(sqe, ci);
}

// 提交 recv
static void submit_recv(struct io_uring *ring, int client_fd, int buf_index) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    struct conn_info *ci = malloc(sizeof(struct conn_info));
    ci->fd = client_fd;
    ci->buf_size = BUF_SIZE;
    
    io_uring_prep_recv(sqe, client_fd, conn_array[buf_index].buf, BUF_SIZE, 0);
    sqe->buf_index = buf_index;
    io_uring_sqe_set_data(sqe, ci);
}

// 提交 send
static void submit_send(struct io_uring *ring, int client_fd, int buf_index, int bytes) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    struct conn_info *ci = malloc(sizeof(struct conn_info));
    ci->fd = client_fd;
    ci->buf_size = BUF_SIZE;
    
    io_uring_prep_send(sqe, client_fd, conn_array[buf_index].buf, bytes, 0);
    sqe->buf_index = buf_index;
    io_uring_sqe_set_data(sqe, ci);
}

int main() {
    struct io_uring ring;
    io_uring_queue_init(2048, &ring, 0);
    
    int server_fd = setup_listening_socket(8080);
    submit_accept(&ring, server_fd);
    
    while (1) {
        struct io_uring_cqe *cqe;
        int ret = io_uring_wait_cqe(&ring, &cqe);
        if (ret < 0) {
            fprintf(stderr, "wait: %s\n", strerror(-ret));
            break;
        }
        
        struct conn_info *ci = io_uring_cqe_get_data(cqe);
        int type = 0; // 在实际项目中需要判断类型
        
        if (cqe->res < 0) {
            fprintf(stderr, "async op failed: %s\n", strerror(-cqe->res));
            free(ci);
        } else if (cqe->res == 0) {
            // 连接关闭
            close(ci->fd);
            free(ci);
        } else {
            // 根据类型处理：这里简化处理
            // 实际实现中应根据 OP 类型分发
            submit_recv(&ring, ci->fd, 0); // 提交下一次读
        }
        
        io_uring_cq_advance(&ring, 1);
    }
    
    io_uring_queue_exit(&ring);
    close(server_fd);
    return 0;
}

这个示例虽然简化，但展示了 io_uring 的核心循环模式：提交初始事件 -> 等待完成 -> 处理完成 -> 提交链式后续请求。对于生产级项目 shuttle 和 tokio-uring 提供了 io_uring 的 Rust async 运行时集成。

生产环境最佳实践

1. 队列深度选择

NVMe 设备的最优队列深度通常在 32~128 之间。io_uring 的 SQ 深度建议设置为设备最大队列深度的倍数。过大浪费内存，过小导致饥饿。

2. 利用多提交批量化

除非紧急，不要每提交一个 SQE 就调 io_uring_submit。批量化提交（每 8~32 个一 batch）可以摊销系统调用成本。如开启 IORING_SETUP_SQPOLL，则无需主动提交。

3. 避免混合阻塞与异步

io_uring 的一个常见错误是在同一个 ring 上同时使用固定缓冲区的 O_DIRECT 和页缓存路径，二者语义可能冲突。应根据 I/O 特征分流到不同 ring。

4. 监控与调试

通过 /proc//io_uring 可以查看 ring 的统计信息。perf 工具支持 io_uring 事件采样。Linux 5.15+ 引入 io_uring 的 BPF hooks，允许动态追踪 ring 行为。

5. 内核版本选择

io_uring 的局限与替代方案

io_uring 并非万能。在以下场景下需要权衡：

• 极小型 I/O 应用：如果每秒 I/O 量小于 1000，epoll + 同步 I/O 可能更简单且性能差异可以忽略。
• 复杂错误处理：异步模型天然增加错误传播复杂度，需要精心设计上下文追踪机制。
• 跨平台需求：io_uring 是 Linux 独占， Windows/macOS 需要 IOCP/kqueue 方案。
• 文件系统差异：ext4 在 O_DIRECT + io_uring 表现优异，但某些文件系统（尤其是网络文件系统如 NFS）对 io_uring 的利用有限。

替代方案对比：

未来展望

io_uring 仍在快速演进中。值得关注的几个方向：

1. 网络零拷贝进一步深化：sendmsg_zc 已经在 6.1 落地，未来零拷贝 recv 也在规划中
2. Verifiable Operations：配合 eBPF，安全团队正在探索在 io_uring 提交路径插入审计/管控点
3. 与 io_uring 对齐的 Rust 生态：tokio-uring、glommio 等运行时持续成熟
4. 分布式存储系统集成：Ceph、MinIO 已在评估 io_uring 接入
5. io_uring 安全边界：Google Chrome 团队发现 io_uring 可被利用绕过 seccomp，社区正在沟通通过引入 io_uring 子系统级别的权限控制来解决这类安全问题，也有人提议在 io_uring 上引入类似 Landlock 的访问控制机制。

结论

io_uring 是过去十年 Linux I/O 子系统最重要的创新。它用精巧的共享内存双队列模型解决了困扰 Linux 多年的异步 I/O 性能难题，并通过持续的内核迭代覆盖了网络、文件、套接字等几乎所有 I/O 场景。理解 io_uring 不仅有助于编写高性能代码，更能帮助我们理解现代操作系统对异步原语的重新思考 —— 随着 io_uring 和 io_uring 的 Rust 运行时生态成熟，异步 I/O 的新范式已经到来。