“开考即崩溃”——对于组织过大型考试的人来说，这四个字背后是IT电话被打爆、高管群被@、全公司等你一个交代的真实噩梦。

很多系统在演示环境里跑得丝滑流畅，一旦上了万人考场的真刀真枪，就原形毕露。问题出在哪？架构。一套能扛住万人并发的考试系统，从底层的数据流转到前端的资源加载，都必须经过专门的设计。本文拆解这个架构设计的四个核心模块，看看真正能撑住场面的系统长什么样。

一、负载均衡：别让所有请求都砸在同一台服务器上

考试系统最脆弱的时刻，就是开考那一瞬间。所有人几乎在同一秒点击“进入考试”，如果所有请求都涌向同一台服务器，这台服务器就成了千军万马要过的独木桥。

负载均衡解决的就是这个问题。它的逻辑很简单：在服务器集群前面放一个调度器，把涌入的请求均匀地分配到多台服务器上。张三被分到1号服务器，李四被分到2号服务器，每台服务器只承担自己那一份压力。

负载均衡有两个关键配置值得关注。

调度算法：轮询是最基础的方案，一台接一台轮流分配。加权轮询更进一步，给性能好的服务器多分配，性能差的少分配。最小连接数算法更智能，自动把新请求分配给当前连接数最少的服务器。对于考试场景，最小连接数通常最合适——不同考生答题速度不同，每台服务器的负载释放节奏不一样，动态判断比固定轮询更合理。

健康检查：负载均衡器需要持续检测后端服务器的健康状况。某台服务器一旦出现异常，调度器自动把它从可用列表中剔除，流量无缝切换到其他健康节点。这个过程对考生完全透明——他那台服务器宕了，请求被自动转走，他自己毫无感知。没有这个机制，一台服务器宕机就会拖累一批考生同时掉线。

选型验证方法：直接问供应商三个问题——“负载均衡用的什么方案？调度算法是可配置的吗？后端服务器宕机后流量切换需要多长时间？”

二、缓存层：把数据库保护起来

数据库是整个系统中最金贵也最脆弱的环节。如果一万人的每一次答题操作都直接读写数据库，数据库瞬间就会被打爆。缓存层的价值，就是在数据库前面加一道“防冲击屏障”。

Redis是这场保卫战的主角。 它把频繁读写的热点数据放在内存中处理，高峰期过去后再批量同步到数据库。具体到考试场景，以下几个数据是最需要被缓存保护的：

答题进度缓存：考生每答一道题，答案先写入Redis，而非直接写数据库。整场考试过程中，数据库几乎感受不到“答题”这个高频操作的存在。等到考试结束或缓存中积累了一定数量，再批量刷入数据库。如果每次点“下一题”都要等数据库写完才响应，万人场景下的延迟会高到考生砸键盘。

试卷数据缓存：一万人在同一时间打开试卷，如果每次都从数据库读取试卷内容，数据库的读取压力也是灾难级的。试卷一旦生成，就应该被缓存，后续考生的读取请求全部命中缓存，数据库只承担第一次生成试卷的计算任务。

考生登录状态缓存：考试期间需要频繁验证考生的登录状态和考试资格。这些信息放在Redis中，读写延迟在毫秒级；放在数据库中，并发高时查询可能排队几百毫秒。两者在高并发下的体验差距是指数级的。

缓存穿透的防御：缓存层不是“加上就完事”，还需要考虑防御策略。如果某个考生频繁查询一个缓存中不存在的数据，请求就会穿透缓存直接打到数据库。成熟的方案需要在缓存层做空值缓存或布隆过滤器——查询结果为空也缓存一段时间，避免重复穿透。

选型验证方法：问供应商“考试过程中，考生答题数据是先写缓存还是直接写数据库？缓存和数据库之间的同步策略是什么？缓存穿透怎么处理？”如果对方回避这些细节，大概率架构中没有真正的缓存层设计。

三、消费队列：把耗时任务排队处理，别跟考生抢资源

考试系统中有很多操作不需要即时完成，但很消耗系统资源。比如交卷后的自动判分、视频监控流的处理、行为分析日志的写入。如果这些重任务和考生答题同步争抢服务器算力，考试的流畅度就会大打折扣。

消费队列的设计逻辑是“削峰填谷”：把这些耗时任务丢进消息队列，由后台的工作进程排队慢慢处理，前端只负责快速响应用户操作。

考试场景中几个典型的队列应用：

交卷处理队列：考试结束那一分钟，可能有几千人同时点交卷。如果交卷请求直接触发判分计算，几千个判分任务同时启动，CPU瞬间飙满。正确的做法是交卷时只做两件事——保存答卷快照、返回“交卷成功”，然后把判分任务丢进队列异步处理。考生交卷后立即看到“已提交”，不需要坐在屏幕前等系统算分。

视频处理队列：监考视频的转码、存储、AI行为分析，都是典型的资源密集型任务。这些任务不应该跟考试主流程共享资源。视频流上传后进入队列，后台分批处理，处理完成后异步更新监考记录。

日志写入队列：万人考试产生的行为日志（登录、切屏、提交等操作记录）是海量的。如果每条日志都实时写入数据库，日志写入就会拖慢主业务流程。通过队列缓冲日志数据，批量写入，既保证了日志的完整性，又不影响考试体验。

选型验证方法：问供应商“考试结束那一瞬间，几千人同时交卷，判分和视频处理是怎么调度的？”合格的回答会提到队列、异步处理。如果回答是“我们服务器配置高，没问题”，说明没有做真正的异步解耦。

四、数据库层：架构的地基，细节见真章

负载均衡、缓存、队列都做对了，但如果数据库本身设计有缺陷，上面三层再完善也白搭。万人并发对数据库的要求，核心集中在读写分离、连接池管理和索引优化三个点。

读写分离：考试场景有一个显著特点——读多写少。打开试卷是读、翻题是读、查看进度是读，只有点击“下一题”或“交卷”才是写。把读操作分配到从库，写操作集中在主库，可以大幅分散数据库压力。更进一步，如果系统支持多从库，读操作可以进一步分摊到多个从库上。

连接池管理：一万个考生每人占用一个数据库连接是绝对不可能的——数据库连接数是有限的昂贵资源。连接池的作用是复用连接：一个考生操作完释放连接，下一个考生继续用。万人并发下，连接池的大小、超时时间、等待策略都需要精细调优。连接池太小，请求排队严重；连接池太大，数据库本身撑不住。这个参数没有万能值，必须根据实际压测结果调整。

索引设计：数据库查询慢不慢，索引设计是决定性因素。考试系统中，以下字段几乎是必须建索引的高频查询场景：考生ID、考试场次ID、组织架构编码、考试状态。没有索引或索引不合理，一条本来毫秒级的查询在高并发下可能劣化为秒级扫描，整个系统的性能就会被某一条慢查询拖垮。

选型验证方法：要求供应商提供一份数据库设计文档，或者直接问“你们的数据库是怎么做读写分离的？连接池是怎么配置的？哪些字段建了索引？”能清晰回答的，说明数据库层经过了专门设计。

五、实战验证：架构能扛住，案例说了算

架构设计得再合理，没上过真实考场都是纸上谈兵。判断一个考试系统的架构是否真正成熟，最直接的方式是看它有没有支撑过同等级规模的真实考试。

一个值得参照的标准是：在私有化部署领域，宏远培训考试系统支撑过多个万人级国企的实战考验。中铁一局“中铁e学”平台超过2万员工、中条山有色金属集团约1.7万员工的年度合规大考，以及山西华新燃气集团日均2万+人次的常态化安全考核，均在同一套架构下稳定运行，开考和交卷高峰期的响应延迟均在毫秒级，考生端全程无卡顿感知。

这些案例验证了一个核心规律：真正能撑住万人并发的系统，负载均衡、缓存策略、队列机制、数据库优化这四层架构缺一环不可，而且必须经过真实考试场景的反复锤炼。

六、选型核查清单

• 负载均衡用的什么方案？调度算法是否可配置？后端节点故障切换需要多长时间？

• 考生答题数据是先写缓存还是直接写数据库？缓存穿透怎么处理？

• 交卷高峰时，判分是同步处理还是丢进队列异步处理？

• 视频分析、日志写入等重任务是否与答题主流程做了资源隔离？

• 数据库读写是否分离？连接池大小如何配置？

• 能否提供同等规模（万人级）的真实考试案例，而非压测数据？

• 能否在自己环境完成1.5倍峰值的压力测试？

结语

架构这件事，平时看不见摸不着，但一到关键时刻就是天壤之别。万人同时在线不卡顿，不是靠“高性能服务器”硬扛出来的，而是靠负载均衡分流、缓存层挡冲击、消费队列削峰填谷、数据库读写分离这四层设计配合完成的。

在选型中，除了关注功能列表上的那些勾选框，更值得花时间去问供应商这些底层架构问题。很多时候，从他们回答这些问题的自信程度和细节程度，就能判断出这套系统在万人考场上是真的能稳，还是只在演示视频里能稳。