从 epoll 到 io_uring：Linux 异步 I/O 引擎的演进与实战

引言：为什么 epoll 不够用了

如果你做过 Linux 后端开发，几乎不可能没用过 epoll。从 nginx 到 Redis，从 Netty 到 Tokio，epoll 几乎是所有高性能网络服务的基石。当连接数达到十万级甚至百万级时，epoll 提供的 O(1) 事件就绪通知 让 select/poll 的线性扫描显得不堪一击。

然而，一个鲜被提及的事实是：epoll 解决的是"可通知性"问题，而非"零拷贝异步"问题。每次 I/O 操作仍然需要跨越用户态/内核态边界，数据仍然要在内核缓冲区和用户缓冲区之间复制。当 NVMe SSD 的延迟进入微秒级、网络带宽突破 100Gbps 时，这种"半异步"模型就成了新的瓶颈。

Linux 5.1 引入的 io_uring 正是对这一瓶颈的终极回应。它不仅仅是一个新的系统调用，而是一套完全重新设计的异步 I/O 执行引擎。本文将从 epoll 的核心机制出发，逐步剖析 io_uring 的架构设计、操作流程、高级特性，并通过实际代码和基准数据展示其在高并发场景下的性能飞跃。

第一章：epoll 的核心机制与局限

1.1 基础架构回顾

epoll 的核心由三个系统调用组成：

// 1. 创建 epoll 实例
int epfd = epoll_create1(EPOLL_CLOEXEC);

// 2. 注册/修改/删除监听事件
epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);

// 3. 等待就绪事件
int n = epoll_wait(epfd, events, maxevents, timeout);

其精妙之处在于红黑树 + 就绪链表的双数据结构设计：所有被监听的 fd 以红黑树组织（支持 O(log N) 的增删查），就绪事件通过回调机制直接插入就绪链表，epoll_wait 只需检查链表是否为空即可获得所有就绪事件。

1.2 epoll 的边缘触发（ET）vs 水平触发（LT）

边缘触发模式下，内核只在 fd 状态变化时通知一次。如果数据未一次性读完，剩余数据不会再次触发事件。这要求用户循环调用 read() 直到返回 EAGAIN。优势在于减少了 epoll_wait 的唤醒次数，劣势是编程模型更复杂，遗漏读取会导致数据"沉"在内核缓冲区。

1.3 epoll 的天花板

尽管 epoll 在事件通知上做到了 O(1)，但以下场景暴露了其根本局限：

• 频繁的小 I/O 操作：每次 read/write 都是一次完整的系统调用，涉及用户态/内核态切换（约 1-2 μs）
• 缓冲区管理：内核无法预知用户将使用哪些缓冲区，无法做预读取或合并写入优化
• 磁盘 I/O 效率有限：epoll 对磁盘 fd 的理论支持在实践中因内核 block layer 同步特性而表现不佳
• 无法利用高级硬件特性：如 DMA 零拷贝、轮询模式（Polling）等

一句话总结：epoll 告诉你"可以读了"，但真正的读取仍然是同步的。

第二章：Linux Native AIO 的尝试与失败

在 io_uring 之前，Linux 曾试图通过 Native AIO（即 libaio）提供真正的异步 I/O。其基于五个系统调用：io_setup、io_submit、io_getevents、io_destroy、io_cancel。

然而 Native AIO 有三大致命缺陷：

1. 仅支持 O_DIRECT：绕过页缓存意味着失去了 Linux 页缓存的预读、合并、缓存优势，小文件性能极差
2. 不支持网络 I/O：无法用于 socket，只适用于块设备
3. API 设计粗糙：每次提交需要单独的 io_submit 系统调用，且提交/完成结构不够灵活

这些问题导致 Native AIO 几乎只存在于数据库等极少数场景中，未能成为通用异步方案。

第三章：io_uring 架构深度解析

3.1 共享队列环（Shared Queue Ring）设计

io_uring 的核心创新是用户态与内核态共享两个环形缓冲区（Ring Buffer），完全消除了每次 I/O 操作的系统调用开销：

• Submission Queue (SQ)：用户态写入 SQE（Submission Queue Entry），内核态消费
• Completion Queue (CQ)：内核态写入 CQE（Completion Queue Entry），用户态消费

两者都是单生产者-单消费者（SPSC）的无锁环形队列。用户通过 mmap 直接将两个队列映射到用户态内存，写入 SQE 后只需在需要时敲响"门铃"（io_uring_enter），内核处理完成后将结果写入 CQ。

3.2 零系统调用模式（SQPOLL）

io_uring 的终极形态是开启 SQPOLL（Submission Queue Polling）模式：

struct io_uring_params params = {
    .sq_entries = 1024,
    .cq_entries = 2048,
    .flags = IORING_SETUP_SQPOLL,   // 内核轮询 SQ
    .sq_thread_idle = 2000           // 空闲 2s 后线程休眠（ms）
};

io_uring_queue_init_params(ring_size, &ring, &params);

此模式下，内核启动一个专用线程持续轮询 SQ。用户写入 SQE 后完全不需要调用 io_uring_enter——内核线程会自动发现新条目并执行。整个 I/O 生命周期中，用户态到内核态的上下文切换彻底消失。

代价是 CPU 占用：SQPOLL 线程即使在无事可做时也会消耗 1-2% 的 CPU（直到 idle 超时）。

3.3 注册缓冲区（Registered Buffers）

io_uring 允许预先注册一组固定缓冲区（IORING_REGISTER_BUFFERS），之后 I/O 操作通过缓冲区索引引用而非传递指针。内核在注册时已完成内存 pinning 和映射，每次 I/O 节省了一次 get_user_pages + put_user_pages 周期。对于高频小 I/O 场景，性能提升可达 15-30%。

3.4 固定文件（Registered Files）

类似缓冲区注册，IORING_REGISTER_FILES 允许预先注册 fd 数组。I/O 提交时使用索引而非整数 fd，避免了每次系统调用的 fd 查找（file 结构体引用计数 + 文件表哈希）。在连接密集的服务器上，这减少了约 5-10% 的开销。

第四章：io_uring 核心操作与代码实战

4.1 基础读写操作

// 获取一个 SQE
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);

// 准备读操作：将 fd 的数据读取到 buf，长度为 len，偏移为 offset
io_uring_prep_read(sqe, fd, buf, len, offset);
io_uring_sqe_set_data(sqe, my_data_ptr);  // 用户自定义指针，完成时返回

// 提交（如果未启用 SQPOLL，需要显式 enter）
io_uring_submit(&ring);

// 收割完成事件
struct io_uring_cqe *cqe;
io_uring_wait_cqe(&ring, &cqe);
// 处理 ce->res（返回值）、cqe->user_data（自定义指针）
io_uring_cqe_seen(&ring, cqe);

关键区别：io_uring_get_sqe 和 io_uring_submit 都是纯用户态操作（无系统调用），真正跨入内核只在需要通知时发生。

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

struct io_uring_sqe *sqe2 = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe2, fd, data_buf, data_len, HEADER_SIZE);
// sqe2 会在 sqe1 完成后自动开始，无需用户介入

// 带超时的 accept
struct __kernel_timespec ts = { .tv_sec = 5, .tv_nsec = 0 };
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_timeout(sqe, &ts, 0, 0);

// 取消已提交但未完成的操作
struct io_uring_sqe *cancel_sqe = io_uring_get_sqe(&ring);
io_uring_prep_cancel(cancel_sqe, target_user_data, 0);

// 为每个连接预链接：recv → send
void submit_echo(struct io_uring *ring, int conn_fd) {
    struct io_uring_sqe *recv_sqe = io_uring_get_sqe(ring);
    io_uring_prep_recv(recv_sqe, conn_fd, buf, BUF_SIZE, 0);
    io_uring_sqe_set_data(recv_sqe, (void*)(uintptr_t)conn_fd);
    recv_sqe->flags |= IOSQE_IO_LINK | IOSQE_BUFFER_SELECT;
    recv_sqe->buf_group = 0;  // 使用缓冲组 0（IORING_REGISTER_BUFFERS_SELECT）

    struct io_uring_sqe *send_sqe = io_uring_get_sqe(ring);
    io_uring_prep_send(send_sqe, conn_fd, NULL, 0, 0);
    io_uring_sqe_set_data(send_sqe, (void*)(uintptr_t)conn_fd);
    // recv 完成后数据已在 send 可直接引用的选定缓冲区中
}