分片任务与数据模型

为什么需要分片

当文件从几 MB 变成几百 MB，单次上传的失败成本会非常高。用户等了十分钟，一次网络抖动全部重来——这是文件系统最直观的体验问题。

分片上传的思路很简单：把一个大文件拆成多个小块，每个分片独立上传，失败时只重传失败的部分。

初始化上传任务 -> 上传 chunk 1..N -> 查询已上传分片 -> 合并文件 -> 校验完成

上传四步

分片上传一般分成四步：

1. 初始化任务：客户端提交文件名、大小、hash、分片大小，服务端返回 upload_id。
2. 上传分片：客户端按序或并发上传分片，服务端记录编号、大小、hash 和位置。
3. 查询进度：断线重连后查询哪些分片已上传。
4. 完成合并：所有分片到齐后，服务端合并文件并校验整体 hash。

数据模型：两张表

分片上传的关键，是把上传状态变成可查询、可恢复、可清理的数据，而不是散落在临时目录里的文件：

upload_task（1）
  └── upload_part（N）：每个分片一行，编号有序

亲手体验一下

下面这个模拟器可以演示分片上传：开始上传、模拟网络失败、观察只重传失败分片、最后合并完成：

这一章引入的复杂度

分片上传显著提高大文件成功率，但也带来新复杂度：

• 上传状态从「一次请求」变成「多步骤状态机」。
• 需要处理临时分片的清理（过期、放弃、失败）。
• 需要并发控制和限流（下一节）。
• 合并前必须做完整校验（再下一节）。

把状态做成数据、把校验做严，这些复杂度就是可控的。

下一节看分片的并发与限流——并发数不是越大越好。

上一章节

分片上传

通过任务初始化、分片传输、合并校验来提升大文件上传成功率

下一章节

并发上传与限流

分片不一定要按顺序，但并发数不是越大越好