FluxDown 智能分段与 Work Stealing 抢速机制
为什么传统多线程下载器会被慢点卡死
传统分段下载器的做法是：文件启动时就切成 N 段（比如 16 段），每段一个连接，从头到尾跑完，中间不调整。这种做法有一个结构性弱点——只要其中某一段的源站镜像特别慢，它会拖到最后才能合并，整个下载速度就被那一段锁死了。
FluxDown 的引擎在运行时重新平衡分段。核心思路是「慢的被劈成两半，快的继续跑」，配合 Work Stealing 让空闲的连接去救援被慢点拖住的分段。
引擎的四件事
FluxDown 的下载引擎在一个文件上同时做四件事：
| 动作 | 什么时候触发 | 做了什么 |
|---|---|---|
| 按需分段 | 下载启动时 | 不像固定 N 段，从 1 连接开始，逐步增加到服务器能接受的连接数，再按需切成更多分段 |
| Work Stealing | 出现空闲 worker 时 | 空闲连接自动挑当前最慢的那个仍在传输的分段，劈成两半，自己接走后半段 |
| 连接复用 | 分段切换时 | 保持 Keep-alive socket，让它跳到下一个分段，不重新握手 |
| 按域学习 | 每次下载后 | 记下该域最佳连接数与 warm-start 提示，下次同域下载直接用上 |
Work Stealing 的触发条件很简单：只要某个 worker 先跑完自己那一段变成空闲，它就会主动介入，不让自己闲着。这意味着「慢段永远不会拖到最后」——因为总有别的连接先干完。
与固定多线程的对比
| 维度 | 传统固定 N 线程 | FluxDown 运行时分段 |
|---|---|---|
| 分段时机 | 启动时一次性切完 | 启动时先少后多，运行中继续劈 |
| 慢段救援 | 无——慢的拖到最后 | 空闲 worker 自动劈慢段并接管尾部 |
| 连接复用 | 多为每个分段新开 | Keep-alive 在分段之间跳 |
| 域适配 | 所有域一套参数 | 每个域独立记录最佳连接数 |
| 适用场景 | 单镜像源、带宽对称 | 多镜像混合、有慢速节点、网络抖动 |
IDM 也有类似的动态分段逻辑，但它只在 HTTP 协议上可用，BT 和 eD2K 并不支持。FluxDown 把这套机制做到了所有六种协议上，一个队列里的所有任务都共享这个调度器。
实现语言：Rust + Tokio
整个引擎用 Rust 写，异步运行时是 Tokio。选择 Rust 的直接收益是零开销抽象——分段、抢速、哈希校验这些热路径上没有 GC 停顿，每秒可以处理的分段调度次数远高于 GC 语言。引擎内部状态用 SQLite 持久化（见 SQLite 持久化），但调度层本身是纯内存的，不被 IO 锁阻塞。