业务背景

• 在校学生:1000 万

• 每年 2 次考试，每个学生一学期 20 门课，上机考试，每门考试 20 判断题、20 选择题、4 道大题

• 考试都安排在某一个月内

总体架构

性能要求分析：

考试结果记录的存储量：

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

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

考试的时候请求试卷，提交答案，中间答题过程浏览器本地完成，请求试卷集中在考试开始的前 1 分钟，提交答案集中在考试结束前的 30 分钟，因此估算如下：

• 请求试卷:1000 万 * 20(课)/ 20(周末不考试) / 4(每天 4 堂考试)/ 1 分钟 ≈ 5 万/每秒

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

存储性能估算：

1.单机不能满足存储容量，读写性能要求

2.面对 1000W 学生考试，要保证可用性，具备容灾，存储主备需要能自动切换

存储架构分析：

1.请求试卷的数据量太大 QPS 达到 5W，故选择 Redis sentinel 架构

2.提交试卷的数据 TPS 为 1.7K/s，使用 MQ 集群（具备暂时存储的中间价）+Hbase 的架构

总体架构：

考题服务架构：

• 编辑考题写部分使用 mysql 集群（主备）

• 请求考题部分使用 redis sentinel 集群扛 5W 的请求，采用分片架构，直接按试卷 ID 按 4 取模， 数据是提前预热写入的。

• 一共 4 个分片，每一个分片有一个副本，每一个分片需求扛住的请求是 1.25W/s，摊到服务器请求是 0.65W/s

• redis 的数据结构是 hash ，key 是考试 id，field 是试卷的题序，value 是题目

考题记录的服务架构：

• 答题服务采用集群服务+异步写的方式

• 其中 MQ 选择通用的的 MQ 集群（比如 Kafka），当 MQ 发送成功对外提示请求成功

• 后续消费消息逐步写入 hbase