设计千万级学生管理系统的考试试卷存储方案

【作业要求】

1. 基于模块 4 第 6 课的估算结果和 Redis sentinel 的初步方案设计，完善考试试卷存储方案，具体包括：

2. 完善 Redis 的数据结构设计，明确具体使用哪种 Redis 数据结构。

3. 设计具体的读写流程(可以文字描述也可以序列图描述，序列图要有文字辅助说明)。

4. 对照模块 4 第 6 课的性能结果，计算 Redis Sentinel 集群的服务器数量和性能。

【提示】

1. 性能可以有一定冗余。

2. 如果对 Redis sentinel 不熟悉， 请参考官方文档: https://redis.io/topics/sentinel

前言

我们已经完成了学生系统的初步设计，现在要针对考试考卷存储方案进行细化，并且我们非常重视此模块功能的效率，因为考试系统在 QPS 和 TPS 部分吃掉的性能很高，同时因为是在线系统，我们要尽可能的保证系统的稳定性，保证考生可以正常的开始和结束考试。

1. 业务背景

考试结果：

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

• 在校学生考试结果存储： 2.4T

• 离校学生结果存储：每年 250w, 每年增长存储量为 0.6T。

考试试卷(重点设计内容)：

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

• 请求试卷(QPS)：250w 请求/分钟 约等于 5w/s

• 提交试卷(TPS)：1700/s

2. 约束与限制

1. 架构设计完成时间：2022/11/06

2. 本次设计要完善 Redis sentinel 架构

3. 本次设计只关注考试试卷的存储架构的完善

3. 考试试卷存储总体架构

3.1 架构分析

1. 及时性

考试的 QPS 达到了 5w/s， 我们要保证考试在开始时可以顺利且无延时的获取考卷。因为试卷本身是重复读取操作，所以放在内存型数据库可以提高读取效率，降低请求延时。

这里我们选择使用 Redis sentinel 模式进行考试试卷的管理与试卷请求的响应。

2. 可用性

目前考试模块非常重要，我们要绝对保证每次的考试季都可以为考生提供稳定的能力，其中核心能力主要包括： 请求试卷 和 提交试卷

所以采用 Redis sentinel 进行服务器高可用的管理，可用性体现在两部分：

Sentinel: 采用分布式的 Sentinel 来保证哨兵系统的高可用。

Redis Server：采用 N 台 Redis 服务器构建主从模式，当主服务器出现问题时，可以通过哨兵系统重新选举。

3.2 总体架构

3.2.1 模块关系架构

3.2.2 Redis sentinel 可用性架构

4. 详细设计

4.1 核心功能

4.1.1 双路径考卷管理

所有的内容会进行两次存储，保证在突发情况下，我们一样可以找到丢失的考卷，同时文件存储中会存取所有历史的考卷。

4.1.2 读取考卷

1. 从缓存中进行试卷的读取，如果成功读取就返回。

2. 缓存读取失败，则通过文件系统进行读取，同时写入 redis 中。

3. 被标记为待考考卷的考题会多一次判断，确保缓存系统中已经有此考卷。

4.1.3 新增考卷

1. 当系统收到新增考卷请求时，生成考题 ID，将上传的文件序列化并分别存储到缓存数据库和文件系统中。

4.1.4 修改考卷

1. 当系统收到修改考卷请求时，会通过考题 ID 获取缓存中对应的考卷

2. 完成修改后，会通过考题 ID 重新写入缓存数据库

3. 同时替换文件系统中的序列化文件

4.1.5 删除考卷

1. 当系统接收到删除考卷的请求时，会通过考题 ID 删除对应的缓存数据库和文件系统中的数据

4.2 关键设计

4.2.1 Redis sentinel:

通过哨兵系统完成，主从自动升级和主从分离功能。

4.2.2 数据结构采用 K/V 模式进行存储：

Key: 考试考卷 ID

Value: 被序列化的考题

4.2.3 Redis sentinel 规模(至少两颗 CPU)：

Sentinel 系统: 3 节点

Redis 服务器：3 节点 - 1 主, 2 从

4.3 设计规范

1. Redis 设置密码访问

2. 应用采用 DNS+VIP 方式进行 Redis 集群访问

3. 应用采用先读缓存后读文件系统的方式查询

5. 质量设计

5.1 可观测性

监控 redis, 监控应用的耗时情况，能够快速的对问题进行响应

5.2 可用性

通过 redis 的哨兵系统，尽可能的保证系统的稳定性。

5.3 可测试性

负责考卷模块的测试同事，可以提前进行包括功能和性能的测试，保证应用可以满足线上的 QPS。

6. 演进规划

1. 构建 3 节点 sentinel 和 3 节点 Redis 主从服务器

2. 增加核心指标监控，保证提前可以感知问题

3. 增加 keeplive + haporxy 架构，保证集群的统一入口