解读

在国内高并发后端、网关、实时消息系统的面试中，tokio 几乎是 Rust 异步性能的“必考题”。面试官问“如何调优 tokio 调度器”，并不是想听你背参数，而是考察三点：

1. 是否真正理解 tokio 工作窃取（work-stealing）调度模型与 CPU 核心绑定的关系；
2. 能否通过 可观测性指标定位瓶颈（调度延迟、任务饥饿、队列倾斜）；
3. 能否结合业务场景给出 量化调优步骤（线程数、任务划分、IO 驱动器、资源隔离），并权衡吞吐量与延迟。
   回答时务必先讲原理，再给工具，最后落到“数字”——国内面试官最爱问“你线上到底压到多少 QPS、P99 延迟降了多少”。

知识点

1. tokio 调度器架构
   • 全局 Multi-thread scheduler（默认）与 Current-thread scheduler 两种模式
   • 每个 worker 线程维护本地双端任务队列，cross-deque 窃取 算法减少锁竞争
   • LIFO slot 与 FIFO inject queue 两级队列，保证高优先级任务延迟 < 10 µs
2. 关键配置项
   • worker_threads：默认等于 CPU 核心数，IO 密集型可超配 1.5~2 倍，计算密集型保持 1:1
   • max_blocking_threads：阻塞线程池上限，默认 512；MySQL/JDBC 同步驱动需调大，防止耗尽
   • event_interval：每轮 IO 驱动器批量事件数，默认 61；万兆网卡+小包可提到 256，降低 syscall 次数
   • global_queue_interval：任务回退到全局队列前的本地轮数，默认 61；任务粒度极细（< 2 µs）可调小到 31，减少窃取
3. 可观测性
   • tokio-console（需开启 tokio_unstable）实时查看 任务调度延迟（busy time / idle time / total time）
   • metrics crate 导出 poll_duration_histogram、budget_forced_yield_count
   • perf/flamegraph 抓 调度器热点：tokio::runtime::scheduler::multi_thread::worker::run 占比应 < 5 %
4. 业务层优化
   • 任务分片：CPU 计算 > 100 µs 务必使用 spawn_blocking 或 rayon，避免阻塞 worker
   • 公平性：channel 无界队列容易让单个协程饿死，采用有界+backpressure
   • 资源隔离：同一进程内多业务域，使用 独立 Runtime（Builder::new_multi_thread().worker_threads(n)），防止高优业务被后台批处理挤占

答案

线上调优我按“四步法”落地，曾把网关 P99 从 22 ms 压到 4.3 ms，CPU 利用率提升 38 %：

1. 选模式：压测证明网关属于 IO 密集型，保持默认 multi_thread，worker_threads = 逻辑核 × 1.5（16 核机器设 24），防止 epoll 空转。
2. 调阻塞池：同步 Redis/MySQL 调用走 spawn_blocking，max_blocking_threads = 200（压测得出 200 时阻塞排队 0），避免 tokio 阻塞池耗尽导致的 “thread ‘tokio-blocking-driver’ panicked”。
3. 细粒度参数：
   • event_interval = 128：小包高并发场景，epoll_wait 返回事件批处理翻倍，syscall 次数从 110 k/s 降到 45 k/s；
   • global_queue_interval = 31：网关任务平均耗时 15 µs，调小后 跨线程窃取次数下降 18 %，CPU 迁移减少。
4. 可观测闭环：
   • 灰度开启 tokio_unstable，用 tokio-console 发现某队列 busy 98 %、idle 0.2 %，定位到一个大 JSON 序列化任务占满一个 worker；
   • 将该任务改为 spawn_blocking 后，** busiest worker busy 时间降到 62 %**，P99 延迟直接下降 12 ms。
     最终 16 核云主机 QPS 从 28 k 提升到 45 k，P99 延迟 4.3 ms，CPU 利用率 92 %，满足国内云厂商 SLA ≤ 5 ms 要求。

拓展思考

1. 混合负载隔离：如果进程内既有 高优 API 接口 又有 低优日志批刷，可启动 双 Runtime：
   • api_runtime：worker_threads = 核数，优先级高；
   • bg_runtime：worker_threads = 2，绑定到 cpuset 末两个核；
     通过 crossbeam channel 做边界通信，避免低优任务挤占高优调度。
2. 无锁队列自研：当任务粒度 < 1 µs 且核心数 > 32 时，tokio 默认窃取算法会出现 cache-line 乒乓；可实验 glommio 或 monoio（基于 io-uring 的单线程模型），在 阿里云第七代 ECS 上测得 P99 再降 30 %，但需放弃标准 tokio 生态，权衡成本。
3. 编译期调优：开启 codegen-units = 16 + lto = "thin"，结合 mold 链接器，把调度器热点函数（如 poll 虚表调用）内联到 同一 text segment，icache miss 下降 5 %，可将极限 QPS 再抬 3~4 %，适合国内“双十一”大促极限压测场景。