服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

公司的用户上传 2GB 的视频文件到网盘，传了 80% 的时候网络断了。页面刷新后，上传列表里空空如也——前端状态丢失，后端也没记录哪些分片已经上传成功。用户只能从头再来。2GB 的文件，从头再传一遍，用户的耐心也从头归零。 分片上传天然支持断点续传——前提是你知道哪些分片已经上传成功了。不知道的话，就只能全量重传。今天聊聊怎么用 Redis 记录每个分片的上传状态，让网络断了之后从断点秒级续传，而不是从头开始。 分片上传的断点问题 分片上传的流程很简单：前端把大文件切成 N 片，逐片上传。后端每收到一片就存起来。 文件 2GB → 切 200 片 × 10MB → 逐片上传 如果第 150 片上传失败（网络断了、服务器卡了），最好的情况是从第 150 片继续传。但前端不知道自己传了哪些片——因为前端的进度存在内存里，页面一刷新就没了。 后端需要提供一个能力：告诉前端哪些分片已经上传成功了。 Redis 记录分片状态 给每个上传任务一个 uploadId（UUID），用 Redis 的 Set 记录已上传的分片编号： // 记录分片已上传 redis.sadd("upload:....

公司的网盘系统出了个诡异的 bug。用户 A 上传了一个 500MB 的视频文件，分成了 100 个分片。上传到第 80 片的时候，用户 B 也上传了一个同名的视频文件——可能是一个修订版。两个上传请求同时往同一个文件名下写分片，最后合并出来的文件里混了一半 A 的内容和一半 B 的内容。文件打不开，用户投诉。 分片上传的并发冲突比单文件上传难处理得多。单文件上传一次 HTTP 请求就完成了，有冲突也容易看出来。分片上传是几十上百个 HTTP 请求，冲突可能发生在任何时候——第一个分片被 B 覆盖，最后一个分片还是 A 的。结果就是一个"拼接怪物"。 今天聊聊怎么用分布式锁把分片上传的整个过程保护起来，确保同一时间只有一个上传任务在操作同一个文件。 冲突是怎么发生的 分片上传的流程通常是这样： 1. 前端发起分片上传 → 后端返回 uploadId 2. 前端逐个上传分片 → 每片带 uploadId + 分片号 3. 全部分片上传完 → 发起合并请求 两个人的冲突： 时间线： 用户 A 用户 B T1 创建 uploadId=A1 T2 上传分片 0~50 T3 创建 uploa....

做文件上传系统的同学肯定都遇到过这个问题：多个用户同时上传同名文件，或者同一个用户在多个设备上上传同一个文件，结果文件被覆盖了，或者文件内容混乱了。这些问题听起来像是低级 bug，但背后折射出的是分片上传场景下并发控制的复杂性。 特别是在大文件分片上传场景下，一个文件被分成几十个甚至上百个分片上传，如果没有做好并发控制，后果可能是： 用户 A 的文件被用户 B 的分片覆盖，导致文件损坏 同一个上传任务被多个请求同时处理，造成资源浪费 合并时出现竞争条件，最终文件内容混乱 文件状态不一致，有的说上传成功，有的说还在上传中 今天我们就来聊聊分片上传并发冲突的架构设计，使用分布式锁和状态机来彻底杜绝并发问题。 分片上传的并发痛点 先来分析一下分片上传的并发痛点在哪里。很多团队会说："我们用了唯一ID，每个文件都有唯一的 fileKey，怎么还会有冲突？" 实际情况远比这复杂： 1. 同名文件上传冲突 多个用户同时上传同名文件： 用户 A 正在上传 file.txt 用户 B 也上传 file.txt 如果只按文件名来做 key，两个文件会互相覆盖 2. 同一个上传任务被重复触发 用户....