Rust 高并发实战:从 Future 到生产排障的 6 期路线
Rainy
雨落无声,代码成诗 —— 致力于技术与艺术的极致平衡
4 MIN READ•... VIEWS
Rust 消灭了一大类内存数据竞争,但生产高并发仍需要主动设计容量、取消、背压、锁顺序和故障恢复。
这个系列使用 Rust + Tokio + Axum 构建与 Go 系列相同的高扇出聚合服务。相同的负载模型便于比较语言差异,文章重点则放在 Future、协作式调度、Send/Sync、取消安全和异步诊断。

这张由 ImageGen 生成的系列概念图以铜橙色任务胶囊表现 Future 状态,以环形轨道表现 reactor/waker,以透明闸门表现 Semaphore 与取消边界:任务只有在资源就绪并取得许可后,才进入右侧有限的执行核心。
系列地图
| 期数 | 主题 | 核心问题 | 实战产物 |
|---|---|---|---|
| Rust-1 | 所有权与并发安全 | Send/Sync、线程与 async 的边界 | 并发成本模型与类型实验 |
| Rust-2 | Future 与 Tokio | Poll/Waker、task 调度和结构化并发 | fan-out、select、JoinSet |
| Rust-3 | Axum 生产服务 | deadline、Semaphore、连接与停机 | 有界聚合 API |
| Rust-4 | 状态与取消安全 | Mutex、channel、atomic、副作用 | actor、事务状态机、Loom |
| Rust-5 | 阻塞隔离与性能 | spawn_blocking、CPU、内存与 runtime | tracing、tokio-console、perf |
| Rust-6 | 压测与线上排障 | task 泄漏、死锁、池耗尽怎么查 | 故障注入与生产 Runbook |
贯穿全系列的工程约束
- async task 数、channel 深度、连接数和 blocking work 都必须有界;
- handler 的 Future 生命周期覆盖其所有子工作,不默认 detached spawn;
- timeout 只是停止等待,外部副作用必须幂等、事务化或可补偿;
- 锁和 semaphore 的等待时间必须可观测;
- 过载时优先稳定已接纳请求,而不是追求零拒绝;
- safe Rust 之外仍要测试死锁、逻辑竞态和 atomic 协议。
最终实战架构
图中每个 Future 都属于 handler 或明确的后台任务 owner;总 timeout drop handler Future 时,子 Future 与 RAII permit 一起释放。已经提交到数据库、网络或 spawn_blocking 的副作用不会自动回滚,所以 Rust-4 会进一步使用事务状态机、幂等键和补偿保证业务正确性。
Tokio worker 只执行短 async poll,阻塞 I/O 和 CPU work 分别进入受限资源池。Rust-5、Rust-6 会用 tracing、tokio-console 与 perf 区分“task 正在运行”和“task 正在等待”。
学习方式
每期代码都区分 I/O 并发、CPU 并行和资源排队。压测时同时记录到达率、P99、task 数、许可等待、连接池、RSS 与 CPU throttling,避免用单一 QPS 得出错误结论。