设计一个存储学生成绩、课程进度、考试数据的教育数据库，需考虑数据一致性、实时性、峰值处理，请说明数据库选型、表结构设计及优化策略。

1) 【一句话结论】采用“分布式事务型数据库（如TiDB）+ 时序数据库（如InfluxDB）+ 缓存（Redis）”的混合架构，通过TiDB保障数据一致性（ACID），用Redis缓存实时数据提升响应速度，结合InfluxDB存储考试等时序数据，整体满足实时性、峰值处理需求。

2) 【原理/概念讲解】首先解释“数据一致性”：学生成绩更新需原子性（类比银行转账，转账前余额减、后加，中间不能中断，否则数据不一致），因此需支持ACID事务的数据库。然后讲“实时性”：课程进度更新需秒级响应（如学生提交作业后立即显示进度），因此需低延迟的存储方案。接着说“峰值处理”：考试期间大量学生同时提交成绩，需分布式架构分摊负载（如读写分离、分库分表）。

3) 【对比与适用场景】

数据库类型	定义	关键特性	适用场景	注意点
MySQL	关系型数据库	强一致性、事务支持、成熟生态	学生信息、课程基础数据（非实时）	单点故障，需主从复制
TiDB	分布式事务型数据库	分布式架构、ACID、兼容MySQL	学生成绩、课程进度（需实时更新）	初始化慢，复杂查询优化需注意
InfluxDB	时序数据库	高效写入、时间序列索引	考试数据、课程进度时间序列（如每日提交量）	不支持复杂SQL，适合时序数据
Redis	缓存数据库	低延迟、内存存储	课程进度实时查询、热点数据缓存	数据易丢失，需持久化

4) 【示例】

• 表结构设计：
  • 学生表（student）：student_id（主键）、name、class_id（外键）
  • 课程表（course）：course_id（主键）、course_name、teacher_id（外键）
  • 成绩表（grade）：grade_id（主键）、student_id（外键）、course_id（外键）、score、update_time（时间戳）
  • 课程进度表（progress）：progress_id（主键）、student_id（外键）、course_id（外键）、progress_status（枚举：未开始/进行中/已完成）、last_update_time（时间戳）
  • 考试数据表（exam_data）：exam_id（主键）、student_id（外键）、course_id（外键）、exam_score、exam_time（时间戳）
• 优化策略：TiDB读写分离（考试期间主库写，从库读）；Redis缓存progress表实时状态；InfluxDB存储exam_data时间序列。

5) 【面试口播版答案】
“面试官您好，针对教育数据库的需求，我建议采用混合架构：以TiDB作为核心，保障学生成绩、课程进度等数据的一致性（ACID事务），用Redis缓存实时进度状态提升响应速度，同时用InfluxDB存储考试等时序数据。表结构上，设计学生、课程、成绩、进度、考试表，通过外键关联。优化方面，TiDB读写分离应对峰值，Redis缓存热点数据，InfluxDB处理时序查询。这样既能保证数据一致性，又能满足实时性和峰值处理。”

6) 【追问清单】

• 问题1：数据一致性如何具体实现？
  回答要点：通过TiDB的分布式事务，比如成绩更新时，先检查学生选课状态，再更新成绩和进度，确保原子性。
• 问题2：实时性怎么保证？
  回答要点：Redis缓存进度表，学生提交作业后，TiDB更新进度，Redis立即返回，延迟低。
• 问题3：峰值处理的具体方案？
  回答要点：TiDB读写分离，考试期间主库写，从库读；分库分表按课程分表，减少单表压力。
• 问题4：如果数据量很大，如何扩展？
  回答要点：TiDB水平扩展节点，增加存储和计算能力；Redis集群扩容，InfluxDB分片存储。

7) 【常见坑/雷区】

• 坑1：只选关系型数据库，忽略实时性需求，导致课程进度更新慢。
• 坑2：忽略峰值处理，单点数据库无法应对考试期间大量写入。
• 坑3：表结构设计不合理，比如成绩表没有时间戳，无法追踪更新历史。
• 坑4：缺乏缓存策略，所有查询都走数据库，导致性能下降。
• 坑5：未考虑数据一致性，比如成绩更新时未检查学生是否选课，导致数据异常。