L2 · async · io_uring · NVMe
榨干硬件性能
Weka 的招牌是把 NVMe 榨到接近硬件极限。这个阶段搞懂两件事：异步运行时怎么调度上万并发 IO，io_uring 为什么比传统系统调用快。
本阶段出口：里程碑② forge-bench：自研压测工具，单机引擎跑到 NVMe 标称 IOPS 的 70% 以上。
4 节课 · 约 3 小时已完成 0/4
- 1
tokio：异步运行时是怎么回事
编码55m一个线程怎么同时伺候一万个连接？把 async/await、Future、运行时调度讲透，再把 forge-store 的接口改造成异步版本。
- 解释 async fn 编译成状态机的过程
- 说清 tokio 的多线程调度与 work stealing
- 知道什么时候该用 spawn_blocking：文件 IO 的尴尬地位
- 2
io_uring：内核旁路前的最后一站
编码55m两个环形队列把系统调用摊薄到接近零。理解 SQ/CQ 模型,用 Rust 直接驱动 io_uring 做真异步的文件 IO。
- 画出 SQ/CQ 双环模型的数据流
- 用 io-uring crate 写出注册 buffer 的随机读程序
- 对比 io_uring 与线程池方案的 IOPS 和 CPU 占用
- 3
NVMe 的并行世界
原理40m为什么队列深度 1 只能跑出标称 IOPS 的零头？多队列、并行 die、写放大 —— 从协议层理解 SSD,让引擎的 IO 模式顺着硬件脾气来。
- 解释队列深度与 IOPS/延迟曲线的关系
- 说清 NVMe 多队列与 CPU 亲和的配合
- 列出对 SSD 友好的三种写模式
- 4
里程碑②：对标 fio
里程碑50m写自己的压测工具 forge-bench,输出延迟直方图和 P99;用它证明你的引擎达到 NVMe 标称 IOPS 的 70%,差距去哪儿了要能说清。
- 实现带延迟直方图（HDR）的并发压测工具
- 跑出引擎的 QD-IOPS-延迟三维数据
- 写一页性能分析报告：瓶颈在哪、下一步优化什么