“考试开始五分钟数据库连接池满了。”“交卷那一分钟慢查询把CPU打满整场考试的人都在转圈等提交。”做过在线考试系统的技术人都知道数据库是整个架构中最容易成为瓶颈的地方。应用服务器可以横向扩展负载均衡可以分流缓存可以挡读压力——但数据落盘的写压力最终都要汇集到数据库。当考生规模从百人到千人、从千人到万人单机数据库迟早撞上那堵墙。本文以宏远培训考试系统的数据库架构演进为线索拆解数据库从单机MySQL到分布式架构的完整升级路径重点介绍OceanBase等分布式数据库在考试场景中的落地实践以及不同规模下的技术选型参考。一、单机MySQL时代够用直到不够用绝大多数在线考试系统起步阶段都是单机MySQL。宏远也不例外。几百人的考试数据库压力不大。考生信息、题库数据、试卷结构、答题记录几张核心表加几个索引一条SQL下去毫秒级返回。开考瞬间几十人同时进入交卷时几十人同时提交MySQL应付得轻轻松松。问题从并发量越过某个阈值开始出现。首先是连接数瓶颈。考试场景的数据库连接不是均匀分布的——开考、翻题、交卷三个时刻数据库操作密度瞬间飙升。连接池设小了请求排队等连接考生端转圈连接池设大了数据库本身撑不住CPU报警。其次是写入瓶颈。交卷高峰时几百上千人同时提交答案每条INSERT都要落盘。单机MySQL的写入能力受限于磁盘IO一旦写入请求堆积不仅写入变慢读操作也被连带拖垮——读写共用一个实例写操作的锁和磁盘争抢会阻塞读操作。再其次是数据量瓶颈。一场千人考试的答题记录可能就有几十万条加上题库、试卷、日志、监控数据单表数据量轻松破千万。查询性能开始劣化慢查询越来越多加索引治标不治本。最后是可用性问题。单机意味着单点故障。数据库一宕整场考试瘫痪。虽然可以搭主从做高可用但主从切换有时间差考试场景对中断零容忍。这个阶段的技术方案通常是“堆配置”——换更强的服务器、上SSD、加大内存、优化SQL。这些操作能续命但治不了根。当考生规模突破万人单机MySQL的天花板就实实在在地到了。二、读写分离缓存续命方案但不是终极解单机扛不住之后宏远的第一步升级是读写分离。主库负责写入——答题记录、交卷操作、日志写入全部走主库。从库负责读取——试卷加载、题目浏览、成绩查询分摊到多个从库。通过数据库中间件配置读写操作自动路由到不同实例。同时引入Redis缓存层把高频读数据挡在数据库门外。试卷内容、考生登录状态、答题进度暂存全部放到Redis。数据库的压力骤降。这套方案在千人到数千人规模能撑相当长一段时间。但它有几个致命短板一是主库仍然是单点写入。读写分离只分摊了读压力所有写入操作还是集中在一台主库上。考试场景的写入峰值集中在交卷时刻——几千人同时提交答案主库的写入压力线性增长分离再多从库也帮不上忙。二是缓存和数据库的数据一致性问题。答题进度暂存在Redis如果Redis宕机缓存数据丢失考生的答题记录就没了。虽然可以通过持久化配置和同步策略来降低风险但架构复杂度也随之上升。三是运维成本开始膨胀。主从切换、缓存失效、数据同步延迟——出问题时排查链路变长对运维团队的要求明显提高。对于万人级并发这套架构的写入瓶颈和可用性短板仍然存在。需要一个能横向扩展写入能力的方案。三、分库分表把鸡蛋放到多个篮子里读写分离不够用之后自然会想到分库分表。按考试场次或机构维度拆分——不同考试的答题数据落到不同库、不同表。一场万人考试的数据被拆成多个分片每个分片独立处理自己那一份读写请求单个数据库实例的压力大幅降低。宏远在服务部分超大规模客户时曾采用过这一方案作为过渡。但分库分表是重武器代价很大。首先是业务侵入性强。SQL不能随心所欲写了——跨分片查询不支持、Join操作受限、聚合统计需要跨多个分片取数据再合并。以前一个简单的“统计本场考试平均分”分库后可能要先从十几个分片各取一份数据再到应用层聚合。其次是运维复杂度剧增。分片多了备份、恢复、扩容、数据迁移每一项操作的工作量都成倍增长。分片键的设计一旦定下来就很难改业务需求变了分片策略未必跟得上。最关键的是分库分表之后系统失去了数据库层面的全局事务能力。答卷提交和成绩更新这两个操作如果在不同分片上如何保证一致性这需要引入分布式事务方案而分布式事务的性能代价和复杂度又是一个大坑。很多团队走到了这一步就卡住了不分撑不住分了hold不住。四、分布式数据库换个思路让数据库自己扛分库分表的本质是把分布式问题从数据库层转移到应用层。开发人员需要自己处理路由、聚合、事务——这些本来是数据库该做的事。分布式数据库的思路正好相反把分布式能力内建在数据库内部对应用层透明。以OceanBase为例。OceanBase是蚂蚁集团自研的原生分布式数据库采用Shared-Nothing架构数据自动分片并分布在多个节点上。应用层看到的仍然是一张逻辑表无需关心数据存在哪个节点上。跨节点的查询、事务、聚合由数据库引擎内部完成。在在线考试场景中OceanBase的几个特性精准命中了单机MySQL时代的痛点写入水平扩展。交卷高峰时的大量写入操作自动分散到多个数据节点并行处理。不是一台服务器在扛写入而是一个集群在分摊。随着考试规模增长增加节点即可线性提升写入能力。原生高可用。数据多副本存储单节点故障自动切换RPO为零RTO在秒级。考试进行中某台服务器宕机考生无感知。这份高可用能力是数据库内置的不需要额外搭建主从复制和切换脚本。全局事务一致性。分布式事务由数据库引擎保证应用层不需要引入额外的分布式事务中间件。答卷提交和成绩更新在一个事务内完成数据一致性有保障。HTAP能力。OceanBase同时支持OLTP和OLAP考试过程中的高并发事务写入和考后的统计分析查询可以在同一套系统内完成不需要把数据导出到分析型数据库再做报表。五、宏远的实践OceanBase在万人考试场景中的落地宏远培训考试系统在支撑万人级高并发考试的过程中完成了从MySQL到OceanBase的数据库架构升级。以下是几个核心实践要点。迁移路径通过OceanBase官方迁移工具OMS完成全量数据迁移和增量实时同步。得益于OceanBase对MySQL协议和语法的兼容现有考试系统代码中绝大多数SQL无需修改业务改动成本可控。性能表现迁移至OceanBase后在数万人同时在线考试的场景下交卷高峰期的数据库响应延迟从原来的秒级降低到毫秒级。某大型国企年度合规考试中系统平稳支撑了超过三万人同时在线数据库层面零故障交卷成功率保持在99.9%以上。运维简化原先需要维护的主从复制、读写分离中间件、分库分表路由逻辑全部由OceanBase内置能力接管。运维团队不再需要关心数据分片策略和节点间数据同步故障切换对业务完全透明。调优经验迁移过程中也积累了一些关键经验。索引和查询需要在OceanBase环境下重新做执行计划分析分布式环境下的查询优化策略与单机MySQL有所不同。热点数据如正在进行的考试场次数据需要特别关注分片键设计避免所有请求集中到单个节点造成热点问题。六、技术选型对照你的系统该用哪种方案没有最好的数据库只有最适合当前阶段的方案。单机MySQL适用考生规模在千人以下考试频次低并发压力小。优势是运维简单、团队熟悉、成本低。读写分离Redis缓存适用考生规模在数千人读多写少峰值可控。优势是不需要大幅改造业务代码架构过渡平滑。分库分表适用考生规模在万人左右写入压力已经无法用单机解决但团队有较强研发能力来维护分片逻辑。优势是成本可控缺点是运维复杂。分布式数据库OceanBase等适用考生规模在万人以上对写入水平扩展、高可用、数据一致性有硬性要求且希望运维成本可控。宏远的实践证明这套方案在万人级考试场景中表现稳定性能天花板远高于传统方案。七、结语考试系统的数据库演进从MySQL到分布式是一条被业务增长逼出来的路。单机扛不住的时候缓存和读写分离能续命续命续不动的时候分库分表能再撑一程当分库分表的复杂度反过来吞噬研发效率时分布式数据库提供了另一种选择。宏远从MySQL走到OceanBase的过程是考试系统技术架构伴随客户规模共同成长的一个缩影。目前国内分布式数据库赛道上OceanBase是少数经过超大规模金融核心系统验证的产品。对于正在规划考试系统技术架构升级的团队如果有万人级以上高并发考试的需求可以参考宏远的实践路径把OceanBase纳入选型考察范围。最终选什么取决于团队能力、业务规模和技术债务——架构选型没有银弹只有在合适的时机做合适的选择。