设计一个支持百万级用户、多校区部署、支持实时直播互动、作业自动批改的在线教学平台，请描述系统整体架构，并说明如何处理高并发请求和跨校区数据一致性。

西北工业大学选调生面试指导难度：中等

答案

1) 【一句话结论】
系统采用微服务+分布式架构，通过负载均衡、分布式缓存（Redis）、消息队列（Kafka）和分库分表处理高并发，集成WebRTC+RTMP+CDN实现实时直播，作业批改通过异步消息队列+结果缓存保障实时性，跨校区数据一致性采用消息队列+延迟补偿的最终一致性方案。

2) 【原理/概念讲解】
针对百万级用户、多校区部署、实时直播互动、作业自动批改的需求，系统核心是微服务拆分，将用户、直播、作业等模块拆为独立服务，解耦强依赖，支持独立扩展。

实时直播互动：
采用WebRTC协议实现低延迟通信（类比：多人视频会议，信令服务器协调连接建立，流媒体服务器中转推流，CDN就近分发）。信令服务器（WebSocket）管理连接与ICE候选收集；流媒体服务器（Nginx-RTMP）接收多校区推流，通过CDN节点分发，降低延迟并支持并发接收。
作业自动批改：
批改服务作为Kafka消费者，接收作业提交消息（消息体含作业ID、内容、用户ID），通过多线程/消费组并发处理，调用预训练AI模型（如BERT）快速推理；结果写入本地数据库并缓存到Redis（过期时间5分钟），用户查询时先查缓存，未命中再查数据库，保障实时性。
高并发处理：
- 负载均衡：Nginx采用轮询/加权轮询算法分发请求，动态调整服务实例权重（负载高的实例权重降低）。
- 分布式缓存：冷启动时预加载用户信息、课程列表等热点数据到Redis，减少数据库压力。
- 消息队列：Kafka采用ACK=1（确保消息至少投递一次），失败重试3次（幂等性处理，避免重复批改）。
跨校区数据一致性：
消息队列持久化（Kafka日志持久化），定时同步（每分钟同步作业批改结果、用户状态），补偿服务处理延迟同步的数据（如检测到同步失败，回滚本地操作并重试）。

3) 【对比与适用场景】

架构模式	定义	特性	使用场景	注意点
单体架构	所有功能集中在一个应用中	代码耦合度高，扩展困难	小规模系统（用户少）	无法应对高并发，单节点性能瓶颈，部署复杂（一次更新全量服务）
微服务架构	拆分为多个独立服务	模块解耦，独立部署，弹性扩展	百万级用户，多业务场景	服务间通信复杂（需统一治理），需考虑服务发现、熔断等机制
分布式缓存（Redis）	高性能Key-Value存储	低延迟，支持数据持久化	热点数据缓存（如用户信息）	需防缓存击穿（布隆过滤器）、雪崩（过期时间随机化，如Redis配置：`EXPIRE key 300 random(0,100)`）
消息队列（Kafka）	异步消息传输系统	高吞吐、持久化、可扩展	异步业务（如作业批改）	需考虑消息堆积（生产者限流，如`max.in.flight.requests.per.connection=100`；消费者反压，如`max.poll.records=1000`），避免消息堆积
跨校区同步方案	消息队列+定时同步	最终一致性，延迟补偿	多校区数据同步	需监控延迟指标（如同步延迟>5分钟触发补偿），补偿服务处理异常数据（如重试、回滚）

4) 【示例】

作业提交流程（伪代码）：

1. 用户提交作业（POST /api/assignment/submit?assignmentId=456&content=...）：
   - 作业服务本地事务：`INSERT INTO assignment (id, content, userId) VALUES (456, ..., 1001);` 生成作业ID。
   - 发送消息到Kafka主题“assignment_submit”，消息体：`{"assignmentId":456, "content":"...", "userId":1001}`。
2. 其他校区批改服务消费消息：
   - 从Kafka消费消息，调用AI模型批改：`result = model.predict(content)`。
   - 结果写入本地数据库：`INSERT INTO assignment_result (assignmentId, score, feedback) VALUES (456, 85, "...");`。
   - 写入Redis缓存：`SET assignment_result_456 85 300;`（5分钟过期）。
   - 通过WebSocket通知用户：`emit("assignmentResult", {assignmentId:456, score:85});`。
3. 用户查询结果（GET /api/assignment/result?assignmentId=456）：
   - 先查Redis：`GET assignment_result_456`，存在则返回；否则查询数据库，并缓存结果。

5) 【面试口播版答案】
各位面试官好，针对百万级用户、多校区部署、实时直播互动、作业自动批改的需求，我设计的系统整体架构是微服务+分布式架构。系统拆分为用户、直播、作业等微服务，通过Nginx负载均衡分发请求。高并发处理上，用Redis缓存热点数据（如用户信息），减少数据库压力；作业批改用Kafka异步处理，避免阻塞主流程。实时直播互动通过WebRTC协议建立低延迟连接，流媒体服务器（Nginx-RTMP）接收推流，多校区通过CDN加速分发，确保低延迟。跨校区数据一致性采用消息队列+延迟补偿：作业提交后本地入库，再通过Kafka通知其他校区，批改结果同步。例如，用户登录时先查Redis缓存，缓存未命中则查询数据库并缓存；直播请求通过流媒体服务器推流，客户端实时接收；作业提交后本地入库，再发消息到Kafka，其他校区消费批改。这样既能应对高并发，又能保证跨校区数据最终一致。

6) 【追问清单】

问：如何控制实时直播的延迟？
回答要点：WebRTC低延迟协议+CDN加速节点选择（就近分发）+流媒体服务器负载均衡（动态调整推流带宽），确保多校区用户低延迟接收（目标延迟<1秒）。
问：作业自动批改的实时性如何保障？
回答要点：异步消息队列（Kafka）+结果缓存（Redis，5分钟过期）+预训练AI模型快速推理（毫秒级），用户查询时先查缓存，未命中再查数据库，保障秒级响应。
问：跨校区数据一致性的最终一致性如何保障？
回答要点：消息队列持久化（Kafka日志持久化）+分钟级定时同步（作业批改结果、用户状态）+补偿服务（检测同步失败，回滚本地操作并重试），监控延迟指标（如同步延迟>5分钟触发补偿）。
问：系统高可用性如何设计？
回答要点：微服务多实例部署（Nginx负载均衡自动切换实例）；数据库主从复制（读写分离，主库写，从库读）；Redis哨兵模式（故障时自动切换主节点），故障时服务不中断。

7) 【常见坑/雷区】

缓存雪崩：所有缓存失效导致数据库压力激增，需设置过期时间随机化（如Redis配置：EXPIRE key 300 random(0,100)，避免集中失效）。
强一致性 vs 最终一致性：强一致性（如两阶段提交）成本高，易阻塞，应采用最终一致性（如TCC、Saga），适合跨校区数据同步（如作业批改允许1-2秒延迟）。
跨校区一致性强求强一致性：强一致性需分布式事务，成本高且影响性能，需权衡业务需求（如作业批改结果，允许延迟但保证最终一致）。
服务间通信复杂：微服务间调用需考虑网络延迟、超时，用异步通信（消息队列）减少阻塞，避免同步调用导致服务雪崩（如作业批改服务阻塞主流程）。