考试季在线模考提交高峰的连接复用方案，核心就一句话：把每次提交都走过的建连开销省掉，让已建立的连接在高峰窗口内反复承载请求，不管是HTTP连接还是数据库连接，复用做扎实了，几百人同时交卷也能稳住。
在线模考提交高峰，为什么连接成了瓶颈
考试季的流量特征和日常完全不一样,日常几百人在线，每人每分钟一两次操作，服务器很轻松，到了模考提交时段，几千人同时点交卷，每个请求都要经历TCP三次握手、TLS协商、后端建连、数据库认证这一整条链路，即使每步只有几十毫秒，在并发放大后也会把线程池和文件描述符吃光。
业内专家指出,在线考试系统的卡顿大多不是业务代码问题，而是连接层被打满，连接层一堵，后面所有逻辑都展不开。
常见的崩溃场景是这样：开考后一小时，大家陆续交卷，Nginx的worker连接数逼近上限，后端Tomcat线程池耗尽，数据库连接池排队，用户端表现为提交按钮转圈、白屏、超时重试，重试又带来更多请求，雪球越滚越大。
行业共识认为,这些问题的根源不是硬件不够，而是连接生命周期管理太粗糙。
在线模考系统连接池怎么配置：两个核心参数决定成败
很多人以为连接池配置就是把最大连接数调大,在线模考这种集中突发场景，池子的最小空闲连接和最大等待时间才是最值得反复调的两个参数。
最小空闲连接决定了高峰第一波能不能接住
连接池默认是懒加载,请求来了才创建连接，考试季提交高峰来临时，第一波请求全部卡在创建连接上，把最小空闲连接数调高，等于让池子里提前睡着一批已经就绪的连接。
具体操作路径,以Java技术栈常用的HikariCP为例：
- 打开
application.yml或application.properties - 将
minimum-idle从默认值调整到20至50，视单机实例规格而定 - 启动后监控
active和idle两个指标，观察空闲连接是否稳定
关键是配完之后一定要压测,模拟200人同时交卷，看第一波请求的耗时曲线，如果曲线在开头就有个明显尖峰，说明最小空闲还是不够。
最大等待时间决定了用户会不会放弃提交
连接池连接耗尽时,新的请求会排队等连接，等待时间设置过长，用户端早就超时了，请求还在后端排队，浪费资源。
更合理的做法是设置较短的等待时间,让超出处理能力的请求快速失败，然后由前端做重试或降级提示，用户看到”系统繁忙请稍后再试”，比一直转圈等一个未知结果要好得多。
在HikariCP中对应connection-timeout参数，建议压测场景下设置为2000毫秒以内，数据库侧也要同步检查，interactive_timeout和wait_timeout不要设置得太短，避免连接被MySQL主动掐断。
在线模考平台和高并发答题场景，连接复用方案对比
不同的复用策略解决不同层面的问题,实际生产环境通常组合使用，这里拆开对比各自的适用面。
| 方案 | 解决的问题 | 适用场景 | 落地成本 |
|---|---|---|---|
| HTTP Keep-Alive | 减少TCP握手次数 | 考生浏览器到网关之间的连接 | 低，网关默认配置即可 |
| 数据库连接池 | 减少数据库认证开销 | 后端服务到数据库的连接 | 低，主流框架内置 |
| 长连接服务化 | 消除反复重建连接 | 在线答题、实时保存草稿 | 中，需要维护连接状态 |
| 消息队列削峰 | 异步化提交请求 | 交卷后需要做主观题判分的场景 | 高，需要引入额外组件 |
HTTP Keep-Alive是性价比最高的一层，很多网关默认超时时间只有60秒，考试期间学生的答题页面长时间不动，连接可能已经断开，交卷时重新建连，又赶上高峰，把网关的keep-alive超时适当拉长，让活跃考生的连接在交卷前保持存活，能明显降低握手开销。
数据库连接池是后端的关键，在线模考平台和高并发答题场景的区别在于，答题过程中每个保存操作都依赖数据库，而交卷瞬间是高密度的写操作，池子大小不是越大越好，配1000个连接，MySQL光维护这1000个连接就要消耗不少内存和CPU，合理的做法是配到
100至200之间，加上上面说的快速失败机制，反而更稳。
长连接服务化一般用在有实时交互需求的功能上，例如考试过程中的题目切换、倒计时同步、草稿箱自动保存，这类连接走WebSocket或Socket.IO，连接建立后长期占用，不适用于交卷这种短促请求，但考试全程保持的连接在交卷时可以直接复用，省去一次握手。
消息队列削峰是最后的兜底手段，交卷请求先落到MQ，后端按自己的速度消费，用户端立即收到”已收到试卷”，真实判分和存储稍后完成，这套方案适合需要批改主观题的大型考试平台，中小规模模考系统引入MQ的运维成本偏高。
考期压测验证：连接复用到底有没有效
配置做完不压测等于没做,考试季前一周，至少要做两轮压测，一轮验证HTTP层，一轮验证数据库层。
HTTP层的验证用JMeter或wrk比较直接,本机执行压测命令，重点观察两个指标：
- 请求的
connect time是否稳定在个位数毫秒 - 并发500时错误率是否低于0.1%
数据库层用show processlist观察连接情况，确认没有大量连接卡在creating状态，结合Threads_connected和Threads_running两个值判断，前者是连接数，后者是真正在执行的线程数，如果二者差距长期过大，说明连接复用没生效。
还有一条实操经验值得参考：压测时不要把并发数一次性拉满，先100、再300、再500逐步爬坡，每档跑10分钟，观察连接池的曲线是否平滑，如果300并发时连接池已经逼近上限，就不要硬顶着500跑，先回头调配置。
历年考试季的故障复盘里,相当一部分高频问题出在连接配置和实际压测结果不匹配，按理说压测环境会提前暴露问题，但很多团队压测时用的是测试库，参数和生产不一致，压测数据参考价值有限，建议压测库和生产库的max_connections、wait_timeout
等核心参数保持完全一致。
连接复用方案的延伸思路
除了连接池和Keep-Alive，还有两个容易被忽略的细节。
一个是DNS解析，如果考生的客户端到服务器的DNS解析路径很长，交卷高峰时解析本身就会产生延迟，建议在CDN或HTTPDNS层做缓存，让域名解析结果就近生效。
另一个是用户端的连接数限制，浏览器对同一域名的并发连接数有限制，如果页面同时加载题目图片、音频、交卷接口等多个资源，连接可能互相挤占，考试页面上交卷相关的接口可以切到独立子域名，避免和其他静态资源抢连接。
据工信部发布的互联网服务质量相关报告,近年来全国在线教育类平台在高峰期访问延迟同比增长明显，其中近半数的性能瓶颈集中在接入层和连接管理层，这个数据和考试季的实际情况是吻合的。
回到连接复用本身,考试季在线模考提交高峰，最怕的不是请求多，而是每个请求都在重新建立连接，把连接当作可重复利用的资源，而不是一次性用品，思路就打开了。
连接复用方案常见问题
在线模考系统连接池怎么配置才算合理？
连接池大小没有标准答案,但有一个粗配方法：按预估峰值并发的10%到20%设置最大连接数，如果预估峰值1000人同时交卷，池子设100到200，先跑压测，再看Threads_running的曲线微调，多轮压测后如果连接数始终跑不满，就逐步调小，直到出现一个稳定拐点。
交卷请求是同步处理还是异步处理？
如果系统里有主观题需要人工判分,交卷一定是异步的，客观题系统里同步处理也没有问题，异步方案核心是MQ的可靠性，确认消息不丢、不重复消费，无状态化处理消息，让消费端可以横向扩容。
数据库连接池长连接会不会撑爆后端？
长连接不等于无限连接,连接池管理的是有上限的固定连接集合，撑爆后端的原因通常是最大连接数配置过高，或者空闲连接回收机制失效，检查connectionTimeout和idleTimeout的配合，确保峰值过后池子能自动收缩。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/767790.html
