1. 考试试卷存储-性能估算

假设在校学生数量总共为 1000 万，每个学生平均一学期 20 门课，考试都采取机考的方式，安排在某一个月内。考试的时候主要分为请求试卷、提交答案两大步骤，中间答题过程浏览器本地完成。考试集中在上午 4 小时和下午 4 小时，请求试卷操作集中在考试开始的前 1 分钟，提交答案集中在考试结束前的 30 分钟，因此估算如下：

1、请求试卷

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

请求试卷 QPS 约为：5 万/s。

2、提交试卷

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

提交试卷 TPS 约为：1700/s。

2. 考试试卷存储方案设计

2.1 请求试卷场景存储方案设计

1、数据结构设计

Key：Paper + 年度（四位年份：2022） + 学期（01-第一学期、02-第二学期等）+ 学校 ID + 课程 ID + 试卷 ID

Value：String 类型，使用 JSON 字符串存储试卷中的所有试题信息，读取后可以比较方便的分解成不同的试题，并显示在浏览器中。

2、请求试卷操作分析

待读取试卷存储在 Redis 中，Reids 采用一主二从部署结构，主从服务器均提供试卷读取功能。每台 Redis 服务器的处理能力在 5-10 万 QPS，故可以支撑试卷请求的需求。

2.2 提交试卷场景存储方案设计

1、数据结构设计

Key：Paper + 年度（四位年份：2022） + 学期（01-第一学期；02-第二学期）+ 学校 ID + 课程 ID + 试卷 ID + 学号 ID

Value：String 类型，使用 JSON 字符串存储试卷中的所有试题信息及学生的答案。

2、提交试卷分析

试卷提交后存储在 Redis 主服务中。每台 Redis 服务器的处理能力在 5-10 万 TPS，故可以支撑试卷提交的需求。

3. 考试试卷存储读写流程

一、请求试卷

1、学生登录后，请求对应课程的试卷，系统根据年度、学期、学校 ID、课程 ID 和试卷 ID 生成 Key 值，从 Redis 中查找对应的试卷信息。

2、Redis 从服务器根据 key 值查找对应的试卷信息（String），并返回。

3、系统解析试卷信息（String，JSON 格式），并格式化后，返回给浏览器。

二、提交试卷

4、学生在浏览器中阅读试卷，答题后提交。

5、系统根据根据年度、学期、学校 ID、课程 ID、试卷 ID 和学号生成 Key 值，根据试题和答题结果生成 JSON 字符串，作为 Value，提交到 Redis 进行保存。

6、Redis 主服务器根据 key 值保存包含答题结果的 JSON 字符串，并自动复制到从服务器，然后返回存储完毕。

7、系统检查是否为最后一题，如果是最后一题，则询问是否继续答题，如果不是最后一题，那么跳转到步骤 4 展示试卷，以便继续答题。

（如果步骤 6 中，提交试卷不成功，系统应该多次重试，如果多次重试仍不成功，则将失败信息返回给浏览器。）

8、学生选择是否继续答题，选择是则跳转到步骤 4 展示试卷，以便继续答题，选择否则答题结束。

4. Redis sentinel 集群架构设计

考虑到 Redis 单服务器性能在 5-10 万 TPS，因此采用一主二从三哨兵的部署架构，共部署 3 台服务器。Redis 的一主二从三个服务各自独立部署，每个服务分别部署在一台服务器上。三个哨兵分别与 Redis 的主从服务部署在一起，如下图所示：

1. 请求试卷操作，可以分散在主从服务分别进行，3 台服务器最低 15 万 TPS，可以满足读取的需要。

2. 提交试卷操作，由主服务完成，单台最低 5 万 TPS，可以满足写入需要。

3. 当 master 节点宕机时，通过哨兵(sentinel)重新推选出新的 master 节点，并重建复制关系，保证集群的可用性。