文章梳理异步I/O的两大范式：就绪型（epoll/kqueue，对应Reactor）与完成型（io_uring/IOCP，对应Proactor），并从推进模型与栈模型两个维度分析主流语言：Rust的无栈Future与epoll契合，接入io_uring需转移缓冲区所有权；Go用有栈协程封装epoll；Zig以Fiber原生对齐io_uring；C#的async/await源于IOCP。最后给出选型建议。

作者重跑BadgerDB仓颉移植版基准，推翻原有三条结论：并发写实际比Go慢约2.6倍而非1.3倍，原因是两侧规模相差1300倍；FFI memcmp因约70纳秒调用开销，在随机key下反比逐字节比较慢18倍；io_uring在小文件场景慢2–6倍，但大写入高并发时可快1.1–1.6倍。错误源于规模未对齐、输入分布不匹配及结论超出证据边界。

本文为SPDK用户态存储栈系列首篇，定位其相对内核NVMe与io_uring的生态位，提出五条坐标系（I/O路径、线程消息、设备独占、bdev、远端控制面）作为排障语言，并规划16篇阅读路线，强调用户态轮询栈的CPU税与运维代价。

本文对比SPDK用户态、内核NVMe块层及O_DIRECT+io_uring三条存储路径，强调选型需基于机制差异而非速度排名。SPDK适合NVMe-oF目标或用户态后端，内核路径利于系统共置，io_uring优化应用自管缓存。迁移需考虑设备独占、CPU核税、配置与观测成本，并建议可回滚演练。最终选择应依据硬件实测与运维能力，而非追求技术先进。

本文为SPDK用户态存储系列终章，通过排除树指导选型：无用户态需求用内核NVMe，需高IOPS用O_DIRECT+io_uring，能付核税且需target/vhost则选SPDK。强调机制差异而非跑分，列出阅读路径、开放问题（如ZNS、DPU卸载），并建议将决策写入架构记录，重跑排除树时禁止仅贴跑分截图。

本文比较了 Linux 中的两种 I/O 处理机制：epoll 和 io_uring。epoll 适用于高并发场景，但需要多次系统调用；io_uring 通过共享环形队列减少系统调用次数，适合高吞吐量需求。尽管 io_uring 有优势，但在低版本内核或现有生态系统中，epoll 仍然是更合适的选择。选择应基于具体需求和环境。

本文探讨了将O_DIRECT与io_uring组合使用的技术路径，旨在解决数据库和块存储引擎中的双重缓冲与系统调用开销问题。文章详细分析了组合使用的决策边界、O_DIRECT的对齐约束、io_uring固定缓冲区的注册方法及其与O_DIRECT叠加时的注意事项。通过实测对比了三种写路径的性能，指出register_buffers组合在特定环境下可能失败，强调需在目标内核上验证。最后提供了工程检查清单和选型建议，帮助读者在实际应用中做出正确决策。

epoll是Linux网络服务器的核心I/O多路复用机制，通过红黑树管理fd、就绪链表和回调机制实现高效事件通知。支持LT（水平触发）和ET（边缘触发）模式，EPOLLEXCLUSIVE解决惊群问题，EPOLLONESHOT保证单线程处理。相比select/poll，epoll仅遍历就绪fd，性能更优。io_uring是补充而非替代，适用于文件I/O和极致性能场景。

io_uring 是 Linux 5.1 引入的异步 I/O 框架，利用共享内存环形缓冲区减少系统调用开销，支持多种文件和网络操作。核心数据结构包括提交队列（SQE）和完成队列（CQE），通过 SQPOLL 和 IOPOLL 等模式优化性能。注册文件描述符和缓冲区可减少重复开销，io-wq 处理阻塞操作。安全模型仍在演进，建议在生产环境中限制非特权用户使用。

本文讨论了在高并发网络服务中使用io_uring的多线程架构，推荐采用“每个工作线程一个ring”的Thread-per-Ring模式，并结合SO_REUSEPORT进行连接分流，以提升性能和简化代码。文章分析了多线程的线程安全问题，介绍了四种多线程架构模式及其优缺点，强调了内存管理和CPU亲和性的重要性，并提供了多线程Echo Server的实现示例，展示了如何有效利用io_uring进行高效的网络编程。

在 Linux 网络编程中，epoll 已使用近 20 年，而 io_uring 的出现改变了这一局面。两者在架构、性能和适用场景上存在显著差异：epoll 依赖频繁的系统调用，适合遗留系统和低活跃连接；io_uring 通过批处理和零拷贝提升性能，更适合高性能需求和新项目。

liburing 提供了更友好的 API 来使用 io_uring，简化了内存管理和请求处理。使用 liburing 的流程包括初始化、获取请求、提交、等待完成和处理结果。示例代码展示了一个简单的 cat 命令，适合高并发场景。

本文介绍了如何使用 io_uring 实现 TCP Echo Server。与传统同步模型不同，io_uring 通过状态机管理连接状态，并通过回调链式处理异步操作。代码示例展示了连接、数据读取和写入的处理，并强调了内存管理的重要性。

io_uring通过SQPOLL、固定文件和提供缓冲区等特性，显著提升I/O性能，减少系统调用开销，优化内核资源管理。

Libevent 2.2（Alpha）版本引入了实验性的 io_uring 后端，结合了 Reactor 和 Proactor 模式。虽然目前主要使用 io_uring 的 POLL_ADD 操作，尚未完全发挥其异步能力，但已能减少系统调用。该后端仍处于实验阶段，未来有望支持真正的 Proactor 模式，以提升性能。

Linux 5.1 引入的 io_uring 技术彻底改变了高性能 I/O 的方式。文章探讨了 io_uring 的核心概念、异步 I/O 的优势，以及与 AIO 和 epoll 的比较，并介绍了如何使用 liburing API 进行文件 I/O 和网络编程。

本文讨论了io_uring的缺点与局限性，指出在某些场景下epoll更为优越。io_uring在低延迟和内存占用方面表现不佳，尤其在高并发和海量连接时。此外，编程复杂度和调试难度较高，生态和安全性问题也需考虑。选择技术时应根据具体需求，避免盲目追新。