io_uring：Linux异步I/O的下一代接口深度解析与实战-尧图网络科技

io_uring：Linux异步I/O的下一代接口深度解析与实战

一、为什么epoll已经不够用了？

epoll统治了Linux异步I/O十几年。它解决了C10K问题，但在C10M场景下暴露出两个根本缺陷。

第一个是系统调用开销。每产生一个I/O事件，用户态先要epoll_wait拿到fd，再调用read/write把数据搬到用户空间。一次请求至少两次系统调用。在高吞吐场景下，syscall的开销从比例上看不大，但绝对量足够吃掉CPU。

第二个是拷贝开销。数据从内核态到用户态的拷贝无法避免，每次read都意味着memcpy。对于追求零拷贝的极致性能场景，epoll模型有天花板。

io_uring的设计哲学就是解决这两点。它用共享内存环形队列替代系统调用密集的epoll+read模式，在一次系统调用中批量提交和收割I/O请求。

二、核心架构：SQ/CQ环形队列

io_uring用两个环形缓冲区实现用户态与内核态的异步通信：

graph LR subgraph 用户态 A[应用程序] -->|写入SQE| B[Submission Queue] A -->|读取CQE| C[Completion Queue] end subgraph 共享内存 B <--> D[共享环形缓冲区] C <--> D end subgraph 内核态 D --> E[io_uring工作线程] E -->|完成通知| C end

SQ（Submission Queue）是用户态写入I/O请求的地方。CQ（Completion Queue）是内核回写完成结果的地方。两者都是SPSC（单生产者单消费者）环形缓冲区，通过内存排序屏障保证可见性，无需系统调用即可操作。

这意味着理想路径下，一次I/O操作开销为零系统调用。用户往SQ里写一个SQE（Submission Queue Entry），内存屏障让内核可见，内核处理完往CQ写CQE，用户通过轮询或事件获知结果。

更深一层看，io_uring的内部数据结构设计决定了它的性能天花板远高于epoll。SQ和CQ的每个条目都是定长的（64字节），内存布局对CPU缓存极其友好。而epoll的事件结构需要动态分配，在高频场景下内存分配器的开销不可忽略。此外，io_uring原生支持"固定文件"和"固定缓冲区"注册，通过IORING_REGISTER_FILES和IORING_REGISTER_BUFFERS预注册资源，绕过每次I/O操作中的文件描述符查找和内存页锁定开销。

io_uring还支持"Splice"和"Send_ZC"等零拷贝操作，数据在文件描述符之间直接在内核空间流转，根本不经过用户态。结合固定缓冲区，可以实现真正的端到端零拷贝，这是epoll体系无法做到的。

三、实战：用liburing实现高性能echo服务器

liburing是io_uring的用户态封装库，比直接操作裸API更安全。先看一个echo服务器的核心实现：

#include <liburing.h> #include <netinet/in.h> #include <string.h> #include <stdlib.h> #define QUEUE_DEPTH 256 #define BUF_SIZE 4096 struct conn_info { int fd; int event_type; }; static int setup_listening_socket(int port) { int fd = socket(AF_INET, SOCK_STREAM, 0); int opt = 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); struct sockaddr_in addr = { .sin_family = AF_INET, .sin_port = htons(port), .sin_addr.s_addr = htonl(INADDR_ANY), }; bind(fd, (struct sockaddr *)&addr, sizeof(addr)); listen(fd, 4096); return fd; } static int add_accept(struct io_uring *ring, int listen_fd) { struct io_uring_sqe *sqe = io_uring_get_sqe(ring); if (!sqe) return -1; io_uring_prep_accept(sqe, listen_fd, NULL, NULL, 0); struct conn_info *info = malloc(sizeof(*info)); info->fd = listen_fd; info->event_type = 0; io_uring_sqe_set_data(sqe, info); return 0; } static void handle_accept(struct io_uring *ring, struct io_uring_cqe *cqe) { int client_fd = cqe->res; if (client_fd < 0) return; struct io_uring_sqe *sqe = io_uring_get_sqe(ring); struct conn_info *info = malloc(sizeof(*info)); info->fd = client_fd; info->event_type = 1; void *buf = malloc(BUF_SIZE); io_uring_prep_recv(sqe, client_fd, buf, BUF_SIZE, 0); io_uring_sqe_set_data(sqe, info); io_uring_sqe_set_buffer_data(sqe, buf); // re-add accept for next connection add_accept(ring, cqe->user_data ? ((struct conn_info *)io_uring_cqe_get_data(cqe))->fd : -1); }

关键点：io_uring_sqe_set_data可附加自定义数据到每个请求，在完成队列中通过cqe->user_data取回，实现请求上下文的关联。

完整的事件循环实现如下：

int main(int argc, char *argv[]) { struct io_uring ring; io_uring_queue_init(QUEUE_DEPTH, &ring, 0); int listen_fd = setup_listening_socket(8080); add_accept(&ring, listen_fd); while (1) { struct io_uring_cqe *cqe; io_uring_submit(&ring); io_uring_wait_cqe(&ring, &cqe); struct io_uring_cqe cqes[32]; unsigned head; unsigned count = 0; // 批量收割已完成事件 io_uring_for_each_cqe(&ring, head, cqe) { struct conn_info *info = io_uring_cqe_get_data(cqe); if (info->event_type == 0) handle_accept(&ring, cqe); // 处理read完成等其他事件类型... count++; } io_uring_cq_advance(&ring, count); } }

这里的核心优化是io_uring_for_each_cqe宏，它在一次调用中批量处理所有已完成的CQE，而非逐个等待。生产环境中，QQUEUE_DEPTH建议设置为256或512，兼顾内存开销和批量效率。

四、三种工作模式与性能对比

io_uring提供三种操作模式，适应不同场景：

graph TB A[io_uring工作模式] --> B[中断驱动模式] A --> C[轮询模式 IORING_SETUP_IOPOLL] A --> D[内核轮询模式 IORING_SETUP_SQPOLL] B --> B1[延迟:~10μs] B --> B2[CPU占用低] B --> B3[适合:普通应用] C --> C1[延迟:~2-5μs] C --> C2[CPU 100%一个核] C --> C3[适合:NVMe SSD] D --> D1[延迟:~3-6μs] D --> D2[无系统调用] D --> D3[适合:极高吞吐]

中断驱动模式是默认行为，内核完成I/O后触发中断，用户态通过io_uring_wait_cqe等待。

IOPOLL模式适合高速NVMe设备，不触发中断，由用户态主动轮询CQ，省去中断处理开销。

SQPOLL模式在内核侧起一个线程持续轮询SQ，用户态写SQ甚至不需要系统调用。这适合延迟极度敏感的场景，代价是内核线程持续占用一个CPU核。

在生产中，大部分应用使用中断驱动模式就已经足够。IOPOLL和SQPOLL仅在确定I/O延迟是瓶颈时才考虑。