【io_uring 系列】巅峰对决：io_uring vs epoll 性能与架构对比
在 Linux 高性能网络编程领域，epoll 统治了近 20 年。而 io_uring 的出现打破了这一局面。本文将从原理、性能和适用场景三个维度，深度对比这两代 I/O 方案。
1. 架构模型对比
特性 epoll io_uring 模型 Reactor (就绪通知) Proactor (异步完成) 工作流 1. 等待 fd 就绪 2. 发起 read/write 系统调用 1. 提交 read/write 请求 2. 等待完成通知 系统调用 频繁 (epoll_wait, read, write) 极少 (批处理 io_uring_enter 或 0 syscall) 数据拷贝 需要 (内核 -> 用户 buffer) 零拷贝 (支持 IORING_OP_SPLICE 等) 磁盘 I/O 不支持 (普通文件总是就绪) 完美支持 (真正的异步磁盘 I/O)
核心差异：谁在干活？
- epoll: 内核只负责通知。搬运数据（读写内存）的工作由用户线程在收到通知后亲自完成。
- io_uring: 用户只负责下单。搬运数据的工作由内核在后台默默完成，用户线程只负责收货。
2. 性能开销分析
2.1 系统调用 (Syscall)
这是 epoll 最大的痛点。在高并发场景下，每秒百万级的请求意味着百万级的 read/write 系统调用。每次系统调用都涉及上下文切换（Context Switch）和 CPU 模式切换，开销不容小觑。
io_uring 通过 SQ/CQ 环形队列 和 批处理 解决了这个问题。在 SQPOLL 模式下，用户态甚至可以做到 0 系统调用 发送 I/O 请求。
2.2 内存拷贝
epoll 模式下，数据通常需要从网卡 -> 内核 socket buffer -> 用户 buffer。 io_uring 支持注册缓冲区 (IORING_REGISTER_BUFFERS)，允许内核直接锁定用户态内存，减少内核内部的映射开销。
2.3 漏洞缓解 (Spectre/Meltdown)
现代 CPU 为了修复推测执行漏洞，增加了系统调用的开销。这对依赖频繁系统调用的 epoll 打击比 io_uring 更大。
3. 适用场景指南
什么时候坚持用 epoll？
- 遗留系统维护：代码库庞大，基于 Reactor 模式构建（如 Redis, Nginx 早期版本）。
- 连接数极多但活跃度低：
epoll在处理海量空闲连接时依然非常高效。 - 内核版本受限：
io_uring需要 Linux 5.1+ (推荐 5.10+)，很多老旧生产环境无法满足。
什么时候转向 io_uring？
- 极高性能要求：需要单机处理百万级 QPS，且 CPU 成为瓶颈。
- 混合 I/O 场景：既有网络 I/O 又有大量磁盘 I/O（如数据库、存储服务器）。
io_uring统一了这两者。 - 新项目开发：没有历史包袱，可以直接采用 Proactor 模式设计架构。
4. 总结
epoll 是一把锋利的瑞士军刀，轻便、通用，足以应付绝大多数场景。 io_uring 则是一台工业级挖掘机，为了吞吐量和效率而生，虽然驾驶它需要更高的技巧（更复杂的内存管理和异步逻辑），但在处理大规模 I/O 时，性能优势非常突出。
上一篇: 01-core-concepts.md - io_uring 核心原理 下一篇: 03-liburing-api.md - liburing 基础 API 详解
返回 io_uring 系列索引
同主题继续阅读
把当前热点继续串成多页阅读，而不是停在单篇消费。