设计一个支持千万级用户并发访问的在线学习平台（LMS），要求高可用、低延迟，请描述系统架构设计思路，包括前端、后端、数据库、缓存、消息队列等组件的选择与部署方案。
答案
1) 【一句话结论】采用微服务架构+分布式技术，通过负载均衡、多级缓存（CDN+Redis+数据库）、数据库读写分离/分片、消息队列解耦，实现高可用与低延迟，支撑千万级用户并发访问。
2) 【原理/概念讲解】
老师：咱们先讲核心概念，比如“微服务”。微服务是把一个大系统拆成多个独立的小服务，每个服务负责单一功能（比如用户服务、课程服务、支付服务），这样每个服务可以独立开发、部署和扩展，适合高并发场景。
再比如“负载均衡”，就像学校门口的“分餐台”，把大量学生（请求）均匀分给多个食堂（后端服务器），避免单台服务器过载，提升并发处理能力。
“缓存”是关键，比如Redis像“快递柜”：用户先去快递柜取件（缓存命中），如果没找到再联系快递员（数据库查询），减少数据库压力。我们采用三级缓存：CDN缓存静态资源（图片、视频），Redis缓存热点数据（用户信息、课程列表），数据库作为持久化存储。
“数据库分片”是把大表拆成多个小表，比如把“用户表”按ID哈希分到多个数据库实例，分散数据存储，提高查询效率。
“消息队列”用于异步处理非实时业务，比如用户注册后发送欢迎邮件，注册服务把任务交给队列，邮件服务再处理，解耦服务依赖，提升系统吞吐量。
3) 【对比与适用场景】
| 组件 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 缓存（Redis vs Memcached） | Redis：内存键值存储，支持数据结构；Memcached：简单内存缓存 | Redis：高性能、持久化、事务；Memcached：高性能、无持久化 | Redis：热点数据缓存、会话管理；Memcached：简单缓存 | Redis需管理内存，Memcached适合非持久化场景 |
| 数据库（关系型 vs NoSQL） | 关系型（MySQL）：ACID事务，结构化数据；NoSQL（MongoDB）：非关系型，灵活数据模型 | 关系型：强一致性、事务支持；NoSQL：高扩展性、弱一致性 | 关系型：用户信息、课程表；NoSQL：用户行为日志、课程评论 | 关系型扩展性有限，NoSQL事务支持弱 |
| 消息队列（Kafka vs RabbitMQ） | Kafka：分布式流处理平台，高吞吐、持久化；RabbitMQ：企业级消息队列，可靠、灵活 | Kafka：高吞吐、持久化、多消费者；RabbitMQ：可靠、事务支持 | Kafka：实时数据流、日志收集；RabbitMQ：异步任务、解耦服务 | Kafka需数据清理策略，RabbitMQ需消息确认 |
4) 【示例】
用户访问课程列表流程（伪代码）：
- 前端请求
GET /courses→ Nginx负载均衡分发到后端服务。 - 后端检查Redis（key="courses_list"）：命中则返回缓存数据；未命中则查询MySQL，存入Redis（过期30分钟）后返回。
消息队列示例（Kafka）：用户注册后，注册服务发送“user_id=1001”到主题“user_register”，邮件服务消费该消息调用邮件API发送邮件。
5) 【面试口播版答案】
面试官您好，针对千万级用户并发访问的LMS设计，核心思路是采用微服务架构+分布式技术，通过负载均衡、多级缓存、数据库分片/读写分离、消息队列解耦，实现高可用与低延迟。具体来说，前端通过CDN加速静态资源，后端服务通过Nginx负载均衡分发请求，缓存层采用CDN+Redis+数据库三级缓存，减少数据库压力；数据库采用读写分离+分片，主库处理写操作，从库处理读操作，分片分散数据；消息队列使用Kafka处理异步任务，如发送通知、生成报表，解耦服务依赖。这样能支撑千万级用户并发访问，保证高可用和低延迟。
6) 【追问清单】
- 如何处理缓存雪崩？回答要点：缓存过期时间随机化，避免大量数据同时失效。
- 数据库分片后，如何保证查询效率？回答要点：使用分片路由（如主键哈希分片），结合全局ID生成器。
- 消息队列的可靠性如何保障？回答要点：消息持久化、事务确认、重试机制。
7) 【常见坑/雷区】
- 缓存穿透：空对象缓存，避免查询空数据导致数据库压力。
- 缓存击穿：热点数据设置默认值，避免热点数据失效时所有请求都查询数据库。
- 缓存雪崩：缓存过期时间随机化，避免大量数据同时失效。
- 数据库分片后的查询：需全局ID生成器，避免跨分片查询。
- 消息队列消费者幂等性：确保消息处理不重复（如使用唯一标识）。