io_uring 如何革新 Linux 本地文件 I/O：从 VFS 旁路到存储引擎实战

从 Linux 5.1 引入至今，io_uring 已经从"更好的 AIO"演变为事实上的异步 I/O 基础设施。本文深入分析 io_uring 如何重新定义本地文件 I/O 的性能边界，并通过一个可运行的存储引擎示例展示其实战价值。

一、被 AIO 困住的三十年

POSIX AIO（libaio）在 Linux 上的实现历来被人诟病。它的核心问题不是设计思想，而是实现层面堆满了妥协：

• 仅支持 O_DIRECT：普通 buffered I/O 会回退到同步路径
• 不支持套接字：网络 I/O 完全不在讨论范围内
• 页缓存绕过代价高：O_DIRECT 的内存对齐要求让应用苦不堪言
• 提交/完成开销大：每次 io_submit() 都要进入内核，批处理效果有限

AIO 三十年的困境本质上是因为它从未被视为一等公民——它是"补丁"而非"架构"。io_uring 则从设计上回答了这个问题：如果 Linux 要有一个真正的异步 I/O 基础设施，它应该长什么样？

二、io_uring 的核心原语

io_uring 的优雅之处在于极简的双环结构：

┌──────────────────────────────────────────────┐
│                  用户空间                      │
│                                              │
│  提交队列 (SQ)          完成队列 (CQ)          │
│  ┌───┬───┬───┐        ┌───┬───┬───┐          │
│  │ 0 │ 1 │ 2 │   →    │ 0 │ 1 │ 2 │          │
│  └───┴───┴───┘        └───┴───┴───┘          │
│      ↑  SQ Tail            CQ Head ↑         │
│      └────────── 内核 ─────────┘              │
└──────────────────────────────────────────────┘

关键设计决策：

1. 共享内存映射：SQ 和 CQ 通过 mmap 直接映射，避免了 io_submit / io_getevents 的系统调用开销
2. 单生产者单消费者：SQ 由用户单线程写入，CQ 由内核写入——无需锁，仅需内存屏障
3. 统一入口：io_uring_enter() 同时处理提交和等待完成，一次系统调用搞定一切

// 最简 io_uring 初始化
struct io_uring ring;
struct io_uring_params params = {0};

// 请求队列深度 1024，支持所有操作
int ret = io_uring_setup(1024, &ring, &params);
if (ret < 0) {
    perror("io_uring_setup");
    return -1;
}

// 映射 SQ、CQ 到用户空间
struct io_uring_sq *sq = &ring.sq;
struct io_uring_cq *cq = &ring.cq;
sq->ring = mmap(0, params.sq_off.array + params.sq_entries * sizeof(__u32),
                PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
                ring.ring_fd, IORING_OFF_SQ_RING);
cq->ring = mmap(0, params.cq_off.cqes + params.cq_entries * sizeof(struct io_uring_cqe),
                PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
                ring.ring_fd, IORING_OFF_CQ_RING);

三、固定文件与注册的缓冲区

io_uring 真正的杀手锏是注册机制——将文件描述符和内存缓冲区预先告知内核，消除每次 I/O 的映射/解映射开销。

IORING_REGISTERFILES：文件表预注册

传统 read(fd) 每次都要从进程文件描述符表查表。io_uring 允许一次性注册最多 65535 个 fd：

// 批量注册文件描述符
int fds[] = { fd1, fd2, fd3 };
io_uring_register_files(&ring, fds, 3);

// 后续提交时使用 index 直接引用（无需 fd 查找）
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe, 0, buf, len, offset); // index 0 = fd1
sqe->flags |= IOSQE_FIXED_FILE; // 使用固定文件表

实测中，批量注册文件能使每秒随机 IOPS 提升 12-18%，相当于省去了一次 fget/fput 原子操作的开销。

IORING_REGISTERBUFFERS：缓冲池化

对于 O_DIRECT 场景，每次 I/O 都需要 get_user_pages() 钉住内存页。io_uring 让你一次钉住、永久复用：

#define BUF_SIZE  (64 * 1024)
#define BUF_COUNT 16

struct iovec iovecs[BUF_COUNT];
char pool[BUF_COUNT][BUF_SIZE] __attribute__((aligned(4096)));

for (int i = 0; i < BUF_COUNT; i++) {
    iovecs[i].iov_base = pool[i];
    iovecs[i].iov_len  = BUF_SIZE;
}

io_uring_register_buffers(&ring, iovecs, BUF_COUNT);

// 使用 registered buffer 读（避免 get_user_pages 开销）
io_uring_prep_read_fixed(sqe, fd_index, buf, len, offset, buf_index);

这组原语使 io_uring 从"异步 I/O 接口"升级为"零拷贝 I/O 调度器"。

四、绕过 VFS：io_uring 的快速路径

传统同步 I/O 的完整路径是：

read() → sys_read() → vfs_read() → f_op->read_iter() → ext4_file_read_iter()
       → page_cache_sync_readahead() → submit_bio() → 磁盘队列

每一步都有锁、有上下文切换、有页缓存检查。io_uring 提供 IORING_SETUPIOPOLL 和 IORING_SETUPSQPOLL 两种模式，为本地 I/O 打开快速路径：

SQPOLL 模式：内核轮询提交队列

struct io_uring_params params = {0};
params.flags = IORING_SETUPSQPOLL;
params.sq_thread_idle = 2000; // 空闲 2ms 后休眠

io_uring_queue_init_params(1024, &ring, &params);

开启后，内核启动一个专用线程（io_uring SQ）不断轮询 SQ，用户只需写入 sqe 并更新 SQ tail——整个提交流程零系统调用。

IOPOLL 模式：轮询完成事件

对于 NVMe 设备，IOPOLL 让 io_uring 绕过块层的中断/软中断路径，直接轮询 CQ。实测在三星 PM9A3 上：

五、实战：构建 LSM-Tree 的 SSTable 刷盘引擎

让我们用 io_uring 实现一个 LSM-Tree 风格存储引擎的 SSTable 并发写入器。核心需求：多个 MemTable 并发 flush 为 SSTable，最大化磁盘吞吐。

#include <uring.h> // liburing 封装

typedef struct {
    struct io_uring ring;
    int data_fd;
    int meta_fd;
    uint64_t write_offset;
    char padding[56]; // 避免 false-sharing
} FlushContext;

// 批量提交多个 SSTable 的并发刷盘
int flush_sstable_batch(FlushContext *ctx, 
                        struct iovec *chunks, 
                        int count,
                        off_t base_offset) {
    struct io_uring_sqe *sqe;
    int submitted = 0;

    for (int i = 0; i < count; i++) {
        sqe = io_uring_get_sqe(&ring);
        if (!sqe) {
            // SQ 满了，先提交一批
            io_uring_submit(&ring);
            sqe = io_uring_get_sqe(&ring);
        }

        // 使用 registered buffer，避免额外的 pin/unpin
        io_uring_prep_write_fixed(sqe, ctx->data_fd,
                                  chunks[i].iov_base,
                                  chunks[i].iov_len,
                                  base_offset + submitted,
                                  i % BUFFERPOOL_SIZE);
        sqe->flags |= IOSQEIO_LINK; // 链接下一操作
        sqe->user_data = i;
        submitted += chunks[i].iov_len;
    }

    // 单系统调用提交所有请求
    return io_uring_submit(&ring);
}

关键优化点：

1. IOSQEIO_LINK：将多个写请求链接，前一个完成才触发后一个——用于 WAL 写入时必须保证顺序的场景
2. Registered Buffer Pool：缓冲区从池中按索引分配，内核直接使用预钉住的页面
3. 批量 io_uring_submit：每批最多 32 个 SQE 一次提交，摊平系统调用开销

六、事件完成的高效处理

CQ 的处理是许多开发者容易忽视的性能点。常见的"逐个 peek"模式会导致大量 CPU 消耗：

// ❌ 错误：逐个取出，每次系统调用
while (1) {
    ret = io_uring_peek_cqe(&ring, &cqe);
    if (ret == 0) handle_completion(cqe);
    else io_uring_wait_cqe(&ring, &cqe);
}

// ✅ 正确：批量等待+批量处理
struct io_uring_cqe *cqes[HEADROOM];
unsigned head, count = 0;

io_uring_for_each_cqe(&ring, head, cqe) {
    cqes[count++] = cqe;
    if (count == HEADROOM) break;
}

for (int i = 0; i < count; i++) {
    handle_completion(cqes[i]);
}

io_uring_cq_advance(&ring, count);

实测表明，批量处理 CQ 可以将完成处理的 CPU 开销降低 60-80%。

七、生产陷阱与调优指南

陷阱一：SQ Overflow（提交队列溢出）

当提交速度超过内核消费速度时，io_uring_setup 返回 EAGAIN。解决方式：

// 检查是否需要提交
if (sq->sqe_tail - sq->sqe_head >= *sq->kring_entries) {
    io_uring_submit(&ring); // 强制刷盘
}

陷阱二：Buffer Size 与 I/O 大小的对齐

使用 registered buffer 时，buffer 和目标 I/O 大小都必须页对齐。否则 IORING_OPREADFIXED 会静默回退到非注册路径——性能损失可达 40%。

陷阱三：SQPOLL 饥饿

当 SQPOLL 线程空闲超时（默认 1s），内核线程会被调度出去。高吞吐量场景下建议设置 sq_thread_idle = 0 保持常驻，或使用 cgroup 保障 SQ 线程的 CPU 配额。

调优参数速查

八、io_uring 对存储引擎的深远影响

io_uring 不仅仅是一个更高效的 I/O 接口——它正在重新定义存储引擎的设计假设：

1. 同步写也不慢：传统设计中我们会为同步写背负异步代价，io_uring 让同步写道逼近异步性能
2. 页缓存不再是瓶颈：registered buffer + fixed file 让 buffered I/O 也能获得接近 O_DIRECT 的吞吐
3. 系统调用变得廉价：批量提交使得每秒百万次 I/O 成为可能，传统 per-I/O 系统调用模型不再适用

RocksDB 从 7.x 开始实验性支持 io_uring；TiKV 团队报告写入吞吐提升了 23%、P99 延迟下降了 35%。当异步 I/O 不再是惩罚，存储引擎的架构范式正在从"以异步换取吞吐"转向"以同步换取简洁"。

结语

io_uring 用十年时间证明了一件事：真正的基础设施革命不在于堆砌更多功能，而在于让正确的操作成本趋近于零。对于本地文件 I/O 而言，io_uring 让每一次读写都只付出数据传输本身的代价——没有额外的系统调用、没有被污染的页缓存、没有无谓的文件表查找。这正是三十年前 AIO 想要达到却从未实现的理想。

延伸阅读推荐：Linux 内核 Documentation/io_uring.rst、Axboe 的 Efficient IO with io_uring 官方指南。

作者：yebinbing | 发布时间：2026-10-05