设计一个在线考试系统，要求支持高并发（考试季同时有数千学生参与）和实时成绩反馈，请描述系统架构和关键技术点。
绍兴理工学院医务人员 (其他特技岗位)难度：困难
答案
1) 【一句话结论】
核心结论：采用微服务架构拆分业务模块，结合Kafka消息队列缓冲请求、Redis缓存提升读写性能，通过WebSocket实现实时成绩反馈，确保高并发下的系统稳定性和实时性。
2) 【原理/概念讲解】
老师口吻讲解关键概念：
- 微服务架构：将系统拆分为用户管理、考试管理、题目管理、成绩计算、实时反馈等独立服务，每个服务负责单一功能，支持水平扩展（如增加“成绩计算”服务实例应对高并发）。类比：大型演唱会，将舞台、灯光、音响等拆分为独立团队，每个团队专注自身任务，整体更灵活。
- 消息队列（如Kafka）：当用户提交答案的请求瞬间激增时，消息队列作为“缓冲区”，将请求异步处理，避免服务过载。类比：餐厅点餐高峰时，顾客排队到取餐窗口，而消息队列就像“取餐窗口的缓冲区”，先存入队列再依次处理，避免窗口拥堵。
- Redis缓存：将热门题目、用户状态等高频访问数据缓存，减少数据库压力，提升响应速度。类比：图书馆的“借阅卡”，热门书籍（高频数据）放在前台（缓存），减少去书库（数据库）找书的次数。
- 实时反馈（WebSocket）：通过长连接技术，用户提交答案后，服务端实时将成绩推送给客户端，无需轮询（如传统轮询每秒请求10次，而WebSocket单次连接可实时推送）。类比：直播间的“弹幕”，观众发送弹幕后，服务器实时推送到所有观众端，无需观众频繁刷新页面。
3) 【对比与适用场景】
| 架构模式 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 单体架构 | 所有功能模块集中在一个应用中 | 开发简单，部署方便，但扩展性差 | 小规模系统（用户量<1000），用户并发低 | 难以应对高并发，故障影响全系统 |
| 微服务架构 | 将系统拆分为多个独立的服务，每个服务负责单一功能 | 水平扩展，独立部署，故障隔离 | 大规模系统（用户量>1000），高并发场景（如考试季） | 服务间通信复杂，需统一管理（如服务注册中心） |
| 消息队列 | 定义 | 特性 | 适用场景 | 注意点 |
|---|---|---|---|---|
| Kafka | 分布式流处理平台 | 高吞吐量（10万+ QPS），持久化存储，多消费者 | 实时数据流处理（如日志收集、考试答案流） | 适合大规模数据，延迟较高（毫秒级） |
| RabbitMQ | 企业级消息队列 | 可靠性高，支持多种消息模型（如发布/订阅、工作队列） | 中等规模系统（用户量<5000），需要可靠传输 | 配置复杂，延迟较低（亚毫秒级） |
4) 【示例】
用户提交答案流程（伪代码）：
- 用户端：
- 登录后通过WebSocket连接“实时反馈”服务；
- 考试开始时，前端从Redis缓存（热门题目）加载题目；
- 用户提交答案：
- 发送POST请求到“成绩计算”服务（微服务）；
- 服务将答案存入Redis（临时存储）；
- 同时将答案发送到Kafka主题“exam_answers”。
- 服务端：
- 成绩计算服务：订阅Kafka主题“exam_answers”，消费消息并计算成绩（如判断答案是否正确，计算分值）；
- 计算完成后，将成绩存入Redis（用户成绩缓存），并通过WebSocket推送成绩给用户。
5) 【面试口播版答案】
面试官您好，针对高并发在线考试系统，我的设计核心是采用微服务架构拆分业务模块，结合消息队列和缓存提升性能，确保实时反馈。首先，系统拆分为用户管理、考试管理、题目管理、成绩计算、实时反馈等微服务，每个服务独立部署，支持水平扩展。当用户提交答案时，使用Kafka作为消息队列缓冲请求，避免服务过载。热门题目和用户状态通过Redis缓存，减少数据库压力。实时成绩反馈通过WebSocket建立长连接，用户提交答案后，服务端实时计算并推送成绩，无需轮询。这样设计能应对数千学生同时考试的高并发场景，保证系统稳定和实时性。
6) 【追问清单】
- 问题1：如何保证数据一致性？
回答要点：通过最终一致性（结合消息队列和缓存，允许短暂不一致，但通过重试机制保证最终一致）；或分布式事务（如两阶段提交，适用于强一致性场景，但需权衡性能）。 - 问题2：如何防止作弊？
回答要点：使用防作弊技术，如IP限制、设备绑定、答题时间监控、答案提交频率限制（如每题间隔≥30秒）、视频监控等。 - 问题3：系统如何扩展？
回答要点：微服务架构支持水平扩展（如增加“成绩计算”服务实例）；消息队列和缓存也支持水平扩展（如增加Kafka分区、Redis集群）。 - 问题4：实时反馈的延迟如何控制？
回答要点：通过WebSocket长连接减少网络延迟；成绩计算服务优化算法（如并行计算）；缓存成绩数据（Redis），快速响应。 - 问题5：数据库如何设计？
回答要点：使用分库分表（如用户表按学校分库），索引优化（如按用户ID、考试ID索引），读写分离（主从复制）。
7) 【常见坑/雷区】
- 架构设计过于复杂：过度拆分服务或引入过多技术（如过度使用微服务），导致维护成本高，反而影响性能。
- 忽略缓存策略：没有合理使用缓存（如未缓存热门题目），导致数据库压力过大，在高并发下性能下降。
- 消息队列选择不当：使用不适合高并发的消息队列（如RabbitMQ在高吞吐量下性能不足），或未考虑持久化需求（如Kafka未开启持久化，数据可能丢失）。
- 实时反馈实现错误：使用轮询而非WebSocket，导致延迟高（如每秒请求10次），用户体验差。
- 数据一致性处理不当：没有考虑最终一致性，导致数据不一致问题（如用户看到成绩与实际不符），影响成绩准确性。