假设学习通平台在开学季面临百万级用户同时注册和登录的高并发场景，请设计一个系统架构方案，从负载均衡、缓存、数据库、消息队列等角度说明如何应对该场景。

1) 【一句话结论】
针对学习通开学季百万级并发注册登录场景，设计分层高可用架构，通过负载均衡分散请求、多级缓存降低数据库压力、数据库读写分离+分库分表提升读写能力、消息队列解耦服务，确保系统稳定与性能。

2) 【原理/概念讲解】
老师会讲解各核心组件：

• 负载均衡：像交通枢纽，将用户请求分发到多台应用服务器。常用Nginx（七层，支持HTTP/HTTPS，配置灵活）、LVS（四层，IP哈希，速度快）。算法选择依据场景：轮询（公平分发）、IP哈希（保证会话粘性，如用户登录态）、加权轮询（服务器性能不均时调整权重）。需结合心跳检测（定期ping服务器）剔除故障节点，避免请求流向异常服务器。
• 缓存：超市货架，存储热点数据（如用户登录态、热门课程信息）。以Redis为例，需解决三类问题：
  • 雪崩：缓存大量数据集中过期，用随机过期时间分散过期时间；
  • 击穿：热点数据被大量请求击穿缓存，用Redis互斥锁（SETNX）保证单线程写入；
  • 穿透：无效查询绕过缓存，用布隆过滤器预过滤无效查询。
    采用三级缓存（本地缓存+分布式缓存+数据库），提升响应速度。
• 数据库：读写分离+分库分表。读写分离（主库写，从库读）减轻主库压力；分库分表（用户ID哈希分库，课程ID哈希分表）解决单库容量和性能瓶颈，同时通过冷热数据分离（如用户基础信息冷数据、热门课程热数据）避免热点数据集中。
• 消息队列：快递中转站，解耦服务间依赖（如注册成功后通知用户中心、发送短信）。以Kafka为例，通过日志持久化（写入磁盘）确保消息不丢失，事务消息（Exactly-Once语义）保证消息发送和存储原子性，死信队列处理失败消息。

3) 【对比与适用场景】
以负载均衡算法为例：
| 算法 | 定义 | 特性 | 使用场景 | 注意点 |
| 轮询 | 按顺序分发请求 | 公平，请求均匀 | 通用场景，无特殊需求 | 可能导致后上线服务器压力小 |
| IP哈希 | 根据客户端IP哈希 | 会话粘性，同一IP请求到同一服务器 | 需要会话保持的场景（如用户登录态） | 避免IP变化导致会话丢失 |
| 加权轮询 | 根据权重分发 | 优先分配权重高的服务器 | 服务器性能不均时 | 需要动态调整权重 |

4) 【示例】
注册流程伪代码：

1. 用户请求注册（POST /register）→ 负载均衡分发到应用服务器。
2. 应用服务器检查Redis缓存（key: user:login:token:uid），若存在则返回“已注册”。
3. 若缓存不存在，查询MySQL从库（select * from users where phone=...），若存在则返回“手机号已存在”。
4. 若数据库无记录，写入MySQL主库（insert into users...），提交事务。
5. 写入成功后，更新Redis缓存（set user:login:token:uid, value:token, ex:3600）。
6. 通过Kafka发送消息（topic: user.register.success, payload: {user_id, phone}）。
7. 应用服务器返回“注册成功”。

5) 【面试口播版答案】
“面试官您好，针对学习通开学季百万级并发注册登录场景，我设计的系统架构核心是分层高可用，具体从负载均衡、缓存、数据库、消息队列四个维度优化：
首先，负载均衡用Nginx七层调度，轮询分发请求到多台应用服务器，结合健康检查剔除故障节点，保证请求均匀分配；
其次，缓存层用Redis，存储用户登录态和热门课程信息，减少数据库压力，比如用户登录时先查缓存，命中则直接返回，未命中再查数据库；
然后，数据库采用读写分离+分库分表，主库写数据，从库读数据，比如按用户ID的哈希值分库，按课程ID的哈希值分表，解决单库容量和性能瓶颈；
最后，消息队列用Kafka，解耦注册成功后的业务流程，比如通知用户中心、发送欢迎短信，避免服务间直接调用导致链路过长，确保高并发下消息不丢失。
这样整体架构能应对百万级并发，保证系统稳定性和性能。”（约80秒）

6) 【追问清单】

• 问：数据库分库分表的具体策略？比如如何确定分片规则？
  回答要点：按用户ID的哈希值分库，按课程ID的哈希值分表，结合业务场景调整（如用户数据按ID范围分库，课程数据按分类分表），避免热点数据集中。
• 问：缓存雪崩/击穿/穿透的解决方案？
  回答要点：雪崩用随机过期时间；击穿用Redis互斥锁（SETNX）；穿透用布隆过滤器预过滤。
• 问：消息队列的持久化机制？如何保证消息不丢失？
  回答要点：Kafka的日志持久化（写入磁盘），事务消息（确保消息发送和存储原子性），死信队列处理失败消息。
• 问：负载均衡的算法选择？比如轮询和IP哈希的优缺点？
  回答要点：轮询公平，IP哈希保证会话粘性，开学季用户可能需要会话粘性，所以用IP哈希。
• 问：系统容灾方案？比如主从切换？
  回答要点：数据库主从切换（如MySQL的GTID），负载均衡器主备切换（Nginx的upstream模块配置主备），应用服务器集群故障转移。

7) 【常见坑/雷区】

• 坑1：未提及缓存雪崩/击穿/穿透的应对，面试官会追问解决方案，若没准备会被扣分。
• 坑2：数据库只说读写分离没提分库分表，开学季数据量激增，单库可能达到瓶颈，没分库分表会导致性能下降。
• 坑3：消息队列没提持久化和死信队列，高并发下消息可能丢失，影响业务（如用户注册后没收到通知）。
• 坑4：负载均衡没提健康检查，故障服务器未被剔除，会导致请求分发到故障节点，影响用户体验。
• 坑5：架构设计过于复杂，比如引入过多组件，没考虑成本和运维复杂度，面试官会问成本和可行性。