设计一个支持大规模在线课程的系统，需要考虑高并发（如开学季同时有数千学生登录）、实时互动（如直播课、在线问答）以及数据一致性（如学生作业提交、成绩记录）。请描述系统的主要组件、通信方式以及如何保证实时性和数据一致性。

东南大学管理后备人才计划专职辅导员难度：困难

答案

1) 【一句话结论】：采用微服务架构，通过API网关统一入口，服务间用gRPC/REST通信，实时互动服务部署WebSocket实现双向通信，作业提交通过消息队列（如Kafka）异步处理并保证幂等性，成绩等关键数据用Saga模式分布式事务保证强一致性，用户/课程等数据通过Redis缓存+数据库分库分表提升高并发性能。

2) 【原理/概念讲解】：老师口吻，解释系统组件与通信：
系统由用户服务（处理登录注册，高并发用Redis缓存用户会话，数据库按用户ID哈希分库、读写分离）、课程服务（管理课程信息，按课程ID分表，缓存热门数据）、实时互动服务（直播课/问答，客户端用WebSocket建立长连接，服务器端通过Redis存储用户会话状态，实现断线重连，类比“直播室里的座位卡，断线后重新入座还能看到之前的聊天记录”）、作业服务（作业提交，先写入Redis临时存储，再发布消息到Kafka）、成绩服务（记录成绩，消费Kafka消息时检查数据库是否已存在记录，避免重复计算）组成。
通信方式：API网关做负载均衡和认证，服务间用gRPC（高效、强类型）或REST，实时互动用WebSocket（双向实时通信）。
数据一致性：作业提交用消息队列保证最终一致性（异步处理，避免阻塞），成绩修改用Saga模式（分解为多个本地事务，通过消息队列协调，失败时触发补偿，避免全局锁）。

3) 【对比与适用场景】：

实时通信协议对比：
| 协议 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| WebSocket | 基于TCP的长连接，双向实时通信 | 低延迟、双向、持久连接 | 直播课、在线问答、实时聊天 | 需要服务器支持，客户端保持连接，需处理断线重连 |
| Server-Sent Events (SSE) | 单向从服务器推消息 | 实时、单向、简单 | 通知（如成绩更新）、数据流 | 仅支持单向，连接断开后无法重新建立，不适合双向互动 |
数据一致性策略对比：
| 策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 强一致性（Saga模式） | 分解为多个本地事务，通过消息队列协调，失败时补偿 | 严格一致性，避免数据不一致 | 关键数据（成绩、考试记录） | 补偿操作复杂，可能增加延迟；高并发下补偿任务可能堆积 |
| 最终一致性（消息队列） | 异步处理，最终达到一致 | 低延迟、高吞吐 | 作业提交、用户行为日志 | 需要幂等性机制，避免重复处理 |

4) 【示例】（作业提交流程伪代码）：

客户端请求：POST /api/assignment/submit?assignmentId=1&content=作业内容
1. 作业服务接收请求：
   a. 将作业信息写入Redis（key: assignment:temp:{assignmentId}，value: {content, userId}）
   b. 发布消息到Kafka主题“assignment_submit”，消息key为assignmentId
2. Kafka消费者（成绩服务）处理消息：
   a. 从Redis获取临时作业信息（key: assignment:temp:{assignmentId}）
   b. 检查成绩表（grade_table）中是否存在该作业的记录（根据assignmentId）
   c. 若存在，跳过处理（幂等性）
   d. 若不存在，计算分数（如根据内容评分），写入成绩表（grade_table），并更新用户成绩记录
   e. 发布消息到“grade_update”主题（通知用户成绩更新）
3. Kafka消费者（用户服务）处理“grade_update”消息：
   a. 更新用户成绩记录（如用户成绩表）
   b. 发送成绩通知（如推送消息）

5) 【面试口播版答案】：设计支持大规模在线课程系统，核心是微服务架构。组件包括用户、课程、实时互动、作业、成绩服务，通过API网关统一入口。实时互动用WebSocket长连接，保证直播课、问答的实时性，客户端断线后通过Redis缓存会话状态实现重连。作业提交通过消息队列（如Kafka）异步处理，消息key为作业ID，确保幂等性（避免重复计算成绩）。成绩修改等关键操作用Saga模式分布式事务，将事务分解为多个本地操作，失败时触发补偿，保证数据一致性。用户/课程数据通过Redis缓存+数据库分库分表（如用户按ID哈希分库，课程按ID分表），读写分离提升高并发性能。整体通过负载均衡、缓存、消息队列处理高并发，实时性通过WebSocket，数据一致性在关键场景用事务，非关键用异步处理。

6) 【追问清单】：

问：数据库选型？比如用户和成绩用MySQL分库，课程用MongoDB？
答：用户、成绩等结构化数据用关系型数据库（MySQL，分库分表），课程内容等非结构化数据用NoSQL（MongoDB），提升灵活性和性能。
问：缓存雪崩怎么办？
答：设置合理的过期时间（如随机偏移），配置热点key的分布式锁（如Redis分布式锁），或者用Redis集群+本地缓存，避免集中过期导致服务崩溃。
问：消息队列选型？比如Kafka vs RabbitMQ？
答：Kafka适合高吞吐、持久化，适合作业提交的异步处理；RabbitMQ适合需要确认的消息（如成绩通知），保证消息可靠投递。
问：实时互动的延迟控制？
答：WebSocket服务器部署在CDN节点，靠近用户，减少网络延迟；服务器端优化消息处理（如批量推送），确保延迟低于200ms。
问：容灾方案？
答：多活部署，主从切换，数据备份到异地，实时互动服务有热备节点，故障时快速切换，保证服务可用性。

7) 【常见坑/雷区】：

忽略会话管理：未用Redis存储用户会话，导致断线后无法恢复连接状态，影响直播课、问答体验。
消息队列无幂等性：作业提交时未检查数据库记录，导致重复计算成绩，影响数据一致性。
分布式事务滥用：所有操作都用Saga模式，导致补偿操作复杂，高并发下补偿任务堆积，影响性能。
缓存策略不当：未设置缓存预热或热点key保护，导致缓存雪崩，数据库压力过大。
数据库分片策略错误：未按业务逻辑分片（如用户按ID哈希，课程按ID范围），导致数据倾斜，查询性能下降。