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

公司的网盘系统出了个诡异的 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. 同一个上传任务被重复触发 用户....