在线竞赛或直播课的高并发场景下，如何设计系统架构以保证稳定性？请从负载均衡、容灾、监控等方面阐述。
学而思竞赛教练难度：中等
答案
1) 【一句话结论】
高并发场景下系统稳定性需通过分层负载均衡（L4+L7结合，满足低延迟与业务路由需求）、多级容灾（主备+多活结合，保障数据一致性及服务可用性）、全链路监控（实时采集关键指标并告警）构建弹性架构，核心是“请求智能分流+服务冗余+实时感知”。
2) 【原理/概念讲解】
- 负载均衡：分布式系统中将请求分发到多个后端服务器的技术，目的是提高吞吐量与可用性。类比：餐厅传菜员，将顾客点餐请求分发给不同后厨。
- 四层（L4，基于IP+端口）：速度快（无应用层处理开销），适合低延迟场景（如音视频直播）；
- 七层（L7，基于HTTP/HTTPS）：识别应用层信息（如URL、Cookie），支持智能路由（如会话保持、业务逻辑分发），适合需要业务逻辑分发的场景（如直播课用户会话保持）。
- 容灾：系统故障时保持可用性的能力，核心指标为恢复时间目标（RTO，故障后恢复服务时间）与恢复点目标（RPO，故障时数据丢失量）。
- 主备容灾（Active-Standby）：主节点服务，备节点热备，故障切换快（RTO低）但数据滞后（RPO高），适合非实时业务（如用户登录）；
- 多活容灾（Active-Active）：多节点同时服务，故障自动切换（RTO低），数据实时同步（RPO低），适合实时业务（如直播课判题）。
- 监控：采集系统各层指标（如请求量、响应延迟、错误率、资源使用率），设置告警阈值（如延迟>200ms、错误率>5%），异常时触发告警，帮助快速定位问题。
3) 【对比与适用场景】
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| L4负载均衡（如硬件设备） | 基于IP+端口的四层负载均衡 | 速度快（无应用层处理），延迟低 | 对延迟敏感的实时请求（如直播流传输） | 无法识别应用层信息，无法智能路由 |
| L7负载均衡（如Nginx） | 基于HTTP/HTTPS的应用层负载均衡 | 识别应用层信息（URL、Cookie），支持智能路由（如会话保持、URL转发） | 需要业务逻辑分发的场景（如不同功能模块分离服务） | 处理开销比L4大，延迟略高 |
| 主备容灾（Active-Standby） | 主节点提供服务，备节点热备 | RTO低（故障切换快），RPO高（备节点数据滞后） | 数据一致性要求不高的业务（如非实时统计） | 需持续同步数据，成本较低 |
| 多活容灾（Active-Active） | 多节点同时服务 | RTO低（故障自动切换），RPO低（数据实时同步） | 数据一致性要求高的业务（如实时判题、直播课） | 需分布式事务或数据同步，成本较高 |
4) 【示例】
假设在线竞赛直播课系统架构：
- 前端请求先通过L4硬件负载均衡器分发到多个Nginx（L7）节点，Nginx的
upstream配置（加权轮询）：
根据权重（1:1:1）分发请求。upstream live_service { server 10.1.1.1:80 weight=1; server 10.1.1.2:80 weight=1; server 10.1.1.3:80 weight=1; } - Nginx根据URL路径（如
/live/stream转发到直播流服务，/contest/judge转发到判题服务）智能路由到后端服务实例。 - 后端服务（如直播流服务）采用多活容灾，多节点部署，数据库读写分离（主库写，从库读）+ Redis集群缓存热门题目（设置随机过期时间防雪崩）。
- 监控系统（Prometheus+Grafana）采集Nginx的QPS、延迟；后端服务的错误率、资源使用率；数据库的连接数。当并发达到10000QPS时，Nginx自动扩容；延迟超过200ms时触发告警，运维人员通过K8s HPA自动扩容后端服务。
5) 【面试口播版答案】
“面试官您好，针对在线竞赛或直播课的高并发场景，保证系统稳定性的核心是构建‘分层负载均衡+多级容灾+全链路监控’的弹性架构。首先，负载均衡采用L4+L7分层方案：前端请求先通过L4硬件负载均衡器快速分发到多个Nginx节点，Nginx再根据URL路径智能路由到对应服务（如判题、直播流），避免单点过载。然后，容灾设计采用主备+多活结合：核心服务（如判题、直播流）用多活容灾，多节点同时处理请求，故障自动切换，保障RTO低；非核心服务（如用户登录）用主备容灾，主节点故障时快速切换，降低成本。最后，全链路监控用Prometheus+Grafana采集QPS、延迟、错误率等指标，设置告警阈值（如延迟>200ms），异常时自动告警，帮助快速响应。这样，高并发下系统能弹性扩容、故障快速恢复，保证稳定性。”
6) 【追问清单】
- 问题1：负载均衡选择L4还是L7的依据？
回答要点：直播课等低延迟场景用L4，需要业务逻辑分发的用L7。 - 问题2：多活容灾如何保证数据一致性？
回答要点：通过分布式事务（如Seata两阶段提交）或数据同步（如数据库binlog复制、Redis集群同步）。 - 问题3：高并发下缓存如何设计？
回答要点：用Redis集群缓存热点数据（如热门题目），设置随机过期时间防雪崩，结合本地缓存（如Guava Cache）减少网络开销。
7) 【常见坑/雷区】
- 只讲一种负载均衡方案，未对比L4/L7差异，或未结合业务需求（如直播课必须用L4却用L7）；
- 容灾方案只提主备，未提多活，或未说明RTO/RPO适用场景（如多活适合实时业务却用主备）；
- 监控只提指标，未提告警机制或阈值，或未说明快速响应流程（如异常时如何自动扩容）；
- 忽略业务特性（如直播课的实时性要求，需要低延迟的L4负载均衡），或未处理热点数据（如热门竞赛的请求集中导致缓存雪崩）；
- 未考虑成本（如多活容灾成本高，适合核心业务却用于非核心业务）。