设计一个支持百万级用户、高并发访问的学习管理系统（LMS）课程管理模块，需支持课程创建、编辑、发布、学生选课、教师课程管理等功能，请描述其核心架构设计、关键组件、数据存储方案以及如何保证高可用性和可扩展性。
答案
1) 【一句话结论】
采用微服务架构，通过服务拆分、分布式锁、数据库分片、消息队列及缓存策略，实现百万级并发下的高可用与可扩展，重点解决选课等高并发场景的冲突与性能问题。
2) 【原理/概念讲解】
首先，课程管理模块拆分为课程服务（负责课程全生命周期：创建/编辑/发布）、选课服务（核心高并发逻辑：学生选课）、教师管理服务（教师权限控制：仅能编辑自己负责的课程）。
- 选课并发控制：多用户同时选课时，用**分布式锁（Redis SETNX）**保证原子性，避免重复选课。例如，学生选课时，先尝试获取课程ID的锁，若失败则返回“请稍后重试”，成功后检查课程剩余名额，再更新数据库并写入消息队列。
- 数据库分片：课程表按课程ID哈希分片到多个数据库实例（如10个分片），解决单库百万级数据压力。但需注意，热门课程可能集中在一个分片，导致数据倾斜（如某热门课程ID哈希结果始终落在分片1），需用随机分片或复合分片键（如课程ID+时间哈希）缓解。
- 消息队列：选课操作先写入Kafka（持久化，设置log.flush.interval.ms=100ms），消费端处理选课逻辑，确保消息不丢失。消费端需实现幂等性（如根据订单号检查是否已选），避免重复消费。
- 缓存预热：高峰前预加载热点数据（如课程列表）到Redis，每天凌晨用脚本查询所有课程数据并写入缓存，设置随机过期时间（30分钟±5分钟），避免缓存雪崩。
3) 【对比与适用场景】
| 技术方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 分布式锁 | 用Redis等实现跨服务原子操作，保证并发场景下的数据一致性 | 原子性、高可用性 | 选课、库存扣减等高并发场景 | 锁超时、死锁风险 |
| 数据库分片 | 按数据量/规则将表拆分到多库，如按课程ID哈希分片 | 扩展性、容量提升 | 大量表（如课程表、用户表） | 跨分片查询复杂，需额外路由；分片键选择影响负载均衡 |
| 消息队列 | 异步解耦服务，如选课操作写入Kafka，消费端处理 | 解耦、高吞吐、可靠性 | 业务流程中异步环节（选课、通知、支付） | 消息丢失、消费延迟、幂等性设计 |
| 缓存预热 | 高峰前预加载热点数据到缓存 | 减少高峰期数据库压力 | 课程列表、热门课程信息 | 避免缓存雪崩，需随机过期时间或分布式锁 |
4) 【示例】
选课流程伪代码（含分布式锁、分片、消息队列）：
1. 学生调用选课API（POST /api/v1/courses/{courseId}/enroll）
2. 选课服务检查课程状态（是否已发布、是否已满）
3. 获取分布式锁（Redis SETNX key:lock:course:{courseId} value:1 timeout:1000）
4. 若获取锁失败，返回“选课失败，请稍后重试”
5. 检查课程剩余名额（从分片数据库读取course表，检查enrollCount < maxEnroll）
6. 若名额不足，释放锁，返回“课程已满”
7. 若成功，更新分片数据库（increment enrollCount），并写入Kafka（topic:course-enroll）
8. 释放锁，返回“选课成功”
（分片数据库通过分片路由器（如ShardingSphere）根据courseId哈希路由到对应分片）
5) 【面试口播版答案】
各位面试官好，针对百万级用户、高并发访问的LMS课程管理模块，我的核心设计思路是采用微服务+分布式架构，重点解决选课等高并发场景的冲突与性能问题。首先，服务拆分：将课程管理拆为课程服务（创建/编辑/发布）、选课服务（核心逻辑）、教师管理服务（权限控制），通过API网关统一入口，实现请求路由和限流。选课服务中，多用户同时选课时，用**分布式锁（Redis SETNX）**保证原子性，避免重复选课；数据库层面，课程表按课程ID哈希分片到10个数据库实例（如ShardingSphere），解决单库百万级数据压力，但需注意热门课程可能集中在一个分片，导致数据倾斜。消息队列方面，选课操作先写入Kafka（持久化），消费端处理选课逻辑，确保消息不丢失，并实现幂等性（如根据订单号检查是否已处理）。缓存策略上，课程列表缓存提前加载（每天凌晨用脚本更新），设置随机过期时间（30分钟±5分钟），避免缓存雪崩。高可用设计：服务部署多实例，用Nginx负载均衡，数据库主从复制+多区域部署（如阿里云RDS多可用区），故障时自动切换。这样整体架构既能支撑百万级并发，又能保证高可用和可扩展。
6) 【追问清单】
- 追问1：选课时的分布式锁具体实现？
回答要点：用Redis的SETNX命令，设置锁的过期时间（如1秒），避免死锁，若获取失败则返回错误。 - 追问2：数据库分片键选择的影响？
回答要点：若按课程ID哈希分片，热门课程可能集中在一个分片，导致该分片负载过高，需用随机分片或结合时间+哈希的复合分片键。 - 追问3：消息队列如何保证消息不丢失？
回答要点：Kafka设置持久化（log.flush.interval.ms=100ms），消息写入磁盘后确认，消费端幂等（根据订单号检查是否已处理）。 - 追问4：缓存预热的具体实现？
回答要点：每天凌晨用脚本查询所有课程数据，写入Redis缓存（key:courses:all），设置随机过期时间（如30分钟±5分钟），避免缓存雪崩。 - 追问5：教师权限控制如何实现？
回答要点：通过Shiro结合数据库角色表，教师只能编辑自己负责的课程（根据teacherId和courseId的关联表判断），避免越权操作。
7) 【常见坑/雷区】
- 坑1：分布式锁未考虑超时，导致死锁。
雷区：锁设置过期时间过短，若业务逻辑耗时超过锁超时，其他请求会获取锁，导致死锁。 - 坑2：数据库分片键选择不当导致数据倾斜。
雷区：按时间分片（如按月份）会导致数据集中，热门课程集中在一个分片，性能下降。 - 坑3：消息队列未实现幂等性，导致重复消费。
雷区：消费端未检查消息是否已处理，导致重复选课或重复通知。 - 坑4：缓存雪崩未处理，高峰期数据库压力激增。
雷区：所有缓存同时过期，大量请求访问数据库，导致数据库宕机。 - 坑5：高可用设计未考虑多区域，故障时无法快速切换。
雷区：仅单区域部署，故障时服务中断，影响用户体验。