华为云 OBS 分片上传实战：大对象上传的失败重试与断点续传

在处理 GB 级乃至 TB 级对象时，直接使用简单上传（PutObject）会遇到两个硬限制：单次请求体大小上限 5 GB，以及网络抖动导致的整单失败重传。华为云对象存储服务 OBS 提供的分片上传（Multipart Upload）正是为这类场景设计的。本文记录一次数据迁移项目中的实测经验，重点说明分片大小选择、失败重试与断点续传的实现思路。 ## 一、分片上传的基本流程 分片上传把一个大对象拆成若干分片（Part），每个分片单独上传，全部成功后再通过 CompleteMultipartUpload 合并。整个流程分三步： 1. InitiateMultipartUpload：初始化上传，返回 uploadId。 2. UploadPart：逐个上传分片，每个分片返回 ETag。 3. CompleteMultipartUpload：提交分片列表，OBS 合并为最终对象。 如果任意一步失败，可以 AbortMultipartUpload 放弃，或继续重试未完成的分片，这正是断点续传的基础。 ## 二、分片大小的取舍 分片大小直接影响并发度与失败成本： - 分片过小：请求数过多，元数据开销大，QPS 容易成为瓶颈。 - 分片过大：单个分片失败需要重传的代价太高，内存占用也大。 官方推荐范围是 1 MB 至 5 GB，常见做法是 64 MB 至 128 MB。迁移 8 TB 日志数据时，使用 128 MB 分片配合 8 并发，单流吞吐稳定在 40 MB/s 左右。 ## 三、失败重试的三个层次 **第一层：网络级重试。** 对 5xx、连接重置、超时等可重试错误做指数退避重试，建议最多 5 次，退避间隔按 2 的幂递增。 **第二层：分片级重试。** 记录每个分片的序号与 ETag，失败后只重传该分片。这里有个坑：ETag 只有在分片上传成功后才会返回，因此需要把 uploadId、分片序号、本地偏移、文件长度一并持久化。 **第三层：断点续传。** 在本地维护 manifest 文件，记录已完成分片。进程重启后读取 manifest，跳过已完成的分片。 ## 四、manifest 的最小实现 manifest 可以用 JSON 存储，字段包括 bucket、key、uploadId、partSize 以及已完成的分片列表。上传成功后把每个分片的 ETag 写入映射，重试时优先复用。 ## 五、容易踩的坑 1. UploadPart 的 partNumber 从 1 开始，且必须连续，否则 Complete 会失败。 2. Complete 之后 uploadId 失效，不能再用同一个 uploadId 重复提交。 3. 未完成的分片会产生存储费用，建议给未完成的 uploadId 配置生命周期规则自动清理。 4. ETag 不一定是 MD5，开启服务端加密后 ETag 是加密后的校验值，不能用它做本地文件校验。 ## 小结 分片上传的核心是把大任务拆小，把失败成本压到单个分片。配合 manifest 做断点续传，可以让大对象上传具备断网恢复能力。在华为云 OBS 上，这套方案配合并发上传可以稳定跑满带宽，是数据迁移场景的推荐做法。