大文件上传流量控制：从带宽打满到服务端限流实战

生产环境报警带宽被打满、核心交易接口超时率飙升。定位到最后根因却是“大文件上传”——这一看似人畜无害的功能竟然能把金融保险Java应用的整体链路直接拖垮。这篇文章不聊虚的就讲讲我在实际项目中如何通过组件选型和服务端拦截改造给大文件上传加装一套完整的流量控制方案。要说清楚这件事得先还原一下事故现场。当时我们负责的是某保险公司的影像平台承载保单扫描件、理赔票据、双录视频等材料上传。上线初期功能一切正常直到某个月底迎来了理赔小高峰业务人员集中上传一批高清事故照片和扫描压缩包突然监控面板全红网关出方向带宽到达98%应用服务器的Tomcat线程几乎全被上传请求占据连带着保单查询、核保接口的响应时间从两百毫秒飙升到两秒以上。事后分析日志发现单个上传请求并不算离谱最大也就一百多MB但几十个用户同时上传瞬时吞吐量直接超过内网链路容量。这就是典型的“上传流量失控”。很多团队把大文件上传当成一个普通功能来做配置一个multipart大小上限就结束了忽略了上传链路在金融保险场景下的特殊性。接下来我把整个思考过程、组件选型、落地代码和上线后踩过的坑完整梳理一遍。1. 为什么金融保险应用必须把大文件上传限流单独拎出来设计1.1 影像材料不是普通文件它是刚需且越来越大金融保险业务的线上化程度越高对影像文件的大小就越“无能为力”。保单投保需要身份证照片、银行卡照片、签字影像理赔阶段要有事故现场原图、维修清单、医疗发票扫描件部分产品还要录制双录视频。手机摄像头像素越提越高一张现场照片动辄十几MB一段几分钟的双录视频轻松突破几百MB。这和一般网站的论坛头像、文档附件完全不同。社区类应用文件超限可以直接拒绝用户不会有太大意见但保险理赔材料缺失意味着业务无法推进用户必须把文件传上来。所以系统不能简单粗暴地“一刀切不传”而是要想方设法在有限带宽和资源内把文件完整收到服务端。1.2 流量失控的代价不只是“上传慢一点”很多人理解的限流就是限制文件大小这其实只解决了一个维度。真实生产环境里大文件上传对系统的冲击是全方位的带宽占用一个200MB文件在1000Mbps链路上传输理论耗时约1.6秒但这是独占带宽的理想情况。如果有20个用户同时上传链路立刻被打满所有经过同一链路的业务请求全部排队。Tomcat线程阻塞Servlet容器处理上传请求时如果不做特殊处理默认会把线程一直占住直到文件读完。线程池耗尽后普通接口的请求根本进不了应用。临时文件磁盘压力Spring Multipart解析大文件时会把内容先落盘到临时目录大量并发上传会把磁盘IO打高甚至撑爆临时目录。数据库和应用层雪崩应用响应变慢后上游调用方不断重试请求量翻倍形成恶性循环。所以金融保险Java应用里的大文件上传流量控制本质上是保护整条业务链路而不是单纯约束上传功能本身。1.3 要控制的是三股流量大小、并发、速率我后来把流量控制拆成三个维度缺一不可单请求大小限制限制单个文件的字节数。这是最基础的防线决定“多大算大”。但这个限制不能只在应用层做容器的请求体大小、网关的client_max_body_size都要配套。并发上传数限制限制同一时刻后台能处理的上传请求数。目的是保护线程池和内存防止几十个大文件同时冲进来占满Tomcat线程。字节速率限制限制单位时间内允许消费的上传字节数。这是真正的“带宽控制”让服务端以一个稳定速率读取客户端数据把链路占用控制在安全水位内。三个维度缺一个其他维度都会被打穿。只限制大小不限制并发20个小文件一样能占满带宽只限制并发不限制速率单个巨型视频文件也能拖死接口。下面几章就以这个框架为基础说说组件选型。2. 组件选型拦截器、Servlet 3.0、第三方存储各能挡多少流量2.1 常见上传组件的流量控制能力真相市面上处理上传的组件很多但很多开发者对它们的能力边界有误解。我用一个表格把常用的手段和真实能力列一下层级典型能力能限制的维度局限Servlet容器Tomcat等maxSwallowSize、maxPostSize单请求体大小只兜底不感知业务无法限制并发和速率Spring MultipartmaxFileSize、maxRequestSize、file-size-threshold单文件大小、单请求大小只是文件大小约束文件解析前带宽已经被读走了Apache Commons FileUploadsetSizeMax单请求大小老项目集成成本低但同样不解决速率问题应用过滤器/拦截器自研代码用信号量和令牌桶控制并发数、上传速率、真实字节数需要自己写但最灵活网关Nginx/API网关client_max_body_size、连接数限制、请求频率限制请求体大小、连接数、请求速率对multipart内部结构不敏感速度控制对上传方向不直接对象存储直传OSS/MinIO签名URL签名URL、单连接限速网络流量不经过应用需要额外开发和权限控制私有化环境未必允许这里重点说一个容易被忽视的问题Spring Multipart的maxFileSize虽然能限制最终接受的文件大小但它是在解析请求体时检查的。客户端数据其实已经通过网络全部到达服务端带宽早就被消耗完了。换句话说大小限制挡的是“落库”不是“传输”。2.2 我选的组合Servlet容器兜底 拦截器做入口闸门 令牌桶做速率控制在私有化部署的金融保险环境中对象存储直传方案往往受安全策略限制不能直接用所以应用层必须自己扛住流量压力。我最终确定的组合是Tomcat层面配maxSwallowSize和maxPostSize防止容器被超大请求体和恶意请求打爆。Spring Boot的spring.servlet.multipart配置限制单文件大小和请求大小作为第二道业务层防线。自研一个上传拦截器在请求进入Controller之前检查是不是multipart请求、Content-Length是否超限、当前并发上传数是否已满。在真正读取文件流的地方接入字节令牌桶对单位时间内消费的字节数做平滑限制。这个组合的好处是每一层只负责自己擅长的部分。容器管单请求体大小拦截器管并发和入口检查令牌桶管传输速率。逻辑上互不干扰坏掉任何一层都不会导致彻底失控。3. 落地实现入口拦截、字节计数、令牌桶限流的完整代码拆解3.1 基础建设用过滤器在请求进入业务前做粗筛我实现了一个UploadTrafficInterceptor它负责两件事识别上传请求、做粗粒度准入判断。核心代码如下public class UploadTrafficInterceptor implements HandlerInterceptor { private final UploadTrafficProperties properties; private final Semaphore uploadSemaphore; public UploadTrafficInterceptor(UploadTrafficProperties properties) { this.properties properties; this.uploadSemaphore new Semaphore(properties.getMaxConcurrentUploads()); } Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!isMultipartRequest(request)) { return true; } // 先检查请求体大小。注意chunked请求的Content-Length可能是-1这里只做粗筛。 long contentLength request.getContentLength(); if (contentLength properties.getMaxRequestBytes()) { sendError(response, HttpStatus.PAYLOAD_TOO_LARGE.value(), 请求体超过最大允许值 properties.getMaxRequestBytes()); return false; } // 再检查并发上传数没拿到信号量直接返回429。 if (!uploadSemaphore.tryAcquire()) { sendError(response, HttpStatus.TOO_MANY_REQUESTS.value(), 当前上传人数过多请稍后重试); return false; } // 拿到信号量后在afterCompletion里释放。 request.setAttribute(UPLOAD_SEMAPHORE_ACQUIRED, Boolean.TRUE); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { if (Boolean.TRUE.equals(request.getAttribute(UPLOAD_SEMAPHORE_ACQUIRED))) { uploadSemaphore.release(); request.removeAttribute(UPLOAD_SEMAPHORE_ACQUIRED); } } private boolean isMultipartRequest(HttpServletRequest request) { String contentType request.getContentType(); return contentType ! null contentType.toLowerCase().contains(multipart/form-data); } }这段代码有两个细节值得说。第一信号量是tryAcquire非阻塞获取拿不到就直接返回429而不是让客户端排队等待。为什么因为大文件上传请求占用线程时间很长如果让请求在队列里排队Tomcat线程照样被占住普通接口反而遭殃。第二afterCompletion必须释放信号量而且要确保请求无论成功失败都走到这一步。3.2 核心组件字节令牌桶控制传输速率并发限制只是防住“人太多”真正控制带宽的是速率限制。我实现了一个非常经典的字节令牌桶按每秒补充固定字节数的模式对上传流读取进行节流。public class ByteRateLimiter { private final long capacityBytes; // 桶容量允许瞬时突发 private final long refillRatePerSecond; // 每秒补充的字节数 private long tokens; private long lastRefillNanos; public ByteRateLimiter(long capacityBytes, long refillRatePerSecond) { this.capacityBytes capacityBytes; this.refillRatePerSecond refillRatePerSecond; this.tokens capacityBytes; this.lastRefillNanos System.nanoTime(); } public synchronized boolean tryAcquire(long byteCount) { long now System.nanoTime(); long deltaNanos now - lastRefillNanos; if (deltaNanos 0) { double deltaSeconds deltaNanos / 1_000_000_000.0; long refill (long) (deltaSeconds * refillRatePerSecond); if (refill 0) { tokens Math.min(capacityBytes, tokens refill); lastRefillNanos now; } } if (byteCount tokens) { return false; } tokens - byteCount; return true; } // 支持带等待时间预算的获取循环尝试直到超时 public boolean tryAcquireWithWait(long byteCount, long maxWaitNanos) { long start System.nanoTime(); while (!tryAcquire(byteCount)) { if (System.nanoTime() - start maxWaitNanos) { return false; } LockSupport.parkNanos(50_000_000L); // 50ms重试一次 } return true; } }令牌桶要理解其实很简单你就把它想象成一个水桶里面装的是“可读取的字节数”令牌。每隔一段时间桶里就会自动补充一批令牌桶的深度决定了允许一次性突发的量补充速度决定了长期的平均传输速率。客户端每次上传数据都得先从桶里拿走对应数量的令牌才能继续。这里还涉及一个策略选择拿不到令牌时是立即拒绝还是等待如果立即拒绝客户端经常上传失败体验很差如果无限等待服务端会积压大量慢请求。我的做法是给一个“等待预算”比如30秒内拿不到令牌就放弃。这样既能让请求平滑降速又不至于无限占用线程。3.3 在真正读取文件流的地方做实时字节计数拦截器只是入口闸门真正的实时限制必须在读取Part的InputStream时完成。代码逻辑如下PostMapping(/upload) public ResponseEntityUploadResult upload(RequestParam(file) MultipartFile file) { try { if (file.isEmpty()) { return ResponseEntity.badRequest().build(); } // 这里用的是Spring已解析的Part实际上更精细的控制需要拿到Part的原始InputStream long fileSize file.getSize(); if (fileSize properties.getMaxFileBytes()) { throw new UploadSizeExceededException(properties.getMaxFileBytes(), fileSize); } // 真正的业务落盘可以替换为自己的存储逻辑 storeFileWithRateLimit(file); return ResponseEntity.ok(UploadResult.success(fileSize)); } catch (UploadTrafficLimitedException e) { return ResponseEntity.status(HttpStatus.TOO_MANY_REQUESTS) .body(UploadResult.failed(e.getMessage())); } }但这里有个更关键的点Spring Multipart在进入Controller时已经完成了请求体的解析和落盘我们想做字节级速率控制就必须在更早的位置介入。实践中有两种做法一是直接在MultipartResolver解析之前用Filter包装请求自己读取InputStream并计数二是换用Servlet 3.0的Part原始流在读写循环里做控制。我偏向后者因为它能精确感知每个字节的到达但代码复杂度更高。如果项目里对上传改造范围不想太大可以在MultipartFile的getInputStream()读取时做控制但要注意此时客户端数据其实已经在容器层接收得差不多了速率控制的效果会打折扣。真实能落地的方案是使用RequestParam(file) Part file然后这样处理try (InputStream in file.getInputStream()) { byte[] buffer new byte[16 * 1024]; int len; long totalBytes 0; long startNanos System.nanoTime(); while ((len in.read(buffer)) ! -1) { totalBytes len; // 真实字节超限判断不轻信Content-Length if (totalBytes properties.getMaxFileBytes()) { throw new UploadSizeExceededException(properties.getMaxFileBytes(), totalBytes); } // 令牌桶限速等待预算为30秒 if (!rateLimiter.tryAcquireWithWait(len, properties.getMaxWaitMs() * 1_000_000L)) { throw new UploadTrafficLimitedException(上传速率超过服务端限制请稍后重试); } outputStream.write(buffer, 0, len); } }额外提一点写文件时的outputStream一定要用BufferedOutputStream否则一次只写几十KB会导致系统调用频繁磁盘IO反而被放大。我见过有人在这步忽略缓冲结果限流没生效服务器磁盘IO先被打满了。3.4 关键参数怎么定一个可复用的计算逻辑参数不能拍脑袋否则要么限不住要么把正常业务卡死。我一般按下面的流程计算明确链路总带宽比如应用服务器所在内网链路上行是1000Mbps除以8得到理论速率125MB/s。预留安全水位不可能把全部带宽都给上传通常预留50%给核心交易接口所以上传可用带宽就是500Mbps约62.5MB/s。结合最大并发数分摊如果maxConcurrentUploads设为5那么单请求平均只能占用12.5MB/srefillRatePerSecond就设为12MB/s。设置突发容量桶容量可以设为速率的2倍即24MB允许短时间冲击一下避免零星的网络抖动触发限流。超时预算一个200MB文件在12MB/s速率下理想耗时约17秒客户端超时时间至少设为60秒服务端等待预算设30秒。配置段示例upload: max-file-size: 200MB max-request-size: 210MB max-concurrent-uploads: 5 traffic-control: capacity-bytes: 24MB refill-per-second: 12MB max-wait-ms: 30000这套参数在我们压测环境里表现比较稳。但记住不同环境带宽差异很大上线前必须根据实际压测结果再校准。4. 上线后真正折磨人的问题伪装小文件、超时、错误码与监控4.1 Content-Length可以被伪造别把它当最终依据流量控制上线后第一个大坑来自Content-Length。拦截器用request.getContentLength()做入口粗筛时遇到以下几种情况会失灵chunked传输编码客户端使用Transfer-Encoding: chunked时Content-Length为-1入口拦截器无法直接判断大小只能放行。客户端伪造长度有的客户端在上传早期就把Content-Length写小实际发送的数据远大于声明。multipart结构的复杂性整个请求体大小不等于单个文件大小多个文件加起来可能超限但入口检查只能看到总长度。所以规则必须是入口拦截器用Content-Length做粗筛能挡就挡最终判断一定要在读取流的时候用累计字节数做准。我在实现里把totalBytes maxFileBytes的判断放在每次读取后就是这个原因。如果只依赖入口那一次检查遇到chunked请求等于没限制。4.2 排队式限流引发的超时问题比想象中更复杂令牌桶做成了“拿不到令牌就等待”之后带来了一个隐蔽问题服务端在排队等待令牌客户端的HTTP连接也在倒计时。比如客户端默认超时30秒服务端允许等待预算35秒客户端早就断了服务端还在傻傻地等待令牌最后把文件写了一半丢弃浪费带宽还留下临时文件。处理这个问题的思路是“快速失败优于慢速堆积”。现在更推荐的是限流触发时不要无限等待而是返回429客户端收到后做指数退避重试。这样虽然看起来“拒绝了”但每个请求占用的时间很短系统整体吞吐反而更高。对于真正的大文件还要配合分片上传。我们在影像平台里把单文件切成5MB一个分片每个分片单独上传、单独限流、单独重试这样即使某个分片因为限流失败重试成本也只是5MB的流量而不是整个200MB。4.3 错误码和提示语义决定前端用户能不能看懂流量控制触发后返回的错误码如果跟前端没有约定体验会非常糟糕。我固定了几个语义HTTP状态码含义前端处理策略413文件/请求体超过大小限制直接提示用户“文件过大”引导压缩或分片429并发数满或速率超限提示“当前上传人数较多请稍后重试”配合自动重试机制500服务端存储异常提示“上传失败请重试”同时告警排查这里面最容易被忽视的是前端拿到429后如果没有任何重试逻辑用户会反复点击产生“重试风暴”。正确做法是前端在429响应后做递增退避第一次2秒、第二次4秒、第三次8秒最多重试5次之后提示用户手动操作。4.4 流量数据埋点和告警水位限流组件加好了如果看不到数据等于白做。我在上传链路里埋了几类指标上传速率直方图每次提交的字节数除以耗时得到每秒传输速率落进Prometheus Histogram。限流等待时长记录tryAcquireWithWait里实际等待的时间用来判断当前速率阈值是否太紧。拒绝次数和比例按413、429分别计数和总上传量做除法。临时目录磁盘占用监控java.io.tmpdir所在磁盘的剩余空间防止临时文件堆积。告警水位我按经验设为带宽利用率持续5分钟超70%时告警429比例超过总上传量的0.5%时告警临时目录磁盘使用率超70%时告警。这三个条件独立触发避免单一指标波动误报。5. 多实例部署下流量控制还得再加一层5.1 单机令牌桶在多节点下的隐患我们最开始只在单机验证了流量控制效果很好但部署三节点集群后发现了新问题每个实例都维护自己的令牌桶单实例速率限制是12MB/s三实例加起来就是36MB/s仍然可能打满链路配额。解决思路有两个方向。一是把令牌桶下沉到Redis用Lua脚本保证原子性让所有实例共享一个全局令牌桶二是干脆不在应用层做速率限制了把流量控制前移到统一网关层。Redis令牌桶的问题在于网络开销每次读取都要多一次RTT在高频小分片上传场景下性能一般。我后来采用的是混合策略网关层做粗粒度的连接数和请求大小限制应用层做精细的并发和速率控制两层各管一段。5.2 网关层挡在大文件进入应用之前金融保险系统前面通常有Nginx或其他负载均衡组件。网关层面的做法很直接client_max_body_size设置一个比业务上限略高的值超过直接拒绝根本不进入后端。limit_conn按IP限制连接数防止单个客户端用大量连接打满上传通道。API网关可以按客户端ID做维度限制比IP更精确。网关层和应用层的限流有一个协同问题如果网关层限制过严应用层根本看不到流量业务上会误判网关故障如果过松又起不到保护作用。我常用的经验是网关层的阈值设为应用层阈值的1.2倍到1.5倍保留一些缓冲让应用层有处理空间。5.3 长期方案把上传流量从应用链路中卸掉应用层限流做得再精细也只是在“流量必须经过应用链路”的前提下做控制。公有云或混合云场景下更彻底的做法是利用对象存储直传应用服务器只负责生成签名URL客户端直接上传到存储服务完全绕开应用带宽。签名URL方案有几个好处不占应用服务器带宽、支持断点续传、存储侧自带单连接速率限制。代价是权限控制更复杂而且某些金融保险的私有化网络环境不允许数据直传外部存储那时候还是要把应用层限流方案做扎实。所以我的建议是应用层限流是地基必须做好存储直传是可选的上层优化不能替代地基。最后分享几个实操体会。限流参数一定要在接近真实的压测环境里调我最初按理论带宽算出的速率阈值偏大压测时直接把链路打到了85%后来压到阈值的70%才安全。另外限流触发后的用户体验要当作功能需求来做不能只想着“保护系统”否则用户遇到一次429就可能放弃上传。还有日志里务必加上全局请求ID把上传耗时、等待时间、文件大小、目标存储路径关联起来排查问题时会省下大量时间。流量控制这件事看着是几行代码和一个组件真正做好靠的是对整条链路的理解。