好未来需要设计一个支持全国多校区、百万级学生、千级教师同时操作的在线课程排课系统，要求支持实时更新（如教师临时调整课时）、数据一致性（多校区同步排课信息）、高并发（开学季并发量峰值可达10万QPS）。请设计该系统的整体架构，并说明核心模块的技术选型与关键实现细节。

好未来Java难度：困难

答案

1) 【一句话结论】
采用分层微服务架构，以事件驱动实现多校区实时数据同步，结合TiDB（按校区分片）作为分布式数据库、Kafka作为消息队列、Redis作为缓存，通过最终一致性保障数据一致性，异步处理应对高并发，满足全国多校区、百万级数据、10万QPS峰值的需求。

2) 【原理/概念讲解】
首先，明确核心需求：多校区（分布式节点）、百万级学生/千级教师（海量数据与高并发）、实时更新（低延迟）、数据一致性（多校区同步）、高并发（开学季10万QPS）。

数据分片策略：按校区分片（校区是地理隔离单位，数据独立存储，跨校区查询需聚合），每个校区对应TiDB的一个分片，本地读写快，跨校区查询时聚合各分片数据（如通过SQL联接或分步查询）。
事件驱动架构：教师操作（如调整课时）→生成事件（如课程更新事件）→各校区消费事件更新本地数据，解耦服务，提升实时性。
分布式数据库（TiDB）：支持ACID和分布式分片，保证核心数据（课程表、教师信息）的一致性，按校区分片满足百万级数据存储。
消息队列（Kafka）：缓冲请求（解耦服务），高吞吐（10万+QPS）、持久化，确保事件不丢失。
缓存（Redis）：热点数据（如教师信息、课程表）存入缓存，提升响应速度，缓解数据库压力。
类比：多校区排课系统像全国连锁的订单系统，不同分店（校区）的订单通过中央系统（消息队列）同步，用缓存（菜单）加速响应。

3) 【对比与适用场景】

数据分片策略
| 策略 | 定义 | 特性 | 使用场景 | 注意点 | |---|---|---|---|---| | 按校区分片 | 每个校区对应一个数据库分片，数据隔离 | 数据独立，跨校区查询需聚合，本地读写快 | 多校区，数据本地化 | 跨校区查询延迟，需聚合逻辑 | | 按课程ID分片 | 按课程ID哈希分片，跨校区课程数据分散 | 课程跨校区，查询需跨分片 | 课程跨校区 | 查询复杂，分片键选择影响性能 |
消息队列选型
| 选项 | 定义 | 特性 | 使用场景 | 注意点 | |---|---|---|---|---| | Kafka | 分布式消息系统，基于日志存储 | 高吞吐（10万+QPS）、持久化、多消费者 | 实时日志、事件驱动 | 资源消耗大，延迟低 | | RabbitMQ | AMQP协议，队列消息系统 | 队列，消息持久化 | 中等规模，解耦 | 延迟较高，适合小并发 |
缓存策略
| 选项 | 定义 | 特性 | 使用场景 | 注意点 | |---|---|---|---|---| | Redis集群 | 内存数据库，支持读写分离 | 高性能，支持数据结构，持久化 | 热点数据（教师、课程表） | 容量有限，需缓存预热 |

4) 【示例】
教师调整课时的流程（伪代码）：
前端请求：

POST /api/teacher/adjust  
{  
  "courseId": 123,  
  "oldTime": "2024-09-10 10:00",  
  "newTime": "2024-09-10 14:00"  
}

核心服务处理：

验证教师权限
生成事件：

{  
  "courseId": 123,  
  "action": "update",  
  "oldTime": "10:00",  
  "newTime": "14:00",  
  "timestamp": 1701234567  
}

发送至Kafka主题“course-updates”
各校区消费：
从Kafka消费事件
更新本地数据库：

UPDATE course_schedule SET time = '14:00' WHERE courseId=123 AND time='10:00';

更新Redis缓存：

hset course:123 schedule, "14:00"

前端实时推送：通过WebSocket将更新后的课程表推送给学生端。

5) 【面试口播版答案】
面试官您好，针对好未来的排课系统需求，我设计的整体架构是分层微服务架构，核心是通过事件驱动实现多校区实时数据同步。具体来说，系统分为前端服务、排课核心服务（微服务）、分布式数据库（TiDB）、消息队列（Kafka）、缓存（Redis）这几层。教师调整课时时，核心服务生成事件发送到Kafka，各校区消费后同步数据，确保实时更新。热点数据存入Redis缓存，提升响应速度。高并发时，消息队列缓冲请求，开学季10万QPS峰值也能稳定运行。数据一致性通过最终一致性保障，核心数据（课程表）通过Kafka事件同步，非核心数据允许短暂不一致，不影响业务。技术选型上，TiDB按校区分片存储百万级数据，Kafka处理高吞吐，Redis集群缓存热点数据，整体满足全国多校区、高并发、实时更新的需求。

6) 【追问清单】

问题1：数据分片策略是如何设计的？如何处理跨校区查询？
回答要点：按校区分片，每个校区数据独立存储，跨校区查询时聚合各分片数据（如通过SQL联接，或先同步到中间节点再查询），确保数据一致性。
问题2：如何保证教师调整课时的实时性？延迟是多少？
回答要点：通过Kafka低延迟（亚秒级）和Redis缓存热更新，前端实时推送（WebSocket），确保用户端能快速看到更新，延迟控制在1-2秒内。
问题3：高并发下如何避免缓存雪崩？具体措施是什么？
回答要点：缓存预热（提前加载热点数据，如开学季前运行脚本加载教师、课程表数据）、设置缓存过期时间（随机偏移5-10分钟，避免集中过期）、限流（当缓存失效时，限流请求到数据库，如令牌桶算法限流）。
问题4：消息队列积压时如何处理？堆积阈值是多少？
回答要点：设置消息堆积阈值（如1000条），超过阈值时触发告警，并启动补偿机制（如重试逻辑，若重试3次失败则丢弃旧消息），确保系统稳定性。
问题5：数据一致性的具体实现？比如冲突如何解决？
回答要点：核心数据通过Kafka事件同步，采用最后写入者胜（LWW）策略，非核心数据允许短暂不一致，不影响业务，最终通过消息队列同步后达到一致。

7) 【常见坑/雷区】

数据分片策略错误：若按课程ID分片，跨校区课程查询复杂，导致延迟高，影响实时性。
缓存雪崩未处理：未做缓存预热，开学季大量请求击穿缓存，导致数据库压力激增。
消息队列积压：未设置堆积阈值，导致请求丢失，影响数据一致性。
强一致性追求：使用分布式事务（如两阶段提交）导致性能下降，不适合高并发场景。
跨校区查询延迟：未考虑聚合分片数据，导致查询延迟超过用户容忍度（如1秒），影响体验。