1. 队列设计背景：下载管理场景、核心矛盾、设计目标与约束
1.1 下载管理场景
现代下载管理器需要同时处理数百至数万个下载任务，每个任务可能来自不同协议（HTTP、FTP、BT）、不同文件大小（KB 到 TB）、不同网络环境（Wi‑Fi、4G、代理）。典型的运行场景包括：
- 批量导入：用户一次添加数百个链接，系统需立即响应但不必立即启动所有下载。
- 优先级调度：用户可动态调整任务顺序（置顶、推迟、暂停）。
- 断点续传与重试：网络中断后自动恢复，失败任务按指数退避重试。
- 并发控制：限制同时下载数（例如 3 个），避免带宽和系统资源耗尽。
- 任务持久化：应用重启后恢复队列状态，不丢失进度。
关键观察：这些场景对队列的核心要求是 高吞吐 + 动态调整 + 可恢复，而非简单的先进先出（FIFO）。
1.2 核心矛盾
传统队列模型（消息队列、线程池队列）无法直接满足下载管理的独有矛盾：
| 矛盾维度 | 理想需求 | 现实约束 |
|---|---|---|
| 调度灵活性 | 支持优先级、依赖、延迟启动 | 队列必须同时保持 O(1) 入队/出队效率 |
| 并发与资源 | 按任务类型、带宽、连接数动态限流 | 系统不可预测的真实网络延迟与失败 |
| 持久化与性能 | 百万级任务安全存储，重启快速加载 | 磁盘 IO 和序列化开销不能影响实时调度 |
| 状态迁移 | 支持等待→下载→暂停→完成→失败 的复杂状态机 | 并发更新状态时需保证原子性，避免脏读 |
这些矛盾导致简单的 BlockingQueue<Task> 无法胜任，必须设计一个支持动态优先级、可持久化、且具备限流机制的专用队列。
陷阱提示：不要试图用 Redis 列表 + 定时扫描来实现队列——缺少优先级排序、原子状态迁移和本地持久化一致性的保障。
1.3 设计目标与约束
架构方案型课程必须在本章明确后续设计的“标的”：
- 目标 1 – 调度公平性：高优先级任务平均等待时间 ≤ 低优先级的 1/10。
- 目标 2 – 高可用恢复：进程崩溃重启后，队列恢复时间 ≤ 3 秒（100 万任务时）。
- 目标 3 – 动态适应：运行时修改并发数、优先级、重试策略，不影响正在执行的任务。
- 约束 1 – 资源限制：最大并发下载数 ≤ 系统 CPU 核心数 × 4，同时连接数 ≤ 128。
- 约束 2 – 数据一致性：状态变更必须持久化到本地存储，允许最终一致性窗口 ≤ 500 ms。
- 约束 3 – 协议无关：队列必须支持任意下载引擎实现，不绑定具体传输协议。
1.4 系统上下文与结构
下图展示下载队列在整个下载管理系统中的位置，以及其与周边模块的边界：
1.5 章节小结
本章明确了下载队列的边界：它不是一个通用消息队列，而是专为下载管理设计的调度+持久化+状态管理复合组件。后续章节将逐一深入分层架构、组件职责、关键数据流与一致性策略。
思考点：如果队列在持久化前崩溃，丢失了刚添加的任务，这种场景是否允许？设计目标中的“最终一致性窗口 ≤ 500 ms”对应了怎样的降级策略？