医院里的PACS系统天天都在上传CT、MR、DR影像单份DICOM文件动不动就是几十上百MB遇到CT薄层扫描甚至能到几百MB到1GB。一线医生点完上传等半分钟进度条还卡在半路要是网络抖一下整个流程直接报废重来。我们科室早年用SpringMVC做影像管理平台就被这个上传体验折磨得不轻。今天这篇就手把手拆一版能落地的方案如何基于SpringMVC这套经典技术栈实现DICOM影像大文件的秒传和断点恢复让一线操作人员从“等待上传”变成“秒级完成”。这套方案的核心思路一句话总结就是前端算指纹的结果决定是“秒传”还是“真的传”。先对文件做MD5后端发现同样的文件已经存在直接返回成功这就是秒传如果文件没传完后端告诉前端“你已经传了哪些分块”前端只补传缺失部分这就是断点恢复。整个链路我用SpringMVC Redis MinIO 前端分块计算来组合实现代码量不大但非常管用。适合谁看两类人。一类是做医疗信息系统、影像归档系统、远程诊断平台的后端开发需要对接DICOM大文件上传场景另一类是做成套系统、负责文件存储选型的技术负责人想在不重写技术栈的前提下把上传体验和存储可靠性同时提上来。下面内容不绕弯子从拆解问题开始到组件选型、核心实现、坑点排查全部按真实项目里的经验来。1. 问题拆解DICOM影像文件为什么必须走“秒传”和“断点恢复”1.1 医疗影像上传的核心痛点DICOM文件不像普通办公文档它自带一堆医疗元数据而且通常是一个患者一次检查会生成一个序列每个序列里有几十张到上千张图像。一次检查的总数据量很容易冲上500MB到2GB。在院内网络环境尚可时上传量大只是“慢”但到了跨院区、医联体远程诊断、或者医生通过公网访问的体检车场景网络带宽和稳定性都很差一次上传基本等于“风险操作”。更麻烦的是DICOM文件还必须保证完整性和可校验性。影像科一旦发现某张图像缺失影响的是诊断结论。所以这种场景不能简单粗暴地“用HTTP multipart把文件响一声丢上去”必须有额外的校验机制文件是否完整、重组之后DICOM Tag是否可读、患者检查号是否匹配等。这就意味着“上传-校验-入库”三个步骤必须拆开每一步都要可以重试、可恢复。1.2 秒传与断点恢复的技术本质秒传不是魔法。它的本质是跳过数据传输只完成状态确认和逻辑入库。前端把文件指纹MD5/SHA1发给后端后端在存储系统里查一下发现这个文件完整存在那就不需要再传直接返回“上传成功”前端界面显示秒完成。断点恢复的本质是让上传任务实现“分块可寻址”。整个文件被切成多个分块每一块都有唯一编号。后端在Redis和数据库里记录哪些分块已经上传、大小是否正确、校验和是否一致。前端再次上传时不用重新整个文件只查询缺失分块清单把剩余分块补齐就行。这两者合起来的体验是网络断了不怕断点续传再次重复上传同一个文件秒传多人重复传同一个影像秒传。这正好对上了医疗场景里的高频行为同一个DICOM文件常被反复上传到不同批次、不同申请单里而多机构协同又会重复采集数据。2. 组件选型基于SpringMVC整合哪些组件实现2.1 前端计算指纹与文件分块策略前端要做两件事算文件MD5、把文件切成物理分块。算MD5在浏览器端用SparkMD5这一类库基于FileAPI读取ArrayBuffer边读边算大文件也不会把内存打爆。分块我建议按固定大小分片比如4MB或8MB一块。为什么用4MB因为太小会导致HTTP请求数量太多太大又会让断点恢复的粒度太粗网络中断重传的冗余数据多。4MB在大多数局域网和公网环境里是最好的折中方案实际测试下来100MB文件也就25个分块请求数量完全可控。文件分块之后每个分块需要包含关键参数文件唯一标识MD5、分块序号、总分块数、分块大小。上传分块时同时带上这个分块的MD5后端就能校验每个分块的完整性。2.2 后端判断秒传与分块合并的核心实现后端组件我用的组合是SpringMVC Controller层 Service层 Redis做任务状态 MinIO做对象存储。SpringMVC负责接口路由和参数绑定Redis存上传任务进度和分块状态MinIO负责把分块和最终合并后的文件落盘。这套组合的好处是SpringMVC完全不需要换仅靠自定义接口和组件化封装就把一个原本只能传小文件的后端改造成了可秒传、可断点的大文件上传系统。这里要特别提到“组件”二字。很多人以为组件就是引个第三方库但实践中我把整个上传能力拆成了三层组件UploadTokenService负责生成上传票据和文件关系映射ChunkStorageService负责分块的读写和合并UploadProgressService负责从Redis里读写进度。这样Controller里只做参数接收和状态返回不堆积业务逻辑。后续如果要接不同的对象存储只需要替换ChunkStorageService的实现不用动接口。3. 核心细节解析从分块上传到断点恢复的关键机制3.1 秒传的实现流程先算MD5再传文件秒传的前置条件是后端必须有一个“文件指纹索引”。流程如下患者上传DICOM文件时先通过前端计算出整个文件的MD5然后调用后端接口/upload/register提交参数fileMd5, fileName, fileSize。后端收到后先查数据库上传记录表如果这条MD5记录已经存在且状态为“已完成”就直接返回“秒传成功”如果存在但状态是“未完成”就返回已上传分块序号如果不存在就创建一条新的上传任务记录返回“需要上传”及分块大小建议。这个流程里最容易被忽略的是秒传不只是省上传时间还省存储空间。因为同一个MD5的文件后端只保留一份物理文件所有关联业务记录都引用同一个存储对象ID。这在PACS系统里尤其重要因为同一患者的同一序列经常被多次申请、多次调阅、多次在不同工作站间流转如果每次都真实传一次存储会被垃圾数据占满。3.2 断点恢复的实现记录已上传分块断点恢复的关键是“查询-差集-重传”三步。前端在/upload/register返回“需要上传”后后端把已上传分块序号列表一并返回。前端拿到这个列表把自己本地切好的分块做一个差集计算只看还没传的分块。比如一个100MB的文件切成25块已经传了10块那前端只上传剩余15块。分块上传接口/upload/chunk接收参数fileMd5, chunkIndex, chunkSize, currentChunkSize, chunkMd5。每个分块上传完后后端会做两件事一是把分块写入MinIO临时目录路径规则建议是tmp/{fileMd5}/{chunkIndex}.part二是写Redis里的分块状态集合用SADD upload:{fileMd5}:chunks {chunkIndex}同时用INCR upload:{fileMd5}:count记录已上传分块数量。由于断点恢复要依赖分块的精确记录Redis里必须存“已上传分块索引集合”而不是只存一个进度百分比。如果只存百分比恢复时无法知道到底是哪几个分块缺失只能把文件从头再传一遍那就失去断点恢复的意义了。3.3 合并文件与DICOM数据校验当已上传分块数达到总分块数时后端就需要触发合并操作。合并不宜在Controller同步做因为文件大时合并可能耗时数秒到数十秒会让HTTP请求超时。实际项目中我在Service里做异步合并合并完成后把结果写回数据库和Redis同时通知前端轮询。合并流程如下读取MinIO临时目录下所有分块按分块序号排序后顺序合并写入最终存储路径。合并完成后做两件事一是计算合并后文件的MD5和前端一开始提交的MD5比对二是用org.dcm4che库读取DICOM文件头校验关键Tag如PatientID、StudyInstanceUID、SeriesInstanceUID等。如果MD5一致且DICOM Tag可解析才把状态置为“已完成”。之后再把临时目录清理掉。这一步为什么重要因为分块传输过程中文件内容可能被篡改或损坏。比如某一块传了半个包后端就返回成功但实际上那一块的大小不对合并之后文件就是坏的。DICOM文件一旦损坏影像科打开就会报错甚至诊断工作站直接崩溃。合并后的完整性校验是最后的防线。4. 实操过程完整实现一个医疗系统的DICOM上传接口4.1 数据库表设计与状态管理上传任务表我建议这样设计字段类型说明idbigint主键file_md5varchar(64)文件全局唯一标识file_namevarchar(255)原始文件名file_sizebigint文件大小字节数chunk_sizeint分块大小字节数chunk_totalint总分块数statustinyint0待上传 1上传中 2已完成 3合并失败storage_object_idvarchar(128)合并后对象存储IDdicom_patient_idvarchar(64)校验后提取的患者IDcreated_timedatetime创建时间update_timedatetime更新时间注意这个表里file_md5字段要建唯一索引。为什么因为秒传的核心就是通过MD5去命中已存在记录如果没有唯一索引高并发重复上传时可能出现同一条记录重复插入后面的逻辑全乱掉。唯一索引还能顺便解决并发重复提交的问题两条相同MD5的注册请求只有一条能插入成功另一条直接走“已存在”逻辑。Redis这边的key设计也讲清楚upload:{fileMd5}:infohash存总分块数、分块大小、文件大小、当前状态upload:{fileMd5}:chunksset存已上传分块序号upload:{fileMd5}:countstring已上传分块数量计数info这个hash可以不用持久化因为数据库表里有全量数据。Redis在这里纯粹是“热数据加速层”用来扛高频率的分块状态查询和更新。如果Redis宕机后端可以从数据库表里反查已上传分块列表然后把Redis重建不影响最终一致性。4.2 Controller接口设计附带代码Controller层我按SpringMVC经典的注解方式写。代码不花哨重点在接口的参数设计上要跟分块语义对齐。RestController RequestMapping(/upload) public class UploadController { Autowired private UploadTokenService uploadTokenService; Autowired private ChunkStorageService chunkStorageService; Autowired private UploadProgressService uploadProgressService; /** * 注册上传任务返回是否需要秒传和已存在分块列表 */ PostMapping(/register) public Result register(RequestParam String fileMd5, RequestParam String fileName, RequestParam Long fileSize) { UploadTaskBO task uploadTokenService.register(fileMd5, fileName, fileSize); if (task.getStatus() UploadStatus.FINISHED) { return Result.success(UploadResponse.secUpload(task)); } return Result.success(UploadResponse.resumeUpload( task, uploadProgressService.listUploadedChunks(fileMd5) )); } /** * 上传单个分块 */ PostMapping(/chunk) public Result uploadChunk(RequestParam String fileMd5, RequestParam Integer chunkIndex, RequestParam Long chunkSize, RequestParam String chunkMd5, RequestParam MultipartFile file) { if (!chunkStorageService.saveChunk(fileMd5, chunkIndex, chunkSize, chunkMd5, file)) { return Result.error(分块校验失败); } int uploadedCount uploadProgressService.markChunkUploaded(fileMd5, chunkIndex); if (uploadedCount uploadProgressService.getChunkTotal(fileMd5)) { // 触发异步合并避免阻塞当前请求 chunkStorageService.asyncMerge(fileMd5); } return Result.success(UploadResponse.chunkOk(chunkIndex, uploadedCount)); } /** * 查询合并状态前端轮询用 */ GetMapping(/status) public Result status(RequestParam String fileMd5) { return Result.success(uploadProgressService.getMergeStatus(fileMd5)); } }这段代码里我故意把“分块大小校验”放在了ChunkStorageService.saveChunk里没有直接写在Controller里原因是分块存储逻辑是可替换组件如果把校验写在Controller里将来换存储实现时容易漏掉一致性检查。Controller只负责参数绑定、流程编排和结果返回这符合SpringMVC里Controller的定位。很多人写SpringMVC时把业务全堆Controller里导致“controller详解”里一堆事务、IO操作根本没法维护。SpringMVC的Controller天生的职责是接收和响应不是干活。4.3 前端分块与进度展示前端我是用原生JavaScript配合SparkMD5库实现的。核心逻辑分三步读文件算MD5、调register、按需上传分块。下面这段代码可以直接参考。const CHUNK_SIZE 4 * 1024 * 1024; // 4MB async function uploadDicomFile(file) { // 1. 计算文件MD5 const fileMd5 await calculateFileMd5(file); const fileSize file.size; // 2. 注册上传任务 const registerResp await fetch(/upload/register, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({fileMd5, fileName: file.name, fileSize}) }); const registerData await registerResp.json(); // 秒传直接返回成功 if (registerData.data.secUpload) { showSuccess(秒传成功); return; } // 3. 计算缺失分块断点恢复 const uploadedChunks registerData.data.uploadedChunks || []; const totalChunks Math.ceil(fileSize / CHUNK_SIZE); const missingChunks []; for (let i 0; i totalChunks; i) { if (!uploadedChunks.includes(i)) { missingChunks.push(i); } } // 4. 逐个上传缺失分块 for (let chunkIndex of missingChunks) { const start chunkIndex * CHUNK_SIZE; const end Math.min(file.size, start CHUNK_SIZE); const chunkBlob file.slice(start, end); const chunkMd5 await calculateBlobMd5(chunkBlob); const formData new FormData(); formData.append(fileMd5, fileMd5); formData.append(chunkIndex, chunkIndex); formData.append(chunkSize, end - start); formData.append(chunkMd5, chunkMd5); formData.append(file, chunkBlob, ${file.name}.part${chunkIndex}); const chunkResp await fetch(/upload/chunk, { method: POST, body: formData }); const chunkData await chunkResp.json(); if (!chunkData.success) { // 记录失败稍后重试这一块 continue; } updateProgress((chunkIndex 1) / totalChunks * 100); } // 5. 轮询合并结果 pollMergeStatus(fileMd5); }为什么前端要算每个分块的chunkMd5再上传因为后端在保存分块时要做两件事一是检查分块文件大小是否和声明一致二是检查分块MD5是否和声明一致。这是防止网络传输过程中数据损坏的关键。有人会觉得每个分块算一次MD5太耗时但实测4MB分块在主流浏览器上单块MD5计算不超过10ms相比上传网络耗时完全可以忽略。前端进度展示要注意“分块维度和字节维度不一致”的问题。假设总100MB前80MB20个分块已上传剩下20MB上传中用字节维度显示进度会更精确。但分块维度更适合判断缺失清单。这里可以两个指标都展示进度条用字节维度详情列表用分块维度医生看到的就是“第3块/共25块”这种直观状态。5. 常见问题与排查技巧实录5.1 分块边界问题最容易踩的坑是文件大小的边界处理。比如文件大小正好是4MB的整数倍总分块数到底是fileSize / CHUNK_SIZE还是向上取整正确答案是向上取整。如果文件是100MB切成25块没问题但如果102MB26块里的最后一块只有2MB前端slice时end不能超过file.size否则会切出一个空Blob。后端合并时也要注意最后一块不能当标准大小处理否则可能读多或读少。这个坑在真实项目中出现过某次上传一个正好256MB的文件前端算出64个分块后端合并时循环64次读块最后一个块的字节数正好是0导致合并时拼出一个多余的空字节整个文件的MD5对不上。解决方式是合并循环判断当前块是否还有有效数据读到的字节数为0就直接停止。5.2 并发导致的分块覆盖医院内网上传速度其实不慢但会有多个医生同时上传同一个文件的情况。这时候并发注册相同MD5的任务如果没有处理好会出现两个任务都在写分块MinIO临时目录里同一个分块文件被互相覆盖合并时发现文件不完整。解决方案是分块写入时要保持幂等性后端对同一个fileMd5 chunkIndex用MinIO的putObject覆盖写没关系但记录进度时必须以“写成功后”为准不能先记进度再写文件。否则并发时两个请求都写了进度但文件实际没写完另一个请求来查进度发现“已上传”前端就跳过这个块合并时缺块。我实际采用的做法是事务边界必须清晰写临时分块文件和写Redis状态放到同一个可回滚的流程里虽然Redis和MinIO之间没有强事务但可以把顺序设计成先写MinIO成功再更新Redis。Redis的更新用SADD本身是幂等的不用担心重复加成员。唯一的风险是MinIO写成功后Redis没写成功这种情况可以在合并前做一次“实际文件存在性检查”发现缺失重新补传。5.3 大文件合并超时与最终文件校验前面说到合并要异步做但异步做也有问题合并任务在应用服务重启后可能会丢。我在项目里加了一个兜底机制每次查询上传状态时如果发现上传分块已齐全但任务状态还是“上传中”就自动触发一次合并。这个设计保证了即使合并任务丢失下一次查询也能恢复合并流程不依赖定时任务。合并后的文件校验必须包含DICOM语义校验而不只是算MD5。我用dcm4che库做个简单的解析读取SOPInstanceUID和StudyInstanceUID如果是空或格式明显不对就判定文件损坏。这个校验在同步上传小文件时可以直接做但大文件异步合并后必须要在合并任务里做否则前端显示“上传100%”但PACS端解析不了那才是最糟糕的用户体验。另外DICOM文件本身就带有校验能力它是一个封装格式内部有严格的数据元素结构。我们不仅要保证文件字节级完整还要保证它符合DICOM标准。有一种情况是分块文件完整但拼接顺序不对MD5一样能对上但序列里图像顺序乱了。所以在合并时要按chunkIndex排序而不是按文件名排序。文件名如果是part1.part按字符串排序会出现“part10”排在“part2”前面这种低级错误一旦出现患者的CT序列图全乱。5.4 断点恢复状态下文件重复上传的语义处理有个场景很隐蔽同一台设备上的同一个文件医生前后两次上传中间文件内容被修改了。此时两个请求的MD5不同系统会认为是两个不同文件分别存两份这是对的。但如果医生上传的文件名一样而内容不一样前端进度展示那里就要注意不能因为“同名”就跳过上传。还有一个场景是医生上传完成后在业务上需要“重新上传一次到另一个申请单”。这种业务语义上的重复不需要重新传字节只需要在业务表里新增一条关联记录指向同一个存储对象ID。我建议在秒传逻辑里不要只判MD5还要加一个业务维度比如studyId。同一个MD5文件在同一个studyId下重复上传算秒传在不同studyId下也算秒传但系统要记录两条业务关联。存储层零冗余业务层可追溯这样最好。6. 从SpringMVC到存储层的整体调用链与优化6.1 一次完整上传的调用链时序说明这里不画图用文字描述清楚。前端发起register请求SpringMVC的DispatcherServlet把请求路由到UploadControllerController调UploadTokenService查数据库然后返回任务状态。前端开始逐个传分块每个分块请求到达Controller后Controller调ChunkStorageService把二进制流写入MinIO再调UploadProgressService更新Redis状态。当最后一个分块完成时ChunkStorageService发一个异步合并事件合并线程从MinIO里读取所有分块合并写到最终目录再解析DICOM Tag写数据库更新状态。前端通过轮询status接口拿到最终结果。整体看下来SpringMVC只是暴露接口的壳子真正的存储和状态管理都是外部组件干的。这套架构好在哪**SpringMVC的拦截器、过滤器完全可以继续用在权限校验、日志记录上不会因为大文件上传而失效。**比如我们给上传接口加了一个AuthInterceptor医生登录后才能拿到上传票据拦截器统一校验token防止外人直接往存储桶里塞文件。这是SpringMVC老项目最舒服的地方不用为了一个新功能就换全家桶。6.2 内存与带宽优化心得大文件上传最容易把应用服务器内存打爆。SpringMVC默认处理multipart时如果配置不对会把整个文件读入内存。针对分块上传每块只有4MB问题不大但要注意Tomcat的maxSwallowSize和Spring的maxFileSize配置。我用的配置是spring.servlet.multipart.max-file-size10MB spring.servlet.multipart.max-request-size10MB server.tomcat.max-swallow-size-1注意max-file-size要比实际分块大小略大否则4MB的块上传时被Spring拒绝就尴尬了。max-swallow-size-1的意思是允许请求体里的剩余数据被吞掉避免连接复用时报错。这个配置在SpringBoot环境下生效传统SpringMVC用web.xml里的multipart配置替代。带宽层面前端可以控制并发上传的分块数量。医学影像系统不建议一次性把所有分块全并发发出4MB一个块100MB是25个请求如果全部并发路由器或网关很容易被压死。我实测下来5个并发最稳既能跑满带宽又不至于让请求大量失败。断点恢复时同理缺失分块按顺序做队列式并发即可。6.3 与MinIO周边方案的整合建议热词里有人搜“minio上传很多大文件方案”我这个方案已经自然回答了用分块MD5记录的方式MinIO只负责存储不关心业务状态但它提供了很好的大对象存储底座。MinIO本身支持服务端组合分块用S3的UploadPartCopy等操作可以把客户端分块直接对接到MinIO的临时分块存储里不过传统SpringMVC项目直接走HTTP multipart到MinIO再合并的方式更直观也更容易排查问题。如果项目里已用了MinIO且不想自己维护一个临时目录可以考虑用MinIO的多部分上传接口实现服务端分块聚合但要小心它的分块状态跟Redis的进度状态需要保持一致复杂度会更高。对大多数医疗项目来说先落本地临时文件再合并是最不依赖外部SDK复杂行为的选择。我个人在实际操作中的体会是医疗系统做文件上传要以“可断点、可校验、可重复”为前提而不是以“快”为前提。秒传和断点恢复里秒传是用户体验的加分项断点恢复才是质量和可靠的底座。真在临床一线用过就明白医生最怕的不是上传慢而是传了半天最后告诉你文件坏了那比不传还糟。这个小技巧对任何类型的大文件上传都通用把文件指纹作为存储落盘时的主键把“这次请求是否传完”和“这个文件是否完整”拆成两个独立状态来管理。前者影响前端进度条后者决定后端是否放行进入业务表。如果你项目里也在做类似的上传组件建议先把这个状态模型画清楚再写代码能少走很多弯路。
SpringMVC+Redis+MinIO：DICOM大文件秒传与断点恢复实战
医院里的PACS系统天天都在上传CT、MR、DR影像单份DICOM文件动不动就是几十上百MB遇到CT薄层扫描甚至能到几百MB到1GB。一线医生点完上传等半分钟进度条还卡在半路要是网络抖一下整个流程直接报废重来。我们科室早年用SpringMVC做影像管理平台就被这个上传体验折磨得不轻。今天这篇就手把手拆一版能落地的方案如何基于SpringMVC这套经典技术栈实现DICOM影像大文件的秒传和断点恢复让一线操作人员从“等待上传”变成“秒级完成”。这套方案的核心思路一句话总结就是前端算指纹的结果决定是“秒传”还是“真的传”。先对文件做MD5后端发现同样的文件已经存在直接返回成功这就是秒传如果文件没传完后端告诉前端“你已经传了哪些分块”前端只补传缺失部分这就是断点恢复。整个链路我用SpringMVC Redis MinIO 前端分块计算来组合实现代码量不大但非常管用。适合谁看两类人。一类是做医疗信息系统、影像归档系统、远程诊断平台的后端开发需要对接DICOM大文件上传场景另一类是做成套系统、负责文件存储选型的技术负责人想在不重写技术栈的前提下把上传体验和存储可靠性同时提上来。下面内容不绕弯子从拆解问题开始到组件选型、核心实现、坑点排查全部按真实项目里的经验来。1. 问题拆解DICOM影像文件为什么必须走“秒传”和“断点恢复”1.1 医疗影像上传的核心痛点DICOM文件不像普通办公文档它自带一堆医疗元数据而且通常是一个患者一次检查会生成一个序列每个序列里有几十张到上千张图像。一次检查的总数据量很容易冲上500MB到2GB。在院内网络环境尚可时上传量大只是“慢”但到了跨院区、医联体远程诊断、或者医生通过公网访问的体检车场景网络带宽和稳定性都很差一次上传基本等于“风险操作”。更麻烦的是DICOM文件还必须保证完整性和可校验性。影像科一旦发现某张图像缺失影响的是诊断结论。所以这种场景不能简单粗暴地“用HTTP multipart把文件响一声丢上去”必须有额外的校验机制文件是否完整、重组之后DICOM Tag是否可读、患者检查号是否匹配等。这就意味着“上传-校验-入库”三个步骤必须拆开每一步都要可以重试、可恢复。1.2 秒传与断点恢复的技术本质秒传不是魔法。它的本质是跳过数据传输只完成状态确认和逻辑入库。前端把文件指纹MD5/SHA1发给后端后端在存储系统里查一下发现这个文件完整存在那就不需要再传直接返回“上传成功”前端界面显示秒完成。断点恢复的本质是让上传任务实现“分块可寻址”。整个文件被切成多个分块每一块都有唯一编号。后端在Redis和数据库里记录哪些分块已经上传、大小是否正确、校验和是否一致。前端再次上传时不用重新整个文件只查询缺失分块清单把剩余分块补齐就行。这两者合起来的体验是网络断了不怕断点续传再次重复上传同一个文件秒传多人重复传同一个影像秒传。这正好对上了医疗场景里的高频行为同一个DICOM文件常被反复上传到不同批次、不同申请单里而多机构协同又会重复采集数据。2. 组件选型基于SpringMVC整合哪些组件实现2.1 前端计算指纹与文件分块策略前端要做两件事算文件MD5、把文件切成物理分块。算MD5在浏览器端用SparkMD5这一类库基于FileAPI读取ArrayBuffer边读边算大文件也不会把内存打爆。分块我建议按固定大小分片比如4MB或8MB一块。为什么用4MB因为太小会导致HTTP请求数量太多太大又会让断点恢复的粒度太粗网络中断重传的冗余数据多。4MB在大多数局域网和公网环境里是最好的折中方案实际测试下来100MB文件也就25个分块请求数量完全可控。文件分块之后每个分块需要包含关键参数文件唯一标识MD5、分块序号、总分块数、分块大小。上传分块时同时带上这个分块的MD5后端就能校验每个分块的完整性。2.2 后端判断秒传与分块合并的核心实现后端组件我用的组合是SpringMVC Controller层 Service层 Redis做任务状态 MinIO做对象存储。SpringMVC负责接口路由和参数绑定Redis存上传任务进度和分块状态MinIO负责把分块和最终合并后的文件落盘。这套组合的好处是SpringMVC完全不需要换仅靠自定义接口和组件化封装就把一个原本只能传小文件的后端改造成了可秒传、可断点的大文件上传系统。这里要特别提到“组件”二字。很多人以为组件就是引个第三方库但实践中我把整个上传能力拆成了三层组件UploadTokenService负责生成上传票据和文件关系映射ChunkStorageService负责分块的读写和合并UploadProgressService负责从Redis里读写进度。这样Controller里只做参数接收和状态返回不堆积业务逻辑。后续如果要接不同的对象存储只需要替换ChunkStorageService的实现不用动接口。3. 核心细节解析从分块上传到断点恢复的关键机制3.1 秒传的实现流程先算MD5再传文件秒传的前置条件是后端必须有一个“文件指纹索引”。流程如下患者上传DICOM文件时先通过前端计算出整个文件的MD5然后调用后端接口/upload/register提交参数fileMd5, fileName, fileSize。后端收到后先查数据库上传记录表如果这条MD5记录已经存在且状态为“已完成”就直接返回“秒传成功”如果存在但状态是“未完成”就返回已上传分块序号如果不存在就创建一条新的上传任务记录返回“需要上传”及分块大小建议。这个流程里最容易被忽略的是秒传不只是省上传时间还省存储空间。因为同一个MD5的文件后端只保留一份物理文件所有关联业务记录都引用同一个存储对象ID。这在PACS系统里尤其重要因为同一患者的同一序列经常被多次申请、多次调阅、多次在不同工作站间流转如果每次都真实传一次存储会被垃圾数据占满。3.2 断点恢复的实现记录已上传分块断点恢复的关键是“查询-差集-重传”三步。前端在/upload/register返回“需要上传”后后端把已上传分块序号列表一并返回。前端拿到这个列表把自己本地切好的分块做一个差集计算只看还没传的分块。比如一个100MB的文件切成25块已经传了10块那前端只上传剩余15块。分块上传接口/upload/chunk接收参数fileMd5, chunkIndex, chunkSize, currentChunkSize, chunkMd5。每个分块上传完后后端会做两件事一是把分块写入MinIO临时目录路径规则建议是tmp/{fileMd5}/{chunkIndex}.part二是写Redis里的分块状态集合用SADD upload:{fileMd5}:chunks {chunkIndex}同时用INCR upload:{fileMd5}:count记录已上传分块数量。由于断点恢复要依赖分块的精确记录Redis里必须存“已上传分块索引集合”而不是只存一个进度百分比。如果只存百分比恢复时无法知道到底是哪几个分块缺失只能把文件从头再传一遍那就失去断点恢复的意义了。3.3 合并文件与DICOM数据校验当已上传分块数达到总分块数时后端就需要触发合并操作。合并不宜在Controller同步做因为文件大时合并可能耗时数秒到数十秒会让HTTP请求超时。实际项目中我在Service里做异步合并合并完成后把结果写回数据库和Redis同时通知前端轮询。合并流程如下读取MinIO临时目录下所有分块按分块序号排序后顺序合并写入最终存储路径。合并完成后做两件事一是计算合并后文件的MD5和前端一开始提交的MD5比对二是用org.dcm4che库读取DICOM文件头校验关键Tag如PatientID、StudyInstanceUID、SeriesInstanceUID等。如果MD5一致且DICOM Tag可解析才把状态置为“已完成”。之后再把临时目录清理掉。这一步为什么重要因为分块传输过程中文件内容可能被篡改或损坏。比如某一块传了半个包后端就返回成功但实际上那一块的大小不对合并之后文件就是坏的。DICOM文件一旦损坏影像科打开就会报错甚至诊断工作站直接崩溃。合并后的完整性校验是最后的防线。4. 实操过程完整实现一个医疗系统的DICOM上传接口4.1 数据库表设计与状态管理上传任务表我建议这样设计字段类型说明idbigint主键file_md5varchar(64)文件全局唯一标识file_namevarchar(255)原始文件名file_sizebigint文件大小字节数chunk_sizeint分块大小字节数chunk_totalint总分块数statustinyint0待上传 1上传中 2已完成 3合并失败storage_object_idvarchar(128)合并后对象存储IDdicom_patient_idvarchar(64)校验后提取的患者IDcreated_timedatetime创建时间update_timedatetime更新时间注意这个表里file_md5字段要建唯一索引。为什么因为秒传的核心就是通过MD5去命中已存在记录如果没有唯一索引高并发重复上传时可能出现同一条记录重复插入后面的逻辑全乱掉。唯一索引还能顺便解决并发重复提交的问题两条相同MD5的注册请求只有一条能插入成功另一条直接走“已存在”逻辑。Redis这边的key设计也讲清楚upload:{fileMd5}:infohash存总分块数、分块大小、文件大小、当前状态upload:{fileMd5}:chunksset存已上传分块序号upload:{fileMd5}:countstring已上传分块数量计数info这个hash可以不用持久化因为数据库表里有全量数据。Redis在这里纯粹是“热数据加速层”用来扛高频率的分块状态查询和更新。如果Redis宕机后端可以从数据库表里反查已上传分块列表然后把Redis重建不影响最终一致性。4.2 Controller接口设计附带代码Controller层我按SpringMVC经典的注解方式写。代码不花哨重点在接口的参数设计上要跟分块语义对齐。RestController RequestMapping(/upload) public class UploadController { Autowired private UploadTokenService uploadTokenService; Autowired private ChunkStorageService chunkStorageService; Autowired private UploadProgressService uploadProgressService; /** * 注册上传任务返回是否需要秒传和已存在分块列表 */ PostMapping(/register) public Result register(RequestParam String fileMd5, RequestParam String fileName, RequestParam Long fileSize) { UploadTaskBO task uploadTokenService.register(fileMd5, fileName, fileSize); if (task.getStatus() UploadStatus.FINISHED) { return Result.success(UploadResponse.secUpload(task)); } return Result.success(UploadResponse.resumeUpload( task, uploadProgressService.listUploadedChunks(fileMd5) )); } /** * 上传单个分块 */ PostMapping(/chunk) public Result uploadChunk(RequestParam String fileMd5, RequestParam Integer chunkIndex, RequestParam Long chunkSize, RequestParam String chunkMd5, RequestParam MultipartFile file) { if (!chunkStorageService.saveChunk(fileMd5, chunkIndex, chunkSize, chunkMd5, file)) { return Result.error(分块校验失败); } int uploadedCount uploadProgressService.markChunkUploaded(fileMd5, chunkIndex); if (uploadedCount uploadProgressService.getChunkTotal(fileMd5)) { // 触发异步合并避免阻塞当前请求 chunkStorageService.asyncMerge(fileMd5); } return Result.success(UploadResponse.chunkOk(chunkIndex, uploadedCount)); } /** * 查询合并状态前端轮询用 */ GetMapping(/status) public Result status(RequestParam String fileMd5) { return Result.success(uploadProgressService.getMergeStatus(fileMd5)); } }这段代码里我故意把“分块大小校验”放在了ChunkStorageService.saveChunk里没有直接写在Controller里原因是分块存储逻辑是可替换组件如果把校验写在Controller里将来换存储实现时容易漏掉一致性检查。Controller只负责参数绑定、流程编排和结果返回这符合SpringMVC里Controller的定位。很多人写SpringMVC时把业务全堆Controller里导致“controller详解”里一堆事务、IO操作根本没法维护。SpringMVC的Controller天生的职责是接收和响应不是干活。4.3 前端分块与进度展示前端我是用原生JavaScript配合SparkMD5库实现的。核心逻辑分三步读文件算MD5、调register、按需上传分块。下面这段代码可以直接参考。const CHUNK_SIZE 4 * 1024 * 1024; // 4MB async function uploadDicomFile(file) { // 1. 计算文件MD5 const fileMd5 await calculateFileMd5(file); const fileSize file.size; // 2. 注册上传任务 const registerResp await fetch(/upload/register, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({fileMd5, fileName: file.name, fileSize}) }); const registerData await registerResp.json(); // 秒传直接返回成功 if (registerData.data.secUpload) { showSuccess(秒传成功); return; } // 3. 计算缺失分块断点恢复 const uploadedChunks registerData.data.uploadedChunks || []; const totalChunks Math.ceil(fileSize / CHUNK_SIZE); const missingChunks []; for (let i 0; i totalChunks; i) { if (!uploadedChunks.includes(i)) { missingChunks.push(i); } } // 4. 逐个上传缺失分块 for (let chunkIndex of missingChunks) { const start chunkIndex * CHUNK_SIZE; const end Math.min(file.size, start CHUNK_SIZE); const chunkBlob file.slice(start, end); const chunkMd5 await calculateBlobMd5(chunkBlob); const formData new FormData(); formData.append(fileMd5, fileMd5); formData.append(chunkIndex, chunkIndex); formData.append(chunkSize, end - start); formData.append(chunkMd5, chunkMd5); formData.append(file, chunkBlob, ${file.name}.part${chunkIndex}); const chunkResp await fetch(/upload/chunk, { method: POST, body: formData }); const chunkData await chunkResp.json(); if (!chunkData.success) { // 记录失败稍后重试这一块 continue; } updateProgress((chunkIndex 1) / totalChunks * 100); } // 5. 轮询合并结果 pollMergeStatus(fileMd5); }为什么前端要算每个分块的chunkMd5再上传因为后端在保存分块时要做两件事一是检查分块文件大小是否和声明一致二是检查分块MD5是否和声明一致。这是防止网络传输过程中数据损坏的关键。有人会觉得每个分块算一次MD5太耗时但实测4MB分块在主流浏览器上单块MD5计算不超过10ms相比上传网络耗时完全可以忽略。前端进度展示要注意“分块维度和字节维度不一致”的问题。假设总100MB前80MB20个分块已上传剩下20MB上传中用字节维度显示进度会更精确。但分块维度更适合判断缺失清单。这里可以两个指标都展示进度条用字节维度详情列表用分块维度医生看到的就是“第3块/共25块”这种直观状态。5. 常见问题与排查技巧实录5.1 分块边界问题最容易踩的坑是文件大小的边界处理。比如文件大小正好是4MB的整数倍总分块数到底是fileSize / CHUNK_SIZE还是向上取整正确答案是向上取整。如果文件是100MB切成25块没问题但如果102MB26块里的最后一块只有2MB前端slice时end不能超过file.size否则会切出一个空Blob。后端合并时也要注意最后一块不能当标准大小处理否则可能读多或读少。这个坑在真实项目中出现过某次上传一个正好256MB的文件前端算出64个分块后端合并时循环64次读块最后一个块的字节数正好是0导致合并时拼出一个多余的空字节整个文件的MD5对不上。解决方式是合并循环判断当前块是否还有有效数据读到的字节数为0就直接停止。5.2 并发导致的分块覆盖医院内网上传速度其实不慢但会有多个医生同时上传同一个文件的情况。这时候并发注册相同MD5的任务如果没有处理好会出现两个任务都在写分块MinIO临时目录里同一个分块文件被互相覆盖合并时发现文件不完整。解决方案是分块写入时要保持幂等性后端对同一个fileMd5 chunkIndex用MinIO的putObject覆盖写没关系但记录进度时必须以“写成功后”为准不能先记进度再写文件。否则并发时两个请求都写了进度但文件实际没写完另一个请求来查进度发现“已上传”前端就跳过这个块合并时缺块。我实际采用的做法是事务边界必须清晰写临时分块文件和写Redis状态放到同一个可回滚的流程里虽然Redis和MinIO之间没有强事务但可以把顺序设计成先写MinIO成功再更新Redis。Redis的更新用SADD本身是幂等的不用担心重复加成员。唯一的风险是MinIO写成功后Redis没写成功这种情况可以在合并前做一次“实际文件存在性检查”发现缺失重新补传。5.3 大文件合并超时与最终文件校验前面说到合并要异步做但异步做也有问题合并任务在应用服务重启后可能会丢。我在项目里加了一个兜底机制每次查询上传状态时如果发现上传分块已齐全但任务状态还是“上传中”就自动触发一次合并。这个设计保证了即使合并任务丢失下一次查询也能恢复合并流程不依赖定时任务。合并后的文件校验必须包含DICOM语义校验而不只是算MD5。我用dcm4che库做个简单的解析读取SOPInstanceUID和StudyInstanceUID如果是空或格式明显不对就判定文件损坏。这个校验在同步上传小文件时可以直接做但大文件异步合并后必须要在合并任务里做否则前端显示“上传100%”但PACS端解析不了那才是最糟糕的用户体验。另外DICOM文件本身就带有校验能力它是一个封装格式内部有严格的数据元素结构。我们不仅要保证文件字节级完整还要保证它符合DICOM标准。有一种情况是分块文件完整但拼接顺序不对MD5一样能对上但序列里图像顺序乱了。所以在合并时要按chunkIndex排序而不是按文件名排序。文件名如果是part1.part按字符串排序会出现“part10”排在“part2”前面这种低级错误一旦出现患者的CT序列图全乱。5.4 断点恢复状态下文件重复上传的语义处理有个场景很隐蔽同一台设备上的同一个文件医生前后两次上传中间文件内容被修改了。此时两个请求的MD5不同系统会认为是两个不同文件分别存两份这是对的。但如果医生上传的文件名一样而内容不一样前端进度展示那里就要注意不能因为“同名”就跳过上传。还有一个场景是医生上传完成后在业务上需要“重新上传一次到另一个申请单”。这种业务语义上的重复不需要重新传字节只需要在业务表里新增一条关联记录指向同一个存储对象ID。我建议在秒传逻辑里不要只判MD5还要加一个业务维度比如studyId。同一个MD5文件在同一个studyId下重复上传算秒传在不同studyId下也算秒传但系统要记录两条业务关联。存储层零冗余业务层可追溯这样最好。6. 从SpringMVC到存储层的整体调用链与优化6.1 一次完整上传的调用链时序说明这里不画图用文字描述清楚。前端发起register请求SpringMVC的DispatcherServlet把请求路由到UploadControllerController调UploadTokenService查数据库然后返回任务状态。前端开始逐个传分块每个分块请求到达Controller后Controller调ChunkStorageService把二进制流写入MinIO再调UploadProgressService更新Redis状态。当最后一个分块完成时ChunkStorageService发一个异步合并事件合并线程从MinIO里读取所有分块合并写到最终目录再解析DICOM Tag写数据库更新状态。前端通过轮询status接口拿到最终结果。整体看下来SpringMVC只是暴露接口的壳子真正的存储和状态管理都是外部组件干的。这套架构好在哪**SpringMVC的拦截器、过滤器完全可以继续用在权限校验、日志记录上不会因为大文件上传而失效。**比如我们给上传接口加了一个AuthInterceptor医生登录后才能拿到上传票据拦截器统一校验token防止外人直接往存储桶里塞文件。这是SpringMVC老项目最舒服的地方不用为了一个新功能就换全家桶。6.2 内存与带宽优化心得大文件上传最容易把应用服务器内存打爆。SpringMVC默认处理multipart时如果配置不对会把整个文件读入内存。针对分块上传每块只有4MB问题不大但要注意Tomcat的maxSwallowSize和Spring的maxFileSize配置。我用的配置是spring.servlet.multipart.max-file-size10MB spring.servlet.multipart.max-request-size10MB server.tomcat.max-swallow-size-1注意max-file-size要比实际分块大小略大否则4MB的块上传时被Spring拒绝就尴尬了。max-swallow-size-1的意思是允许请求体里的剩余数据被吞掉避免连接复用时报错。这个配置在SpringBoot环境下生效传统SpringMVC用web.xml里的multipart配置替代。带宽层面前端可以控制并发上传的分块数量。医学影像系统不建议一次性把所有分块全并发发出4MB一个块100MB是25个请求如果全部并发路由器或网关很容易被压死。我实测下来5个并发最稳既能跑满带宽又不至于让请求大量失败。断点恢复时同理缺失分块按顺序做队列式并发即可。6.3 与MinIO周边方案的整合建议热词里有人搜“minio上传很多大文件方案”我这个方案已经自然回答了用分块MD5记录的方式MinIO只负责存储不关心业务状态但它提供了很好的大对象存储底座。MinIO本身支持服务端组合分块用S3的UploadPartCopy等操作可以把客户端分块直接对接到MinIO的临时分块存储里不过传统SpringMVC项目直接走HTTP multipart到MinIO再合并的方式更直观也更容易排查问题。如果项目里已用了MinIO且不想自己维护一个临时目录可以考虑用MinIO的多部分上传接口实现服务端分块聚合但要小心它的分块状态跟Redis的进度状态需要保持一致复杂度会更高。对大多数医疗项目来说先落本地临时文件再合并是最不依赖外部SDK复杂行为的选择。我个人在实际操作中的体会是医疗系统做文件上传要以“可断点、可校验、可重复”为前提而不是以“快”为前提。秒传和断点恢复里秒传是用户体验的加分项断点恢复才是质量和可靠的底座。真在临床一线用过就明白医生最怕的不是上传慢而是传了半天最后告诉你文件坏了那比不传还糟。这个小技巧对任何类型的大文件上传都通用把文件指纹作为存储落盘时的主键把“这次请求是否传完”和“这个文件是否完整”拆成两个独立状态来管理。前者影响前端进度条后者决定后端是否放行进入业务表。如果你项目里也在做类似的上传组件建议先把这个状态模型画清楚再写代码能少走很多弯路。
