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

公司做视频平台，用户上传一个 2GB 的素材文件，进度条跑到 95%，浏览器崩了。刷新页面重新上传，进度条又从 0% 开始。用户直接关了页面，再也没回来。 后来加了断点续传。用户重新打开页面，后端一问 Redis——"这个文件你上次传了 38 个分片，还差 2 个"，直接从第 39 片开始传。3 秒搞定，用户甚至没注意到断过。 大文件上传这种事，不怕慢，怕的是断了之后要从头再来。今天聊聊怎么用 Redis 记录分片上传状态，实现真正的秒级续传。 先说清楚：为什么大文件上传非得分片 一个 2GB 的文件你不可能一口气传上去。网络稍微波动一下，整个 HTTP 请求就废了，2GB 白传。 所以业内的标准做法是分片上传：客户端把文件切成小块（比如每片 5MB），一片一片发。服务端收齐所有分片后，按顺序合并成完整文件。 客户端： 文件 2GB → 切成 400 片，每片 5MB 上传过程： 上传第 1 片 ✓ 上传第 2 片 ✓ ... 上传第 399 片（网络断了！）✗ 上传第 400 片 ✗ 服务端： 收到 398 片 等待第 399、400 片（永远等不到） 分片之后，问题就变成了....

传统文件上传的痛点 在我们的日常开发工作中，经常会遇到这样的文件上传难题： 用户上传几个G的视频文件，网络中断导致上传失败，需要重新开始 大文件上传占用服务器大量带宽，影响其他用户访问 相同文件重复上传，浪费存储空间和带宽 上传进度无法实时显示，用户体验差 服务器内存被大量上传请求占满，导致服务不稳定 传统的单文件上传方式在面对大文件时显得力不从心。今天我们就来聊聊如何构建一个高效的大文件上传系统。 解决方案核心思路 1. 文件分片上传 将大文件切分成多个小片段，分别上传，降低单次请求的压力。 2. 断点续传 记录上传进度，网络中断后可以从断点继续上传，避免重新上传。 3. MD5校验秒传 通过MD5校验判断文件是否已存在，实现秒传功能。 4. 并发控制 合理控制并发上传的分片数量，平衡上传效率和服务器压力。 核心实现方案 1. 文件分片处理 @Service public class FileChunkService { public List<FileChunk> splitFile(MultipartFile file, int chunkSize) { List....