大考阅卷高并发场景下的数据库架构平滑演进方案

先说结论：学科网这类平台的“大考阅卷高并发”并不是一个典型的双十一秒杀场景，而是一个“平时很稳、考前瞬间涌进大量阅卷老师评分、考后集中查分”的高峰型读多写少场景。数据库要撑住的不是单一瞬间的峰值下单，而是几小时内持续涌入的判分请求、分数落库、成绩汇总和查询。这篇文章不堆概念，直接从架构演进路线、数据库拆分、缓存策略、队列削峰、平滑迁移和压测验收六个维度展开，给出一套可以直接参考落地的高并发数据库架构演进方案。

大考阅卷系统的数据库访问有几个鲜明特征：流量周期性极强、读多写少、对一致性的要求严格但可以异步收敛、故障容忍度低。考试结束后的一到两天是判分高峰期，大量阅卷老师同时在线打分，每条判分请求都要落库；考后查分阶段又是典型的读流量高峰。如果数据库架构还是单体数据库直连、集中式写库，那么在判分高峰来临时，连接数打满、锁等待飙升、慢查询拖垮主库几乎是必然结果。

很多团队遇到这种情况的第一反应是“分库分表”。但在大考阅卷这种业务里，分库分表不是第一优先级，先把连接管理、读写路径、缓存做到位，往往能解决 80% 的问题。真正的架构平滑演进，应该按照“缓存先行 -> 读写分离 -> 垂直拆分 -> 水平拆分 -> 异步化治理”的顺序推进，每一步都要有明确的验证标准，经过灰度压测后再进入下一阶段。

1. 核心问题与架构目标

在设计数据库架构之前，先把业务侧的流量模型定义清楚。大考阅卷系统通常包含以下核心流程：答题卡扫描上传、客观题自动识别、主观题人工评分、成绩复核、成绩发布查询。其中高并发压力最大的两个环节是人工评分和成绩查询。

人工评分阶段的数据库操作长这样：阅卷老师每提交一个评分，就会触发一次分数写入、一次进度更新、一次总分预计算。几千名老师同时在线操作，每个评分动作包含 2 到 3 次 SQL 操作，主库每秒新增写入可以达到几千甚至上万条。更麻烦的是，这些写入还会触发子查询和统计汇总，如果统计汇总直接在业务库里做，主库 CPU 和 IO 会同时被打满。

成绩查询阶段的压力则完全相反：百万级考生同时查分，每分钟查询请求量是日常的几十倍。这一阶段对实时性要求很高，但对数据库资源的消耗主要是读，而且查询结果基本是固定数据，非常适合用缓存和读写分离扛住。

从这张表能看出来，大考阅卷的数据库架构目标不是单纯追求“高并发写入能力”，而是在不同阶段提供不同的数据访问路径：评分阶段保障写入吞吐，查分阶段把读流量从数据库剥离，复核阶段保证一致性和审计。

2. 数据库架构平滑演进总览

这里先给出一张完整的演进路线图。与传统“一次性重构到位”的思路不同，平滑演进的核心理念是：每一步都不影响线上业务，每一步都能回退，每一步都有明确的验证指标。

第一版是单体数据库架构，应用直连 MySQL，一主一从。这个阶段能支撑的容量有限，但架构简单，适合业务初期。接下来在不到数据库的情况下，引入 Redis 和连接池治理，这一步能显著降低数据库连接压力，但不需要改表结构。第三步做读写分离，一主多从，把查询流量分流到从库，缓解主库读压力。第四步对核心业务表做垂直拆分，把用户、考试、评分、成绩等核心域拆成独立的库和服务。第五步针对流量最大的评分记录表和成绩表做水平分片，用中间件或 ShardingSphere 进行分库分表。最后在分片之上建立异步化机制和柔性事务方案，用 MQ 队列承接瞬时写入洪峰，保证最终一致性。

每一步之间都需要经历“小流量灰度 -> 全量切换 -> 压测验收”三个环节。最忌讳的是“一步到位”，直接引入分库分表中间件，然后把所有 SQL 都改一遍。这样做的结果往往不是性能提升，而是大量 SQL 不支持分片、分布式事务问题爆发、排查链路变长。

3. 第一步：连接数与缓存先行

很多高并发下数据库被打垮，并不是因为数据量大，而是因为应用端把数据库连接池全部打满了。大考阅卷场景里，判分客户端往往使用长连接反复提交请求，连接池配置不合理时，几百个并发请求就可以把 MySQL 的连接数打满，导致正常业务请求全部阻塞在连接获取阶段。

先做三件事。

第一，连接池参数显式配置。以 HikariCP 为例，连接池最大连接数不建议超过数据库实例 CPU 核心数的 2 到 4 倍。很多团队的配置错误在于 maximum-pool-size 设置过大，比如直接配成 500，结果 MySQL 端 max_connections 被打满。连接池不是越大越好，容量规划的底层逻辑是：每个连接背后都是数据库的线程和内存资源，连接数翻倍并不能等比例提升吞吐，反而会增加上下文切换开销。

第二，应用端增加重试和退避机制。当数据库连接获取超时后，不要立即重试，应该等待随机退避时间。否则高峰期会形成“重试风暴”，数据库连接被打满后，所有应用实例同时发起重连，数据库直接拒绝服务。

第三，把结果集很小的读请求全部缓存到 Redis。判分老师的阅卷任务列表、考生基本信息、评分项配置等数据，基本都是低频变更数据，完全可以把查询落到 Redis，而不是每次都打到 MySQL。这里要用“缓存预热 + 延迟双删”的策略，避免缓存击穿和缓存一致性问题。

// 连接池配置示例：按实际数据库规格调整 HikariConfig config = new HikariConfig(); config.setMaximumPoolSize(50); config.setMinimumIdle(10); config.setConnectionTimeout(3000); config.setIdleTimeout(60000); config.setMaxLifetime(1800000); config.setConnectionInitSql("SELECT 1");

缓存设计上，比较推荐“Cache-Aside + 延迟双删”的组合。请求先查 Redis，命中直接返回；未命中则查数据库，回填 Redis。更新数据库时，先更新数据库，再删除缓存，并在几百毫秒后再次删除一次，避免并发读写导致的脏缓存。对阅卷任务数这类经常变化的统计值，可以使用 Redis 的 Hash 和 ZSet 做预计算，减少对 MySQL 的实时统计压力。

// 延迟双删示例：更新 DB 后延迟删除缓存 public void updateScore(Long scoreId, Integer score) { // 1. 更新数据库 scoreMapper.updateScore(scoreId, score); // 2. 立即删除缓存 redisTemplate.delete("score:" + scoreId); // 3. 延迟再次删除，兜底并发覆盖 scheduledExecutor.schedule(() -> redisTemplate.delete("score:" + scoreId), 500, TimeUnit.MILLISECONDS); }

这里需要注意的是，缓存只能承载“读多”场景。评分写入本身必须落库，不能只写 Redis，否则一旦缓存宕机，评分数据就丢失了。正确的节奏是：写入走 MySQL，热点查询走 Redis，统计汇总走异步任务。

4. 第二步：读写分离与一主多从

当单库的读压力持续上升时，最常见的演进方向是读写分离。MySQL 的主从复制机制已经很成熟，通过一主多从架构，将查询流量分发到从库，主库只承担写入操作。

大考阅卷查分阶段的流量模型下，读写分离能发挥巨大作用。因为查询请求基本都是按考生 ID 查成绩、按班级查汇总，这些查询是只读的，完全可以路由到从库。评分阶段的写操作则集中走主库，从库通过 binlog 同步拿到最新数据。

在从库数量规划上，常见误区是“从库越多越好”。实际上，主库的 binlog 推送能力是有限的，从库数量过多会导致主库网络和磁盘 IO 压力增加。一般建议一主两从起步，如果查询压力仍然大，再对历史成绩类数据做 TTL 归档，而不是盲目增加从库数量。

读写分离之后，必须考虑主从延迟问题。考生答完题提交后，立即查询成绩，如果查询路由到从库，而主库的同步还没完成，就会查询不到数据。解决思路是按业务容忍度拆分：强实时数据走主库，可容忍秒级延迟的数据走从库。比如“阅卷老师评分后，界面立即展示最新分数”这种场景，必须走主库或采用“查询优先主库”的强制路由；而“成绩排行榜”“班级统计”这类允许延迟的场景，可以走从库。

# ShardingSphere 读写分离配置示例，按实际版本调整 rules: - !READWRITE_SPLITTING dataSources: gk_readwrite: writeDataSourceName: gk_master readDataSourceNames: - gk_slave_1 - gk_slave_2 loadBalancerName: roundRobin loadBalancers: roundRobin: type: ROUND_ROBIN

读写分离引入后，应用层要避免两类问题。第一类是事务内不能跨主从节点，一个事务内的所有读写必须路由到同一个数据源；第二类是同一请求内的多次读取，如果涉及刚刚写入的数据，必须保证主库路由，否则会出现“前一条写完、后一条查不到”的诡异问题。实践中常见做法是在 Service 层方法上增加@DS(DataSourceType.MASTER)注解，强制指定数据源。

5. 第三步：垂直拆分与领域边界划分

当单体库已经无法承载全部核心业务的访问压力时，就要开始做垂直拆分。垂直拆分的核心原则是按业务域拆分数据库，而不是按功能模块随便切开。

大考阅卷系统可以按领域拆成以下几个库：用户库（考生、老师、管理员账号），考试库（考试场次、科目、考试配置），评分库（阅卷任务、评分记录、复核记录），成绩库（考生成绩、班级汇总、统计报表）。四个库之间的关联关系，通过服务层调用完成，不再是数据库层面的 join。

垂直拆分后，数据库连接总数量不变，但是每个库的连接数被分摊开来，单库压力显著降低。同时，评分库和成绩库可以独立扩容，比如评分库的磁盘 IO 打满了，只需要扩容评分库的实例，而不需要动整个集群。

不过，垂直拆分带来的最直接问题是跨库查询。以前一条 SQL 可以 join 用户表和成绩表，拆分后 join 不到了，必须在应用层做“先查 A 库再查 B 库”的组装。解决思路有两个：一是把高频 join 的结果做宽表，在本地存储；二是接受应用层组装，把多次调用包装成接口。对阅卷系统而言，成绩汇总这类查询，建议通过异步任务预生成汇总宽表，把“实时计算”转成“预计算”。

6. 第四步：水平分库分表，什么时候做？怎么做？

水平分库分表不是提前做的，而是当单表数据量超过 2000 万行、单库连接数和 IO 都达到瓶颈、且已充分使用缓存和读写分离后才考虑的手段。大考阅卷系统中有两类数据具备分片条件：评分明细表和考生成绩表。

评分明细表是典型的高频写入表，每天新增量巨大。分片键的选择很关键。评分明细表的访问模式是“按批次查看”和“按评卷老师查看”，更合理的分片键是批次 ID 或场次 ID，而不是评分主键 ID。这样可以保证一个考试批次的数据集中存储，查询时走单分片，避免跨分片聚合。成绩表则按考生 ID 分片，查分场景下先根据考生 ID 路由到具体分片，查询性能极高。

分片之后，几个问题必须提前考虑清楚。第一是跨分片查询，比如“查整个考区的平均分”，只能通过聚合汇总表或中间件层的跨分片聚合能力解决，这两种方式都有代价。第二是分布式主键，不能依赖 MySQL 的自增 ID，要使用雪花算法或号段模式生成全局唯一 ID。第三是分片扩容问题，一次性分成 32 个分片，扩容成本低；如果分成 4 个分片，数据膨胀后再扩容，需要走数据迁移，成本非常高。

# ShardingSphere 水平分片配置示例 rules: - !SHARDING tables: score_record: actualDataNodes: gk_score_${0..31}.score_record_${0..3} tableStrategy: standard: shardingColumn: batch_id shardingAlgorithmName: batch_inline keyGenerateStrategy: column: id keyGeneratorName: snowflake shardingAlgorithms: batch_inline: type: INLINE props: algorithm-expression: score_record_${batch_id % 4}

分库分表改造的最大风险不是 SQL 语法问题，而是业务对数据一致性的预期。分片后，跨分片事务不再是数据库原生事务，需要采用最终一致性方案。大考阅卷中，评分修改这类操作，可以做成“先更新评分库分片，再发 MQ 消息，异步更新成绩库汇总分片”，保证最终一致即可。真正要求强一致的场景很少，比如分数发布后的定版数据，可以锁定为只读，不再接受修改。

如果团队不想自研分库分表，可以直接使用 ShardingSphere-JDBC 或 MyCat。前者以 jar 包方式嵌入应用，对应用侵入小，适合 Java 技术栈；后者是独立代理层，对应用透明，但需要额外部署代理节点。从性价比来看，Java 团队优先选 ShardingSphere-JDBC 即可。

7. 第五步：异步化设计与 MQ 队列削峰

数据库架构演进到最后，核心目标是把“每一条请求都同步写入数据库”变成“请求先落队列，再异步批量写入”。这一步是评分高并发场景下最有效的保护手段。

评分动作的写入链路可以这样重构：阅卷老师提交评分 -> 应用层写入 Redis 待处理队列 -> 返回“提交成功” -> 后台消费程序从队列中拉取评分数据 -> 批量写入评分库分片 -> 更新汇总数据。这样，数据库的写入压力从“每秒几千次独立写入”变成“每秒几百次批量写”，写入吞吐提升明显，同时数据库连接占用大幅降低。

批量写入时，JdbcTemplate 的 batchUpdate 比单条 insert 效率高很多，MyBatis 的 BatchExecutor 也可以达到类似效果。批大小建议设置在 500 到 1000 条，太大容易造成事务过长，太小则削峰效果不明显。除了写入，评分进度统计和成绩汇总统计也尽量通过 MQ 异步处理，把实时统计的压力从数据库剥离。

// MQ 消费者批量落库示例 @RabbitListener(queues = "score.save.queue", containerFactory = "batchContainerFactory") public void onBatchMessage(List<ScoreSaveMessage> messages) { if (CollectionUtils.isEmpty(messages)) { return; } List<ScoreRecord> records = messages.stream() .map(m -> new ScoreRecord(m.getScoreId(), m.getBatchId(), m.getStudentId(), m.getScore())) .collect(Collectors.toList()); // 批量插入，降低数据库连接压力 scoreRecordMapper.batchInsert(records); }

引入 MQ 后，有三个问题要提前规划好。一是 MQ 的消费堆积监控，评分高峰期如果生产速度远大于消费速度，队列积压会持续增长，必须设置积压报警阈值。二是消息重复消费问题，因为 MQ 至少一次语义下，消费者可能收到重复消息。落库时要做幂等设计，比如用 score_id + student_id 建立唯一索引，重复消费时捕获重复插入异常即可。三是事务消息，如果“先写数据库再发 MQ”会存在分布式一致性问题，建议先把 MQ 消息和业务数据放在同一个本地事务里，由本地消息表保证最终一致性。

8. 平滑迁移与灰度发布策略

架构演进最怕的是“一把梭”，直接切全量流量到新架构。数据库架构变更几乎没有热回退的可能，一旦分库分表完成，回退到单库的成本极高。所以要采用灰度发布策略。

平滑迁移的通用路径：存量数据全量迁移到新库 -> 开启双写 -> 校验一致性 -> 灰度切读 -> 全量切流 -> 旧库只读保留。其中双写阶段最常见的问题是数据不一致。解决方式是引入数据校验任务，定期对比新旧库中的同一份数据，发现差异则触发补偿修复。校验的核心字段包括批次号、考生号、评分值、更新时间。

在切流时，推荐按“考区”或“考试批次”维度灰度。先切换一个小的考区到新架构，观察数据库连接数、慢查询数、接口 RT、错误率，确认稳定后，再逐步扩大灰度范围。这里有一个关键原则：每次切换前必须记录当前版本的基线指标，包括 QPS、RT、错误率、CPU、内存、磁盘 IO，切换后和基线对比，偏差超过 15% 立即回滚或暂停灰度。

-- 数据校验示例：对比新旧库数据 -- 新库 SELECT batch_id, student_id, score, update_time FROM gk_score.score_record WHERE batch_id = 20240101; -- 旧库 SELECT batch_id, student_id, score, update_time FROM legacy.score_record WHERE batch_id = 20240101;

如果灰度过程中发现从库延迟很大，就要考虑同步链路优化。常见的优化手段包括：使用并行复制、加大从库的 innodb_buffer_pool_size、对主库 binlog 进行压缩传输。如果延迟依然无法接受，说明主库的写压力已经到顶，建议把低频消耗较大的统计 SQL 彻底从主库剥离，只保留在线事务写入。

9. 稳定性保障与容量压测验证

数据库架构改完，不代表线上就稳了。必须通过压测验证容量，监控每一个关键指标。

压测方法要贴合真实业务模型。评分高峰是写密集，成绩查询高峰是读密集，所以要分开压测。写场景压测时，模拟多个阅卷老师同时提交评分，逐步增加并发，观察数据库的 TPS 和事务耗时。读场景压测时，模拟大量考生查询成绩，观察从库的 QPS 和延迟。压测期间至少要采集以下指标：数据库连接数、活跃连接数、CPU 使用率、InnoDB 行锁等待次数、慢查询数量、主从延迟时间、应用层接口 RT 和错误率。

# 使用 sysbench 压测 MySQL 写入性能，参数按需调整 sysbench --db-driver=mysql --mysql-host=127.0.0.1 \ --mysql-port=3306 --mysql-user=root --mysql-password=xxx \ --mysql-db=test --table-size=1000000 --threads=32 \ --time=300 --events=0 oltp_write_only --report-interval=10 run

容量预估方面，大考阅卷场景下，可以根据历史考试数据估算峰值。假如某次考试的报名人数是 100 万，那么成绩查询高峰时，接口 QPS 可能在 1 万到 5 万之间，数据库层实际落到 MySQL 的读 QPS 可能是 1000 到 3000，其余压力被缓存扛走。评分阶段，假设同时在线阅卷老师是 5000 人，每人每 10 秒提交一次评分，那么评分落库的 TPS 在 500 左右，单库 MySQL 完全能承受。但前提是缓存和 MQ 把无效请求和无意义重试挡在了数据库之外。

另一个容易忽略的稳定性隐患是GC 问题。高并发下，应用层频繁创建 MQ 消息对象和 SQL 拼接对象，会导致 Young GC 频繁。建议统一使用对象池，避免在循环中创建临时对象；数据库连接、Redis 连接都要使用连接池复用，不要每次创建新连接。

最后是监控大盘。建议至少覆盖：应用层（QPS、RT、错误率、JVM GC）、缓存层（命中率、内存使用、大 key）、MQ 层（生产速率、消费速率、堆积量）、数据库层（连接数、活跃会话、慢查询、InnoDB 锁、主从延迟、磁盘空间）。任何一个指标出现异常趋势，都要有对应的告警规则，而不是等故障发生后再去查日志。

10. 大考阅卷高并发常见问题与排查方法

这套排查思路的核心是分层：先看应用层是否把压力拦截住了，再看中间件层是否有堆积，最后才看数据库层是否存在慢 SQL 和锁竞争。很多团队一遇到高并发故障就直奔数据库，实际大多数问题都出在连接池配置不当、缓存未命中、MQ 消费跟不上。

11. 架构演进中的最佳实践

结合学科网这类大考阅卷业务的数据库演进经验，以下几条实践值得直接落地。

第一，区分“容量问题”和“代码问题”。数据库高并发下性能下降，不一定是架构不够高级，更可能是慢 SQL 没用对索引、ORM 产生了 N+1 查询、连接池配置不合理。先做 SQL 审计和索引优化，再考虑架构升级。

第二，演进过程中保持短迭代。每做一次架构调整，都要能独立上线、独立验证、独立回滚。不要把所有优化一次性发布到生产环境，否则一旦出现问题，你根本不知道是哪一步引入的。

第三，把高并发压测做成常态化。不是上线前压一次就结束了，而是每次改动都要跑关键链路压测，保留基准报告。大考阅卷系统的场景非常固定，完全可以建立一套自动化压测流水线，每次发布前自动跑一遍。

第四，数据安全与权限隔离。阅卷系统涉及大量考生隐私数据和评分数据，数据库账号必须按最小权限原则分配，应用账号不应该拥有 DDL 权限。评分数据在落库、同步、备份的全链路中，都要做好加密和审计。

第五，保留一份“降级预案”。如果数据库压力真的扛不住，至少要能快速启用降级策略：关闭非核心统计功能、增加缓存过期调整、限制查询范围、将成绩查询切换到只读快照。降级预案要提前演练，不能等到故障发生时再去写脚本。

12. 总结：给阅卷高并发场景的架构建议

大考阅卷高并发数据库架构的平滑演进，核心不在于一次引入多复杂的技术栈，而在于把每层压力拆解掉，让数据库只承接它应该承接的流量。

从落地顺序来看，先是连接池治理和缓存，把无效请求挡在数据库之外；再通过读写分离把读流量从主库剥离；然后是垂直拆分和水平分片，解决单库容量天花板；最后用 MQ 异步化削峰填谷。每一步都以压测数据作为验收标准，通过灰度发布平滑推进。

对大考阅卷这类周期性高并发业务，不要迷信分库分表，先解决连接层和缓存层，再考虑数据分片。真正稳定的架构不是一蹴而就的，而是每一步都有度量、有比较、有验证的持续演进结果。这套方法不只是适用阅卷场景，凡是“平时平稳、高峰期集中突增”的业务，都可以参考这条演进路径。建议收藏备用，在下一个大考季来临前把数据库架构提前打磨到位。