Rust 异步运行时深度对决：Tokio vs Monoio vs Glommio——从理论到生产级性能调优

3.3 io_uring 驱动的 I/O：真正的零拷贝异步

// Monoio 的 fs 模块直接使用 io_uring pwritev/readv
async fn read_file_zero_copy(path: &str) -> io::Result<Vec<u8>> {
    let file = monoio::fs::OpenOptions::new()
        .read(true)
        .create(false)
        .open(path)
        .await?;
    
    let metadata = file.metadata().await?;
    let mut buf = Vec::with_capacity(metadata.len() as usize);
    
    // Monoio 在内部使用 io_uring 的 pread 操作
    // 固定缓冲区 + vectored → 真正零拷贝（跳过一次内核态到用户态拷贝）
    let n = file.read_at(&mut buf, 0).await?;
    buf.truncate(n);
    Ok(buf)
}

// Monoio 的网络 I/O：LT（Level Triggered）模式（默认）或 ET 模式
async fn handle_client<S: monoio::net::SockAddr>(mut conn: monoio::net::TcpStream) {
    let mut buf = [0u8; 4096];
    loop {
        // Monoio 的 read 直接使用 io_uring read 而非 epoll + read
        // 优势：减少 50% 的 epoll_ctl/epoll_wait 系统调用
        let n = match conn.read(&mut buf).await {
            Ok(0) => return, // EOF
            Ok(n) => n,
            Err(e) if e.kind() == io::ErrorKind::WouldBlock => continue,
            Err(e) => { log::error!("读取错误: {}", e); return; }
        };
        // 处理请求...
        conn.write_all(&buf[..n]).await.unwrap();
    }
}

3.4 Monoio 的局限

• 内核依赖：要求 Linux ≥ 5.10（io_uring 生产可用版本）
• !Send 约束：无法跨线程 spawn，全局状态只能用 thread_local!
• 生态缺口：缺少 Tokio 级别的三方 crate 兼容层
• CPU 亲和性要求：需要手动绑核，配置复杂度高

四、Glommio：共享 Nothing 的 io_uring 微调器

4.1 设计理念

Glommio（DataDog 主导）同样基于 io_uring，但与 Monoio 的"极端单线程"不同，Glommio 允许每个核拥有自己的运行时实例，核间通过显式消息通道通信——这是经典的 share-nothing 架构：

// Glommio 启动：按需创建多个 Executor 组（每组对应一个物理核心类型）
use glommio::{LocalExecutorBuilder, Placement, CpuLocation};

fn main() {
    // 先创建一个 numa 感知的运行时组
    let handle = LocalExecutorBuilder::new(Placement::Fixed(0))
        .spawn(|| async move {
            // 这个闭包运行在绑定到 CPU 0 的线程上
            let mut listener = TcpListener::bind("0.0.0.0:3000").unwrap();
            loop {
                let conn = listener.accept().await.unwrap();
                // Glommio spawn 的任务同样不可以跨 executor
                glommio::spawn_local(async move {
                    handle_connection(conn).await;
                }).detach();
            }
        });
    
    handle.join().unwrap();
}

// 多核利用：为每个物理核心创建独立 executor
fn spawn_pool(num_cpus: usize) -> Vec<glommio::ExecutorHandle<()>> {
    (0..num_cpus).map(|i| {
        LocalExecutorBuilder::new(Placement::Fixed(i as u32))
            .name(&format!("worker-{}", i))
            .spawn(move || async move {
                // 循环处理这个核心上的所有任务
                run_worker_loop(i).await;
            })
    }).collect()
}

4.2 Glommio 的独特能力

预注册缓冲区（Buffer Registration）：与 io_uring 的 IORING_REGISTER_BUFFERS 结合，避免每次动态分配：

// Glommio 预注册缓冲区：一次注册，终身复用
let mut pool = glommio::io::SharedBufPool::new(1024, 4096)?; // 1024个4KB缓冲区
let registration = glommio::io::register_buffers(&mut pool)?;

// 之后的 read/write 操作直接从池中取缓冲区
// 省去"分配→填充→提交"链路中的 2 次 syscall
let buf = pool.try_obtain().ok_or_else(|| io::Error::new(io::ErrorKind::Other, "池空"))?;
let (buf, res) = conn.read_with registration_id, buf).await;
let n = res?;
// ... 处理 buf ...
pool.release(buf); // 归还而非释放

五、正面交锋：性能深度对比

5.1 测试环境与方法论

5.2 TCP 回 Echo 基准（p99延迟，64 字节 payload, 100K QPS）

解读：io_uring 绑定的运行时（Monoio/Glommio）在 p99-p999 段大幅领先 = 2-3x 延迟优势，代价是无法跨核负载均衡。

5.3 NVMe 直写带宽（O_DIRECT 8KiB 随机写, QD=128）

SQPOLL 模式下 Monoio 实现了接近零系统调用的 I/O 提交——这是 epoll 方案不可能达到的理论极限。

5.4 并发任务数 vs 内存占用对比（100K 并发 TCP 连接空闲态）

六、选择指南：不是好坏，而是匹配

如果你还在纠结，以下是决策树：

Q1: 你的服务主要瓶颈是 CPU 计算还是 I/O 等待？
  ├── 主要是 I/O（网络代理、KV 存储、消息队列）
  │   ├── Q2: 是否部署在 Linux 5.10+？
  │   │   ├── 是
  │   │   │   ├── Q3: 是否追求极致 p99 延迟？
  │   │   │   │   ├── 是 → Monoio
  │   │   │   │   │     （绑核 + io_uring SQPOLL + 固定缓冲区）
  │   │   │   │   └── 否 → Tokio (io_uring 特性 + multi_thread)
  │   │   │   │         （兼容性最佳，生态最丰富）
  │   │   │   └── Q4: 是否需要多核共享状态通信？
  │   │   │       ├── 是 → Glommio（显式消息通道）
  │   │   │       └── 否 → Monoio（更简单的心智模型）
  │   │   └── 否 → Tokio（选择 epoll 后端）
  │   │
  │   └── 混合负载 → Tokio spawn_blocking 分流 + io_uring net
  │
  └── 主要是 CPU 计算 → 任何运行时无所谓，work-stealing 够用了
      └── Tokio（最大化 CPU 利用率）

七、生产环境踩坑实录

7.1 Tokio：TASK_DEREGISTERED 噩梦

// ❌ 经典死锁：block_on 嵌套
async fn outer() {
    tokio::task::block_on(async {
        // 在非 runtime 线程调用 block_on: OK
        // 在 runtime 线程内部调用 block_on: 死锁（当前线程被占用，无法驱动子任务）
        inner_outer().await;
    });
}

// ✅ 替代方案：用 channel 而非嵌套运行时
async fn outer_fixed() {
    let (tx, rx) = tokio::sync::oneshot::channel();
    tokio::spawn(async move {
        let result = compute().await;
        tx.send(result).unwrap();
    });
    let result = rx.await.unwrap();
}

7.2 Monoio：跨线程共享状态的代价

// Monoio 的数据结构不能跨线程 Sync
// 如果需要全局计数器，三种方案：

// 🥇 方案一：线程局部 + 最终合并（推荐）
thread_local! {
    static LOCAL_COUNTER: RefCell<u64> = RefCell::new(0);
}
fn increment_count() {
    LOCAL_COUNTER.with(|c| *c.borrow_mut() += 1);
}
// 定时器定期 flush thread_local → shm 或日志

// 🥈 方案二：独占一个线程做原子计数（适合高频）
// 单独 spawn Monoio runtime + 通过 channel 发送计数 delta
static GLOBAL_COUNT: AtomicU64 = AtomicU64::new(0);
// 每次 increment 跨线程发送消息，延迟较高

// 🥉 方案三：用 io_uring 直接读/写共享内存映射（extreme）
// Monoio 提供 SharedMemory trait，允许多个 runtime 实例映射同一文件
// 但写入同步需要手动实现（CAS + memory barrier）

7.3 Glommio：文件描述符穿越

// Glommio 的 TCP 连接不能跨 executor 传递
// 如果你在 CPU 0 上 accept，传给 CPU 1 的 executor 处理 → 编译错误！

// 解决：在 accept 的同一核心处理，或使用预分配连接池
use glommio::{io::ScheduledSource, spawn_local};

async fn bind_per_core(port_base: u16, core_id: usize) {
    let ex = glommio::executor();
    let my_placement = ex.affinity();
    assert_eq!(my_placement, core_id);
    
    // 确保 TLS 在这个核心上被 clone 的可 Send 类型
    let listener = glommio::net::TcpListener::bind(format!("0.0.0.0:{}", port_base + core_id as u16)).unwrap();
    loop {
        let conn = listener.accept().await.unwrap();
        // 这个 spawn_local 保证 conn 永远留在当前核心
        spawn_local(handle(conn)).detach();
    }
}

八、未来展望：Linux 7.x 与 Rust 2026 的化学反应

站在 2026 年 9 月的节点，几个趋势正在加速分化：

1. io_uring 的成熟：Linux 7.x 已支持 IORING_SETUP_SUBMIT_ALL 和 register_ring_fd，Monoio/Glommio 的"零 syscall"路径将更安全稳定。Tokio 也已在 1.40 中对 io_uring 后端做了重大重写。
2. io_uring 与uring_v4：新提出的 uring_v5 协议草案引入了bind-to-core SQ/CQ，专门为线程绑定运行时设计——这意味着 Monoio 不需要自己在用户态做绑核补偿。
3. Rust 语言的异步改进：async closures、static async trait、return position impl Trait in traits (RPITIT) 已在 nightly 可用，2026 年下半年有望稳定。这些特性让 Monoio 的 !Send 约束变得更加可管理。
4. 调度器专业化：Tokio 团队正在开发 tokio-perf 插件系统，允许运行时根据场景动态切换调度策略（work-steeping / thread-per-core），三大运行时的界限可能逐渐模糊。

结语

Rust 异步运行时没有"银弹"，只有适配。Tokio 适合 90% 的场景——它不是最快的，但它是最可靠、生态最完整的。Monoio 是存储引擎和网络的"手术刀"，为 p999 而极致优化。Glommio 则是我心中的"优雅中间态"——如果你能接受 share-nothing 编程模型，它的抽象层次比 Monoio 更高，又比 Tokio 更接近硬件本质。

技术在演进，但底层选择逻辑不变：先度量，再选择，最后调优。在你决定用 Monoio 换掉 Tokio 之前，请先证实 bu 火焰图确实告诉你"epoll 系统调用是瓶颈"——大多数情况下，不是。