设计一个支持多校区、高并发在线考试的系统，需要考虑哪些核心模块和技术选型？请说明各模块的功能以及技术选型的理由（如负载均衡、缓存、消息队列等）。

1) 【一句话结论】设计多校区高并发在线考试系统，核心是通过微服务拆分业务（用户、试卷、流程、作弊检测等），结合负载均衡、缓存、消息队列、分布式锁等中间件，重点保障系统高可用、低延迟，并防范作弊风险，关键技术包括分布式锁防并发冲突、缓存防雪崩、消息队列确保异步任务可靠。

2) 【原理/概念讲解】老师口吻，解释各模块与技术选型：

• 用户认证与权限管理：多校区用户统一注册登录，技术选型OAuth2.0+JWT，Redis缓存用户令牌（令牌过期时间=考试时长+缓冲，减少数据库压力，类比：令牌是考试入场券，过期后失效，避免重复登录压力）。
• 试卷与题目管理：分布式文件系统（如MinIO）存储题目内容（避免数据库存储大文件），MySQL存储试卷结构（题目ID、顺序等），动态组卷算法（随机抽题、难度比例），技术选型：MinIO（对象存储，高可用，支持分片）+ MySQL（关系型存储，事务支持）。
• 考试流程控制：控制考试开始/结束、时间限制、题目跳转，技术选型：Redis分布式锁（保证原子性，锁超时=考试时长+5秒+随机偏移量，防止死锁，类比：锁是考试开始的开关，避免多个服务器同时开始考试），结合Kafka异步处理成绩计算、邮件通知（避免阻塞用户界面）。
• 作弊检测模块：视频监控（Nginx-RTMP录制考生画面）、屏幕录制（记录操作过程）、IP绑定（考试前绑定IP，异常IP报警）、题目随机化（不同用户题目顺序不同），技术选型：流媒体服务器（如Wowza）存储监控视频，Redis存储IP绑定记录（键为“ip_exam_map_校区_考试ID”，值=考生ID）。
• 数据存储：用户数据、试卷数据持久化，MySQL主从复制（读写分离，主库写，从库读，分库分表按校区，如按“校区ID”分库），事务支持（确保成绩提交一致性，类比：事务是考试结束的最终确认，所有操作要么都成功，要么都失败）。
• 负载均衡：Nginx（四层）或LVS（七层），策略：轮询（简单均衡）、权重轮询（根据服务器负载，如CPU使用率）、会话保持（用户会话固定服务器，需Redis会话存储，键为“session_用户ID”，值=服务器IP），健康检查（定期ping服务器，故障时剔除，键为“server_health_服务器IP”，值=健康状态）。
• 缓存：Redis（内存数据库），缓存热点数据（用户信息、试卷列表、热门题目），设置过期时间（用户信息30分钟，试卷列表1小时），应对缓存失效（TTL过期后回源数据库，类比：缓存是考试前的复习资料，提前准备好，减少临时查找时间），缓存雪崩（随机TTL，设置TTL为T+随机偏移量，避免集中过期，技术选型：Redis的EXPIRE命令加随机偏移量），缓存穿透（布隆过滤器过滤无效请求，或设置空值缓存+过期时间，布隆过滤器类比：快速判断“请求是否可能命中缓存”的过滤器，误判率低，但无法删除）。
• 消息队列：Kafka（高吞吐、持久化），处理异步任务（成绩计算、邮件发送），确保消息不丢失（日志持久化，自动重试机制，如消息发送失败后重试3次，间隔1秒），消费者确认机制（如Kafka的ack=all，确保消息持久化后消费，类比：消息队列是成绩传输通道，确保每个成绩都传递到计算服务，不会丢失）。

3) 【对比与适用场景】

• 负载均衡策略对比：

  策略	定义	特性	使用场景	注意点
  轮询	按顺序分发请求	简单，负载均衡	服务器性能一致	可能导致某些服务器负载过高
  权重轮询	根据服务器性能分配权重	考虑服务器负载	服务器性能差异大	需要实时监控权重
  健康检查	检查服务器是否可用	确保请求到健康服务器	避免故障服务器	检查频率影响性能
  会话保持	将用户请求固定到同一服务器	保持会话状态	需要会话状态同步	分布式环境下复杂

• 缓存雪崩解决方案对比：

  方法	原理	优势	注意点
  随机TTL	设置缓存过期时间为T+随机偏移量	防止集中过期，减少数据库压力	需要动态调整偏移量
  互斥锁	使用Redis的setnx + expire实现，缓存过期时加锁，避免多个请求同时回源	确保同一时间只有一个请求回源	锁竞争高时可能影响性能

• 消息队列选型对比：

  模块	定义	技术选型	优势	注意点
  Kafka	分布式消息队列	Kafka	高吞吐（10万+QPS）、持久化、容错	需要集群部署，管理复杂
  RabbitMQ	消息队列	RabbitMQ	易用、支持多种消息模型（队列、主题、发布/订阅）	吞吐量低于Kafka

4) 【示例】（以用户发起考试开始请求为例，伪代码）：

1. 用户在多校区A的浏览器点击“开始考试”按钮，请求发送到负载均衡器（Nginx）。
2. 负载均衡器根据轮询策略，将请求分发到应用服务器1（应用服务器集群）。
3. 应用服务器1检查Redis分布式锁：尝试获取考试开始锁（键为“exam_start_lock_校区A_考试ID”，超时时间=考试时长+5秒+随机偏移量（1-3秒））。
4. 若锁获取成功：
   a. 更新数据库：将考试状态改为“进行中”，记录开始时间（SQL：UPDATE exam SET status='in_progress', start_time=NOW() WHERE id=考试ID）。
   b. 通过Kafka生产者发送消息（主题：exam_start，消息体：{“exam_id”：考试ID，“start_time”：当前时间，“campus”：校区A}，分区按考试ID）。
   c. 通知作弊检测模块：启动视频监控（Nginx-RTMP录制考生画面，流地址为rtmp://服务器IP/live/考试ID），绑定IP（Redis命令：SET ip_exam_map_校区A_考试ID_考生ID=考生IP, EXPIRE 2小时）。
5. 若锁获取失败（返回错误码：409，考试已开始）。
6. 考试过程中，用户答题时，应用服务器从Redis缓存中获取题目（若缓存未命中，回源MySQL，查询试卷题目，更新缓存，键为exam_questions_试卷ID_用户ID，值=题目列表，TTL=考试时长-已用时间）。
7. 考试结束时，用户点击“交卷”按钮，应用服务器：
   a. 通过Kafka生产者发送消息（主题：exam_end，消息体：{“exam_id”：考试ID，“end_time”：当前时间，“user_answers”：答题记录JSON}，分区按考试ID）。
   b. 消费者（成绩计算服务）消费消息，计算成绩（如按题目正确率*权重+时间奖励），将成绩存入数据库（SQL：INSERT INTO exam_results (exam_id, user_id, score, end_time) VALUES(考试ID, 用户ID, 计算结果, NOW())），并发送邮件通知（Kafka消息触发邮件服务，主题：考试结束，内容：成绩为X分）。

5) 【面试口播版答案】
各位面试官好，设计支持多校区、高并发的在线考试系统，核心是通过微服务拆分业务模块（用户、试卷、流程、作弊检测等），结合负载均衡、缓存、消息队列、分布式锁等中间件，重点保障系统高可用、低延迟，并防范作弊风险。首先，用户认证和试卷管理是基础，通过Nginx负载均衡分发请求到多台应用服务器，避免单点压力；缓存（Redis）用于存储用户信息、试卷数据等热点内容，减少数据库查询，提升响应速度。考试流程控制通过Redis分布式锁保证原子性（锁超时设为考试时长+5秒+随机偏移量，防止死锁），并借助Kafka异步处理成绩计算、邮件通知，避免阻塞用户界面。数据存储采用MySQL主从复制（读写分离）和分库分表（按校区），确保数据持久化。作弊检测模块则通过视频监控、屏幕录制、IP绑定、题目随机化（不同用户题目顺序不同）保障公平性。关键技术包括分布式锁防并发冲突、缓存防雪崩、消息队列确保异步任务可靠，整体架构支持多校区并发，满足在线考试需求。

6) 【追问清单】

• 问：如何应对缓存雪崩？
  回答要点：设置缓存随机过期时间（如T+1-3秒），避免集中过期；或使用互斥锁（Redis setnx + expire），确保同一时间只有一个请求回源数据库。
• 问：消息队列如何保证消息不丢失？
  回答要点：采用Kafka的ack=all机制，确保消息持久化后消费；结合自动重试（失败后重试3次，间隔1秒），防止消息丢失。
• 问：分布式锁在高并发下如何优化？
  回答要点：锁超时时间设为考试时长+5秒+随机偏移量，减少死锁风险；或使用更高效的分布式锁实现，如Redis Redlock（多节点加锁，提高可用性）。
• 问：考试数据一致性如何保障？
  回答要点：通过数据库事务（如ACID）结合分布式事务（最终一致性），确保考试记录、成绩等数据一致。
• 问：系统如何进行容灾？
  回答要点：数据库主从复制+备份，应用服务器集群，负载均衡器冗余，消息队列持久化，定期数据备份（如每天全量备份，每小时增量备份）。

7) 【常见坑/雷区】

• 忽略缓存雪崩的应对，导致大量请求集中回源数据库，造成性能瓶颈。
• 消息队列未配置ACK机制，导致消息丢失，成绩计算失败。
• 分布式锁未设置超时和随机偏移量，导致死锁，考试开始/结束操作失败。
• 缓存穿透未处理，导致无效请求查询数据库，造成雪崩。
• 数据库未做读写分离或分库分表，高并发下数据库性能瓶颈。