考试季在线阅卷大文件上传的并发处理，核心思路是把大文件切成小块、用队列控制节奏、将存储分担到多个节点这三件事做好，就能扛住几千名教师同时上传的压力。别指望单机神勇，教育行业的阅卷高峰短时间内会涌进几万份扫描件，一旦没做并发隔离，系统卡死是小，数据丢失才麻烦，这篇是写给学校信息中心老师、教务员和负责阅卷平台采购的教务主任看的，直接讲怎么识别瓶颈、怎么改配置、怎么选系统。
考试季在线阅卷系统上传慢，卡点到底在哪几个环节
很多学校以为上传慢是“网不好”，其实多数时候是服务端没做并发处理，开学考试和期末考结束当天晚上，老师们习惯性在办公室同时提交扫描件，短时间内集中上传几GB甚至几十GB的PDF和图片文件，这种情况下，多数在线阅卷系统上传慢的现象不是网络先堵住，而是服务器端接收请求的通道太窄。
上传链路拆开看，卡点有三个：
- 出口带宽。 校园网络一般是千兆到桌面，但互联网出口往往只有几百兆，几百名老师同时大文件上传，设备端路由器先丢包。
- Tomcat或Nginx的连接数。 默认配置只支持几百个并发连接，超过以后，后面的请求排队等待，反馈到界面就是转圈圈。
- 存储端写入速度。 多数学校采购的是普通NAS或服务器自带硬盘，并发写大文件时，机械盘的随机写性能迅速下降。
行业共识认为,上传瓶颈通常不在代码逻辑，而在于I/O模型，也就是说，即便阅卷平台本身功能完整，只要硬件基础设施的上传通道窄，到了考试季一样卡，先做审查，再看代码优化，顺序不能反。
大文件上传并发处理方案，为什么一定要先把文件切开
切片不是新概念,但在教育阅卷场景中其实没普及，很多平台还在用传统表单上传，一个几十MB的PDF就得传给服务器整体接收，中间只要断一次网，这个文件就作废，考试季在线阅卷大文件上传并发处理，最朴素的方案就是把文件切开。
切片上传的实际运行过程是这样的：
- 前端先用
file.slice()方法把大文件切成多块，每块大小常设定在5MB到10MB之间，具体值按平均网络质量来调节。 - 分块上传时,每块文件单独发出HTTP请求，服务器可以并行处理多块，不用管原文件整体是否到达。
- 所有切片传完后,后端读取每一块的
md5值验签，确认无误后才触发合并任务。
这个设计直接抵消了大文件传输中的两个老大难问题：超时和断点续传，一份容量为200MB的答题卡扫描件，切成20个10MB的块后，每个块即使在最差的网络环境下，上传时间也控制在几秒内，单个块失败，只要重新发起那一块的请求即可。
切片大小怎么选,需要试验对比，切太小了，比如1MB一块，一个200MB的文件产生200个请求，服务端工作量激增，反而拉低吞吐，切太大，比如50MB一块，分块失败后重传代价高，多数生产环境里，10MB是一个平衡点。
大文件上传并发处理的调度方案队列、限流与重试机制
有了切片,并发就会激增，几百个客户端同时发请求，每个客户端又同时发几十个切片的HTTP请求，服务器收到的请求数量级一下子膨胀十倍以上，如果不管控，系统照样挂，这里的解法是加一个队列层，通过限流控制传入服务器的流量。
具体做法分三步：
- 引入Redis或消息队列作为缓冲层。 前端上传切片时，先把请求打到队列重定向服务器上，由队列按照预设的速率（如每秒每客户端允许20个请求）分发到后端服务，这样后端就永远不会超出自身并发上限。
- 启用客户端并发限制。 网页端的
XMLHttpRequest或fetchAPI并不能天然限制并发请求数，在代码里需要用自定义调度器，设置同时只发送3到4个切片请求，其余排队等待，很多老师反映网页上传进度条卡住，多数时候就是浏览器同时开了太多连接。 - 设置失败重试和退避算法。 切片请求失败后，不能立刻重发，否则会给频临极限的服务器再补一刀，采用指数退避第一次失败等1秒，第二次等2秒，第三次等4秒，最多重试5次，这个方法在应付考试季集中上传时特别有效。
业内专家指出,很多平台的并发处理止步于网络层，却忘了真正的瓶颈在应用层，切片、队列、重试这三件事是一整套体系，只做其中一项，效果都有限。
在线阅卷系统哪个好用从并发与大文件角度横向对比
这是教务主任比较关心的一个问题,考试季在线阅卷大文件上传并发处理的需求各有不同，但选型逻辑是看系统架构是否具备天然的上传抗压能力，按技术路线划分，目前市面大致有三类：
| 方案类型 | 代表形态 | 上传并发能力 | 大文件友好度 | 成本范围 |
|---|---|---|---|---|
| 自建阅卷系统 | 学校自购服务器部署 | 依赖自家集群配置 | 需要二次开发切片上传 | 硬件+人力，投入较大 |
| 商业SaaS阅卷平台 | 按学期订阅云端账号 | 云厂商自动弹性扩容 | 标配分片上传+断点续传 | 按学生人数计费 |
| 混合部署 | 校内缓存+云端存储 | 本地分片上传，云端合并 | 方案成型较快 | 中等，需要定制开发 |
选型的时候别只看功能演示,直接将测试文件调整到200MB以上，用5台电脑同时上传，再看后台监控里的CPU、内存和网络指标，商用平台如果宣称支持大文件上传，通常会直接展示分片进度和传输速度，这类配置对考试季流量是有预期的。
在校内自建的情况下,为每台服务器配置4核CPU和16GB内存起步，具体配置视学生规模而定，预算有限的学校可以采用混合部署，让上传请求走校内局域网分流，降低对互联网出口的依赖，这套方案在省市级联考阅卷中较常见，备课时段和考试后时段的高峰也可以有效错开。
考前实操：三步配好大文件上传并发参数
无论用哪个平台,有些部署参数是可以在考前自己调的，这部分不求懂源码，只要会改配置文件就行。
第一步：改Nginx的请求体与连接数限制。 在物理机或虚拟机的nginx.conf中，找到http块，把client_max_body_size从默认的1m改到1024m；把worker_processes调整到CPU逻辑核心数的两倍，worker_connections调到1024，这样大文件请求就不会在入口被拒掉。
第二步：给阅卷前端设置上传并发上限。 如果系统本身就是自己开发的，在Web端调度逻辑中，设定同时最多运行4个上传任务，每个任务独立控制切片顺序，执行路径直接参考concurrency函数库或p-limit库的配置，控制在代码层面记录下来，部署时按实际带宽微调。
第三步：抬高后端内存与临时目录容量。 分片上传需要在服务端临时拼接，拼接时会产生大文件副本，将临时目录定向到系统盘的/tmp/upload_chunks，确保该分区至少保留等于“平均文件大小乘并发人数”的空间，按200人同时上传计算，预留容量按学校历史数据的平均答卷大小来做，不设硬性上限。
这套流程跑完,再配合考试前两天组织一两个备课组老师做模拟上传，压力测试生成的数据能直观反映出当前配置的负载水平，如果上传速度仍然上不去，优先检查交换机上是否有单台设备限速策略。
考试季在线阅卷大文件上传并发处理,本质上是把不可控的网络波动转化为可调度的计算任务，通过切片、限流、重试和合理的资源配置，冲击峰值完全可以被平缓掉，先把这几个环节配合好，学期中的每次考试系统压力都在可控范围内。
Q&A：考试季在线阅卷大文件上传并发处理的三个关键疑问
考试季上传提示“请求超时”是网络问题还是服务器问题？
需要分开判断,如果只有某个老师反映，多半是局域网到该办公室交换机的链路拥堵；如果整个学校多个楼层都报超时，更高可能指向服务器并发瓶颈或学校出口带宽饱和，做法是登录服务器后台查看Nginx的访问日志，若有大量499状态码，则表示客户端在发送请求时服务器已经处理不过来，需要调大worker_connections和keepalive_timeout，若日志无异常，就可以让网络中心检查防火墙或限制上行带宽的策略。
几百MB的答题卡扫描PDF传到一半断了，能不能续传？
能,前提是系统必须支持分片上传和断点续传，上传中断后，服务端保留已接收的切片，重新上传时前端会先去查询哪些切片已到位，然后只补传缺失部分。没有分片机制的平台不具备续传能力，整文件重新传来的概率几乎为百分之百。
局域网内阅卷上传是不是就不会有并发问题？
不是,局域网内部带宽虽然大，但服务器网卡叠加千兆口数量有限，多台设备同时上传时，服务端的接入层交换机依然会成为瓶颈，校园网络类型普遍是千兆到桌面，但服务器端并非每台都配万兆网卡。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/770811.html
