好未来在线平台的直播课系统在开学季会出现高并发请求，导致部分用户无法正常进入课堂。作为SRE，你会如何设计系统架构以应对这种高并发场景？请说明关键组件的设计思路，如负载均衡、缓存、数据库分片等。

好未来SRE难度：中等

答案

1) 【一句话结论】针对开学季高并发场景，设计分层弹性架构，通过负载均衡分散请求、Redis缓存降低数据库压力、数据库分片水平扩展，结合限流、异步处理与监控告警，确保用户稳定进入直播课系统。

2) 【原理/概念讲解】

负载均衡：核心是请求分发，将用户请求分发到多台后端服务器，避免单点过载。类比交通枢纽，把大量车流分到不同车道，提高整体通行效率。常见方案如Nginx（七层负载均衡器，支持HTTP/HTTPS，配置灵活，适合Web/直播课前端，需配置健康检查避免故障节点）、LVS（四层负载均衡器，基于Linux内核，高性能集群，适合大流量低延迟场景，需内核支持）、HAProxy（七层负载均衡器，高性能，支持会话保持，适合需会话复制的场景）。
缓存（Redis）：用于存储高频访问数据（如用户信息、课程信息），减少数据库查询压力。类比超市货架，用户先从货架拿商品（缓存），不用去仓库（数据库），提升响应速度。需设置TTL（如60秒+随机偏移1-5秒）避免雪崩，用布隆过滤器防缓存穿透，热点数据提前预热。
数据库分片：将数据水平切分成多个分片，每个分片存储不同数据，实现水平扩展。类比把一个大仓库分成多个小仓库，每个小仓库负责不同类别的商品，常见分片策略如按用户ID模N分片（如UID%3），跨分片查询通过预聚合或分片键设计（如按课程ID分片）减少跨分片操作。

3) 【对比与适用场景】
负载均衡方案对比：

方案	定义	特性	使用场景	注意点
Nginx	七层负载均衡器	支持HTTP/HTTPS，配置灵活，支持健康检查	Web应用、直播课系统前端	需配置健康检查，避免故障节点
LVS	四层负载均衡器	高性能，基于Linux内核，支持集群	大流量、低延迟场景	配置复杂，需内核支持
HAProxy	七层负载均衡器	高性能，支持会话保持	需会话复制的场景	需维护会话状态

缓存与数据库对比：

特性	缓存（Redis）	数据库（MySQL）
读写速度	毫秒级	秒级
数据持久性	RDB/Memcached	本地磁盘
事务支持	支持（复杂）	强支持
适用场景	高频读、热点数据	写操作、复杂查询

4) 【示例】
请求流程：用户访问直播课系统，Nginx负载均衡器将请求分发到后端Server1。后端先查询Redis（key=“user:info:1001”），命中则返回；未命中则查询MySQL（分片1，UID%3=0），获取数据后存入Redis（TTL=60s+随机偏移3s），返回给用户。
数据库分片示例：用户表user按UID模3分片，分片1存储UID%3=0的用户，分片2存储UID%3=1的用户，分片3存储UID%3=2的用户。查询用户时，根据UID计算分片ID，再查询对应分片数据库。

5) 【面试口播版答案】
“面试官您好，针对开学季高并发，我会设计分层架构，核心是通过负载均衡分散请求、Redis缓存减少数据库压力、数据库分片水平扩展。具体来说，前端用Nginx做七层负载均衡，分发请求到多台后端服务器；后端通过Redis缓存用户信息、课程信息，减少数据库查询；数据库按用户ID模3分片，每个分片存储不同ID范围的用户数据。同时，设置令牌桶限流（QPS=100，令牌生成速率1/秒），异步处理日志写入，监控QPS、缓存命中率（>90%）、数据库延迟（<100ms），通过K8s自动扩容应对流量波动。这样能确保用户稳定进入直播课系统。”

6) 【追问清单】

问：如何设计限流策略？
回答要点：采用令牌桶算法，设置QPS=100，令牌生成速率1/秒，超过则拒绝请求。
问：缓存雪崩如何处理？
回答要点：设置TTL=60s+随机偏移1-5秒，避免大量缓存过期同时失效。
问：数据库分片后，跨分片查询如何处理？
回答要点：对于用户与课程的关联查询，按课程ID分片，减少跨分片操作。
问：如何保证缓存与数据库数据一致性？
回答要点：使用乐观锁（版本号），或通过消息队列异步同步数据。
问：系统如何监控和告警？
回答要点：监控QPS（>200告警）、缓存命中率（<90%告警）、数据库延迟（>100ms告警），触发扩容或告警。

7) 【常见坑/雷区】

忽略健康检查：负载均衡器未检测故障节点，导致流量分发到不可用服务器。
缓存未设置过期策略：导致缓存数据过期后，大量请求查询数据库，引发雪崩。
数据库分片导致数据不一致：跨分片操作未考虑一致性，如用户删除后，其他分片仍有数据。
忽略异步任务：实时任务（如日志写入）未异步处理，导致数据库压力过大。
监控指标不全面：未监控缓存命中率、数据库延迟等关键指标，无法及时发现性能问题。