毕业设计实战：从零构建一个高可用的刷题平台后端架构-深圳市維司達科技有限公司

毕业设计实战：从零构建一个高可用的刷题平台后端架构

摘要：许多学生在毕业毕业设计实战：从零构建一个高可用的刷题平台后端架构

摘要：许多学生在毕业设计中选择开发刷题平台，却常因缺乏工程经验而陷入性能瓶颈、接口混乱或数据一致性问题。本文基于真实毕业设计场景，详解如何使用 Spring Boot + MyBatis Plus + Redis 构建具备题目管理、用户提交、判题回调等核心功能的后端系统。通过引入消息队列解耦判题服务、利用 Redis 缓存热点题目、设计幂等性提交接口，显著提升系统吞吐量与稳定性。读者将获得一套可直接复用的模块化代码结构与部署 checklist。

1. 背景痛点：学生项目常见“三座大山”

毕业设计里做“刷题平台”听起来简单，落地时却常被以下问题卡住：

判题阻塞：同步判题导致线程长时间挂起，并发一上来整站 504。
重复提交：前端连点两下“提交”，数据库里出现两条记录，用户一脸懵。
冷启动延迟：题目列表接口每次全表扫描，首页打开 3 s 起步，答辩现场直接翻车。

这些痛点本质上是“学生项目”与“工程系统”之间的鸿沟：功能代码能跑，但缺容错、缺横向扩展、缺观测手段。下文用一套最小可用、却可线性扩展的架构，带你把“玩具”升级成“产品”。

2. 技术选型：为什么不是 Django，也不是本地内存

维度	Spring Boot	Django/Flask	结论
依赖注入与 AOP	原生支持	靠第三方	Spring 生态对事务、幂等、重试的封装更成熟
横向扩展	无状态 Jar + 任意注册中心	Python GIL 限制多进程利用率	Java 多线程模型更适合 CPU 密集判题
社区组件	MyBatis Plus、Spring Cloud、RocketMQ	相对分散	企业级方案直接搬来即用

缓存方案对比：

本地内存：进程重启即失效，多实例时缓存漂移，无法横向扩展。
Redis：独立进程，可集群；支持 TTL、LRU、Pub/Sub，天然适合“热点题目”与“判题结果”缓存。

综上，后端主栈锁定Spring Boot 2.7 + MyBatis Plus + Redis 6.x + RocketMQ 4.9，部署在 2C4G 单机上即可抗住毕业设计答辩并发。

3. 模块划分与核心实现

系统分三层：网关层（Nginx）、业务层（Spring Boot）、判题层（Sandbox）。本文聚焦业务层，内部再拆为：

题目服务（Problem Service）
提交服务（Submit Service）
判题回调（Judge Callback）

3.1 题目服务：缓存 + 分页 + 索引

热点题目（近 7 日提交量 Top 200）在 Redis 采用hash结构缓存，字段即题号，值序列化为 JSON；冷数据走 DB，分页用 MyBatis Plus 的Page对象。缓存穿透用布隆过滤器拦截，缓存雪崩加随机 60–120 s 的 TTL jitter。

3.2 提交服务：接口幂等性设计

前端提交时携带client_submit_id（UUID），后端用数据库唯一索引实现幂等：

UNIQUE KEY uk_user_submit (user_id, client_submit_id)

重复请求直接返回原结果，避免重复入库。核心代码见第 4 节。

3.3 判题回调：消息队列解耦

提交服务只负责“写记录 + 发消息”，不等待判题结果；Sandbox 判完后向 MQ 发送JudgeFinishedEvent，业务层消费后更新状态。事件体例如下：

{ "submitId": 142857, "result": "AC", "time": 120, "memory": 65536 }

消费端幂等：利用submitId做幂等键，更新前判断状态是否已终态（AC/WA/TLE 等），防止重复累加通过数。

4. 关键代码片段（含注释）

4.1 SubmitController——接收提交、幂等保护

@RestController @RequestMapping("/api/submit") @RequiredArgsConstructor public class SubmitController { private final SubmitService submitService; /** * 1. 幂等键：clientSubmitId * 2. 事务边界：仅落库与发消息，不等待判题 */ @PostMapping public ApiResult<SubmitDTO> submit(@LoginUser Long userId, @Valid @RequestBody SubmitRequest req) { // 重复提交直接返回 SubmitDTO exist = submitService.getByUserAndClientId(userId, req.getClientSubmitId()); if (exist != null) { return ApiResult.success(exist); } // 新提交：本地事务 = 写库 + 发 MQ SubmitDTO dto = submitService.doSubmit(userId, req); return ApiResult.success(dto); } }

4.2 JudgeEventConsumer——消费判题结果，保证幂等

@Component @RocketMQConsumer(topics = "topic_judge_result") @Slf4j @RequiredArgsConstructor public class JudgeEventConsumer { private final SubmitService submitService; private final RedisTemplate<String, String> redisTemplate; @Override public void onMessage(JudgeFinishedEvent event) { Long submitId = event.getSubmitId(); String key = "judge:result:" + submitId; // 1. 利用 Redis setnx 做分布式锁，防并发重复消费 Boolean absent = redisTemplate.opsForValue().setIfAbsent(key, "1", Duration.ofMinutes(5)); if (Boolean.FALSE.equals(absent)) { log.warn("duplicate consume, submitId={}", submitId); return; } // 2. 更新库，版本号乐观锁兜底 boolean updated = submitService.updateResult(event); if (!updated) { log.error("update submit result failed, event={}", event); } } }

5. 性能与安全：并发、防刷、SQL 注入

竞争条件：
更新提交状态时使用乐观锁version字段，CAS 失败重试 3 次，仍失败则日志告警人工介入。
防刷机制：
- 接口限流：基于 Redis 的令牌桶，每用户 10 次/60 s。
- 验证码：同一 IP 5 min 内提交超过 20 次弹出图形验证码。
- 代码相似度检测：引入sim命令，重复率 > 90 % 直接判 0 分并记录。
SQL 注入：
MyBatis Plus 内置#{}预编译，杜绝拼接；动态排序用Wrapper的orderBy方法，内部白名单校验列名。

6. 生产级避坑 checklist

坑点	现象	解决
索引缺失	题目列表按`difficulty + create_time`查询 2 s	联合索引`(difficulty, create_time)`后降至 20 ms
判题超时无重试	Sandbox 宕机，消息消费成功但结果丢失	消费端 ack 前检查返回码，非 200 抛异常，MQ 自动重试 16 次
日志缺失	线上出错无法复现	接入`traceId`透传，Controller、MQ、线程池统一 MDC 打印
Redis 大 Key	缓存整表`select *`导致 value 5 MB，网卡打满	拆分为`hash`分片，只缓存必要字段
大事务	提交接口里同步调用判题 + 写库 + 更新通过数，锁等待 3 s	拆分为“写提交记录”与“更新通过数”两个事务，后者异步

7. 部署与可观测

CI 脚本：mvn -T 1C clean package -Dmaven.test.skip=true打出 fat-jar，配合systemd托管。
Dockerfile仅 30 行，基于openjdk:17-jre-slim， layers 缓存缓存依赖。
Prometheus + Grafana：
- JVM 级：GC、线程数、内存；
- 应用级：QPS、RT、提交成功率；
- 业务级：7 日 AC 率、题目冷热分布。
告警：RT > 1 s 持续 2 min 或错误率 > 5 % 即刻飞书群机器人推送。