Tokio 只保进度不保顺序
Tokio Gives Progress, Not Ordering: Scheduling 1M Tasks
我们在处理 100 万 Tokio 任务时发现，早期创建的任务并不一定先被调度。Tokio 的调度器只保证进度，不保证顺序，导致早期事件的任务被延迟，内存峰值飙升。通过引入 Semaphore 限制并发事件数，我们既保持了吞吐量，又显著降低了内存占用。这并非 Tokio 的缺陷，而是应用层需要明确公平性边界。
Tokio 保证的是进度，而不是顺序；任务创建早不等于先被轮询，更不等于先完成。
- jandrewrogers
我觉得大家都是在吃尽苦头后才学到这些教训的。我就是这样。在真实系统中设计健壮调度器的难点，源于两个特性的交汇：理论上最优的调度方案无法保证任务延迟的上限，而运行时调度本身是 AI 完备（AI-complete）的。
在实践中，我们需要延迟是有界的，而且往往要求非常严格。调度器的实现必须在有限的内存和计算预算内运行，而这并不是任何需要“AI 完备”算法的系统所具备的特性——你最多只能做到极其狭隘且非常宽松的近似。
受限于这些约束，任何通用调度器要么脆弱不堪，要么效率低下（通常两者兼有）。与此同时，除了最简单的应用外，为特定实现设计专用的调度器绝非易事。文献中最接近的简单例子是缓存替换算法，这属于调度中非常狭窄的一种情况，其中无界延迟并不是问题。
历史上，解决这类设计问题通常被归入“延迟隐藏”（latency-hiding）的范畴（例如在 HPC 领域）。针对软件的文献少得可怜，而硬件的许多约束和特性并不适用于软件。
- excerionsforte
你很早就明白 Tokio 不保证顺序，因为顺序性正是高性能的敌人之一。要么自己实现方案，要么使用第三方方案，付出相应的代价，但你得到的就是你所期望的。
futures_orchestra (https://crates.io/crates/futures_orchestra) 解决了限制并发、排队和排序的问题。说实话，我觉得我有点低估它了，哈哈。