前言

本文是千万级学生管理系统的考试试卷存储方案详细设计文档，用于指导技术团队进行后续的开发、测试和运维。

词汇表

• Redis：Remote Dictionary Server

• 关系数据：数据之间的关系非常密切，互相依赖和影响，核心特征就是读的时候 Join，写的时候用事务保证一致性

• 非关系数据：数据之间关系疏松，互相独立，数据间的一致性要求很低

1. 业务背景

现在需要给教育部做一个千万级的学生管理系统，随着学生规模的扩大，需要处理的信息的数量级也不一样。现在假设学生数量为 1000 万，而这个千万级的学生管理系统需要满足登录注册、文件上传下载、选课、考试几大功能。而我们当前需要针对考试试卷存储方案进行详细设计。

2. 约束和限制

1. 方案设计必须在 2022.01.10 前完成，系统需要在 2022.04.01 前完成

2. 在校学生考试结果存储：2.4T；

   离校学生考试结果存储：每年增长 0.6T；

   试卷请求 QPS：5 万/s；

   提交试卷 TPS：1700/s。

3. 总体架构

• 试卷用 Redis 的 sentinel 模式存储

• 老师课程考试结果、学生基本信息用 MySQL 的分库分表

• 学生考试结果、登录记录、图片信息用 HBase

3.1 架构分析

为什么试卷存储用 Redis sentinel 呢？

3.2 总体架构

1. 主从复制，读写分离。

   Master 故障时 sentinel 自动切换。

4. 详细设计

[必选，描述核心场景或者流程的实现机制]

4.1 核心功能

4.1.1 考试

假设每门学科每年 2 次考试，每个学生平均一学期 20 门课，考试采取机考的方式，每门考试的答案 20 判断题、20 选择题、4 道大题（答案 200 字以内），考试结果永久保存，在校学生能够看到自己曾经的考试结果，则考试结果记录的存储量为：

• 在校学生：1000 万* 20（课）* 2（考试次数） * 1000（答案）* 2（学期） * 3（只有前三年考试）= 2.4T。

• 离校学生：每年 250 万，存储量为 0.6T。

假设学校的考试都安排在某一个月内，考试的时候请求试卷，提交答案，中间答题过程浏览器本地完成，由于考试集中在上午 4 小时和下午 4 小时，且请求试卷集中在考试开始的前 1 分钟，提交答案集中在考试结束前的 30 分钟，因此估算如下：

• 请求试卷：1000 万* 20（课）/ 20(周末不考试） / 4（每天 4 堂考试）/ 1 分钟= 250 万请求/分钟≈ 5 万/每秒。

• 提交试卷： 1000 万* 20（课）/ 20(周末不考试） / 4（每天 4 堂考试）/ 30 分钟= 1700/每秒。

4.2 关键设计

[必选，描述系统的一些关键设计点是如何实现和取舍的]

[样例（如果你有兴趣，可以对比一下 kafka 的文档：Kafka design）：

1）消息发送可靠性

业务服务器中嵌入消息队列系统提供的 SDK，SDK 支持轮询发送消息，当某个分组的主服务器无法发送消息时，SDK 挑选下一个分组主服务器重发消息，依次尝试所有主服务器直到发送成功；如果全部主服务器都无法发送，SDK 可以缓存消息，也可以直接丢弃消息，具体策略可以在启动 SDK 的时候通过配置指定。

如果 SDK 缓存了一些消息未发送，此时恰好业务服务器又重启，则所有缓存的消息将永久丢失，这种情况 SDK 不做处理，业务方需要针对某些非常关键的消息自己实现永久存储的功能。

2）消息存储可靠性

消息存储在 MySQL 中，每个分组有一主一备两台 MySQL 服务器，MySQL 服务器之间复制消息以保证消息存储高可用。如果主备间出现复制延迟，恰好此时 MySQL 主服务器宕机导致数据无法恢复，则部分消息会永久丢失，这种情况不做针对性设计，DBA 需要对主备间的复制延迟进行监控，当复制延迟超过 30 秒的时候需要及时告警并进行处理。

3）消息如何存储

每个消息队列对应一个 MySQL 表，消息队列名就是表名，表结构设计为……(此处请自行补充）

]

[技巧：常见的关键设计点包括高性能、高可用、可扩展、安全等]

4.3 设计规范

[必选，描述 Role 和 Relation 相关的开发框架、连接协议、数据包格式等]

[样例：

1）消息队列服务器使用 Spring Boot + Netty 开发

2）MySQL 使用 Innodb 存储引擎

3）TCP 包的结构设计……（此处省略，请自行补充）

]

[技巧：如果某个规范涉及内容比较多，请独立章节描述，例如数据包格式定义]

5. 质量设计

[必选，描述和质量相关的设计，包括：可测试性、可维护性、可观测性、成本等设计]

[样例：

5.1 消息队列管理后台

5.2 成本

]

[技巧：如果某个维度不涉及，也请在文档中说明，避免评审的时候被认为考虑不周全]

6. 演进规划

[必选，可以是演进规划，也可以是项目计划，需要描述每个里程碑或者版本具体要实现的能力]

[样例：

6.1 消息队列一期

6.2 消息队列二期

]

[技巧：开发阶段快速迭代，小步快跑，但要基本完善后才能正式推出给其他人用]