写作思路：

1. 存储方案设计步骤：

1) 估算性能需求：分析考试试卷场景来估算存储性能需求，包括存储量、读写性能等。

2) 选择存储系统：根据技术储备、方案优缺点选择合适的存储系统。本次作业要求采用 Redis Sentinel。

3) 设计方案：基于 Redis Sentinei，设计其具体的存储方案。

2.在设计环节中，不断澄清与迭代，得到以下输出：

1) 完善 Redis 的数据结构设计，明确具体使用哪种 Redis 数据结构

2) 设计具体的读写流程

3) 根据第 1.1 步估算结果，计算 Redis sentinel 集群的服务器数量和性能

说明：

• 在 外包学生管理系统架构设计 基础上完善考试试卷存储方案

• 本次作业内容用蓝色突出显示。模块四作业更新的标题部分加 [M4] 标记，代表 Milestone 4。

1. 业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。不仅花费大量的教师资源，

处理效率也十分低下。由此带来几个明显的问题：

• 管理效率问题：学生信息管理数据信息量大、修改不方便。

• 信息质量问题：信息准确度不高，对一系列数据进行统计分析时花费时间长，占用教师宝贵的教研时间。

• 管理质量问题：学校学生信息管理工作系统化、规范化、自动化程度不高，例如学籍、课程、成绩、奖惩等。

基于以上背景，我们需要引入学生管理系统，提供系统化、规范化、自动化的手段，提供统计学生各类信息进行日常管理，如查询、修改、增加、删除、以及学生选课、成绩的查询等、成绩的查询等功能的管理系统。

2. 约束和限制

• 用户不能超过 1000 万

• 规划两期

• 第一期：上线核心功能，必须在 2022.08.30 号上线

• 第二期：上线全部功能，必须在 2023.01.30 号完成，

• 支持 PC 浏览器访问（Chrome/Firefox），支持移动端访问（安卓/iOS）

• 信息存储要求：

• 学生信息要求永久保存，毕业后也不能删除。支持离校学生信息归档、备份与查询。

• 学生作业信息至少保留一学期，登录信息至少保留 3 个月，提供手段以备查验。

• 考试结果永久保存，在校学生能够看到自己曾经的考试结果。

3. 总体架构

3.1 架构分析

3.1.1 高性能分析

登录 TPS 估算：3000/s

假设每个学生每天提交4次作业，提交作业一般是在晚上18：00~22：00。

复制代码

注册 TPS 估算：3 /s

总共1000万学生，每年只有新生注册，不同学校新生开学时间是分散的，而且注册可以在入学后完成。假设每年250万新生需要注册，注册时间分散在9.1~9.30这30天内。考虑到开学第一天人数会多一点，计算结果调整为10万每天，且主要在12小时内操作。

复制代码

考试 TPS 估算：

• 请求试卷：50,000/s

• 提交试卷：1700/s

说明：

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

复制代码

3.1.2 存储性能分析

登录信息估算 3 个月：43G

登录会产生一条登录记录，登录记录保存3个月。每条记录包含学生 ID（4字节）、登录时间（4字节）、登录 IP（4字节）。

说明：登录信息查询不做特殊考虑。只做核验备查。

学生信息估算：

• 在校学生：基本数据 2G，图片数据 10T

• 离校学生：基本数据增长 500M/年，图片数据增长 2.5T/年

说明：

学生信息主要包含学号（10字节）、身份证（19字节）、头像（图片，不超过1M）、专业（4字节）、家庭信息（100字节）等，且学生信息要永久保存，即使毕业后也不能删除。

考试信息估算：

• 在校学生：2.4T

• 离校学生：增长 0.6T/年

说明：

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

3.1.3 考试信息存储分析 [M4]

考试信息包含：考试说明、考试内容。

考试说明字段内容

试卷内容字段信息

考试信息：hset [key] [field] [value] 命令， 可以实现以考试 Id，考试信息类型 Id 为 field，考试信息为 value。

• Key: 考试 Id，根据具体业务要求设计，例如“学校 Id-学科 Id-考试序列号”。命名遵循设计规范。

• Field：考试信息 Id 考试说明、考试内容、考试结果。

• Value：考试信息的具体内容，JSON 格式。

由于考试信息为读多写少，即录入试卷的频率低，读取试卷的并发高。

采用 Redis 集群存储考试信息与试卷。

假设每门学科每年 2 次考试，每个学生平均一学期 20 门课。

每门考试的答案 20 判断题、20 选择题、4 道大题（答案 200 字以内）。

估算：每道题 500 字节，考试说明 500 字节。

试题存储空间1000万 * 20门 * （50题 * 1000字节）= 1T 
每年考试 Key 估算500个学科 * 10次考试 = 5000场考试

Redis sentinel 集群的服务器数量和性能

• 集群数量：3 节点 sentinel

• 性能：根据预估，配置 8G 内存可满足要求

Redis 性能预估

3.2 总体架构

3.2.1 业务架构

业务架构图

1. 课程管理，考试管理由课程子系统提供服务。

2. 学生管理由学生子系统提供服务。

3. 权限管理由权限子系统提供服务。

3.2.2 系统架构[M4]

系统架构图

1. 客户端请求通过 Nginx 分发到对应子系统。

2. 客户端通过业务模块向各子系统发起请求，调用增、删、改、查等 API 接口。

3. 考试子系统由 Redis 集群保证高并发性能（请求试卷 50,000/s），存储当年的考试。

4. 数据存储由 MySQL 主备架构保证数据不会丢失。业务数据保存在 MySQL，图片与试题资源可选择保存到 OSS 对象存储。

4. 详细设计

4.1 核心功能

学生管理系统核心功能包括，登录注册、文件上传下载、选课、考试。

4.1.1 登录注册

登录注册时序图

1. 学生用户账户由学校统一分配，例如教导员根据教务处信息进行账号分配。

2. 学生账号在使用前，需要根据自己的所在班级、专业，填写绑定个人绑定信息（可根据具体需求考虑，加入后台审核功能）。

3. 学生输入用户名密码登录管理系统，操作查询、选课、考试等功能。

说明：学生子系统返回的结果有成功与失败。其中失败的情况根据具体的业务提供对应业务码及错误提示信息。用户需要根据对应的提示执行相应的操作。

4.1.2 文件上传下载

文件上传下载时序图

1. 文件上传时，权限、格式等检查，由客户端保证。

2. 文件下载时，权限检查由客户端与业务模块保证。

3. 文件上传下载结果可能成功或失败。需要定义统一的错误码与客户端展示规范。

注意：这里只列举了学生用户作业附件的上传下载。考试、课程等业务功能也涉及到此功能，这里不做重复说明。

4.1.3 选课

选课时序图

1. 选课主要功能包含：课程查询、提交申请、查看结果、取消已选课程

2. 各功能提交结果可能成功或失败。需要定义统一的错误码与客户端展示规范。

3. 由于提交选课申请为集中时间，需要在课程子系统详细设计中考虑高并发情况。建议使用 Spring Boot + RabbitMQ 架构。消息队列的定义与配置需要遵顼设计规范。

注意：消息队列选型需要结合开发与运维的技术情况进行审核。

注意：由于一些同学具备脚本开发经验，需要在选课提交与查询功能增加相应的预防措施。避免因为自动化脚本影响同学的正常选课。

说明：选课流程还包括选课冲突处理，例如自动挑选，关注课程等功能。这里不做展开。可参考选课说明

4.1.4 考试 [M4]

考试时序图

1. 考试功能包含：考试查询、在线考试

2. 考试过程中可能出现意外关闭网页、打开无关网页等情况。需要在考试子系统详细设计中进行相应处理。例如防切屏、开启摄像头等。

3. 考试信息需要遵循统一、可扩展的信息格式，遵循设计规范。

说明：一些考试需要在考试完成后根据判题规则直接给出评分，这里不做展开。

4.2 关键设计

4.2.1 数据存储可靠性

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

4.2.2 高性能设计

“请求试卷”是整个系统中 TPS 要求最高的应用。在估算 1000 万人同时考试的情况下，TPS 达到 50,000/s。根据项目的实际情况，考虑到全校正常的考试实际情况，短期内单台 Nginx 可满足需求，并对部署 Nginx 的机器进行高性能调优。

4.2.3 数据存储性能

由于学生人数会逐年增加，结合数据保存的实际需求。在 MySQL 数据库表设计时，进行水平拆分。例如，针对学生信息，可按照学生的编号进行拆分。针对作业信息、考试信息、登录信息，可按照创建日期进行拆分。

说明：根据作业要求，这里不做表结构设计。

4.3 设计规范

各模块设计请遵守下列规范：

1) 使用 Spring Boot 实现业务子系统。Java 代码编码命名遵守《阿里巴巴Java开发手册》

2) MySQL 使用 Innodb 存储引擎

• 学生信息、考试信息、登录信息不允许删除

• MySQL 设计命名遵守《阿里巴巴Java开发手册》
  

3) 用 RESTful API 向客户端提供服务，接口设计需要遵守RESTful API 接口规范

4) 文件规范

• 文件上传要求，头像（图片，不超过 1M，支持 jpg, png 格式）

• 考试试题与答案要求，试题文本（图片或 pdf，单个文件不超过 5M），试题答案（使用 Excel 模板）

5) 错误码

• 业务错误码：业务模块编号+错误编号

• 系统错误码：业务模块编号+错误编号

• 错误码对应表：错误码编号，错误信息

说明：这里不做具体的业务错误编号，实际开发中需要具体模块在设计时给出自己的业务编号。系统错误码可遵守 RESTful API 常见错误码

6) 客户端错误处理

• 错误类型：网络错误、文件上传下载错误、权限错误等

• 遵守统一的客户端错误处理规范，让用户得到一致的使用体验

建议：由 UI/UX 设计统一的错误提示、错误展示设计。实现时，利用现有框架的机制进行定制处理，例如基于 Spring Boot 错误页处理机制进行定义。页面错误处理设计可参考如何设计合理友好的错误提示

7) 消息队列使用规范

• 命名规范：队列命名规则

• 结构规范：消息体规则

• 配置规范

说明：这里不做具体的规则描述，可参考RabbitMQ 使用规范

8) 题库规范

• 针对不同科目的考试，定义可扩展的题库结构

说明：这里不做具体的规则描述，一般可在数据库题库信息表设计时，结合实际考试需求进行详细设计。

9) Redis 命名规范，参考关于redis key命名规范的设计

5. 质量设计

5.1 可测试性

1）单元测试

• 后端：核心业务覆盖 Spring Boot 单元测试，RESTful API 自动化单元测试

• 前端：核心功能 Mock 数据测试覆盖

2) 链路测试

核心业务链路 Mock 点测试。

3) 日志

核心业务链路日志管理。

4) 高并发测试

核心业务高并发测试。

5.2 可维护性

1）配置可维护：构建脚本，Spring Boot 配置，Nginx 路由与配置，MySQL 配置，日志配置

2) MySQL 主备切换方案：切换备机方案

3) 数据维护：历史数据导出与备份方案，MySQL Master 数据恢复方案

4) 高并发情况，非核心业务降级方案

5.3 可观测性

管理后台提供流量监测、服务总览、JVM 监控、日志检测、存储监测等。

5.4 成本

1) 开发成本：根据团队资源估计，主要包括

• 前端：安卓/iOS，PC。至少，3 人 x 工时

• UI/UX：至少，1 人 x 工时

• 后端：Java 开发。至少，2 人 x 工时

• 管理后台：至少，1 人 x 工时

说明：开发成本根据当地价格估算。

2) 服务器成本：

• Nginx：阿里云 ECS 服务器，2CPU，4G 内存.3000 人民币/年

• 后台服务器：阿里云 ECS 服务器，8CPU, 32G 内存，9,000 人民币/年

• MySQL 服务器：MySQL 阿里云 ESSD 云盘，Master 2G 内存 5T, Slave 1G 内存 5T。200,000 人民币/年

• OSS 存储（可选）： 阿里云 OSS 图片存储，10T，10, 000 人民币/年

• 杂项：域名、软件著作权、专利等其他费用

说明：杂项成本根据实际需要估算（含增值税）。

注意：此项为通用方案，具体实施可结合客户具体要求，利用已有资源。在实施时，需要考虑具体方案的维护成本。例如，本地服务器部署，会需要相应的人员维护。

3) 运维成本

运维与部署：至少 1 人 x 工时

说明：运维成本根据当地价格估算。

4) 项目管理成本

项目经理，产品经理：至少 1 人 x 工时

说明：项目管理成本根据当地价格估算。

6. 演进规划

学生管理规划两期，采用敏捷开发（2 周一个 Sprint)：

1) 第一期：上线核心功能：

• 登录注册

• 选课：一个课程上线的基本功能

• 考试

2) 第二期：上线全部功能（含管理后台）

必须在 2023.01.30 号完成