设计一个支持百万级用户同时观看直播的视频流处理系统，需要考虑哪些核心组件？如何保证低延迟和高可用？
淘天集团视频编解码难度：困难
答案
1) 【一句话结论】
构建百万级直播系统需分层架构（内容分发、传输、播放），核心组件包括CDN、负载均衡、多级缓存、低延迟流媒体协议（如RTMP），通过CDN加速、协议优化（低延迟RTMP）、多节点容灾（自动切换、数据同步），实现低延迟（≤1秒）和高可用（99.99%以上）。
2) 【原理/概念讲解】
老师口吻解释各组件作用：
- CDN（内容分发网络）：分布式节点（边缘、区域、核心），边缘节点离用户近，减少传输延迟。类比“快递网点”，离用户近则取件/配送快，避免核心节点压力。
- 负载均衡（如Nginx）：将用户请求分发到多个后端节点，采用轮询/加权轮询，根据节点负载和权重分配请求，避免单点过载。
- 多级缓存：边缘（热点视频流，TTL=60秒）、区域（次热点，TTL=3600秒）、核心（冷启动，TTL=长期）三级缓存。机制：用户请求先查边缘，无则查区域，再查核心，核心拉取后逐级推送。
- 低延迟协议（RTMP）：实时流传输协议，专用于直播推流，延迟≤1秒；HTTP-FLV（秒级延迟，兼容性好）、HLS（1-3秒延迟，分段传输）用于拉流。
- 实时监控与告警：监控节点延迟、流量、错误率，延迟过高时自动调整负载，故障节点自动切换。
3) 【对比与适用场景】
| 组件/方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| CDN | 分布式节点网络，加速内容传输 | 边缘节点离用户近，减少延迟，负载均衡 | 百万级用户直播，降低核心服务器压力 | 需CDN服务商，成本较高 |
| 自建边缘节点 | 公司自建或合作边缘节点 | 可定制，控制权高 | 大型直播平台，需定制化功能 | 需投入硬件/运维，成本高 |
| 负载均衡（Nginx） | 将请求分发到多个后端节点 | 轮询/加权轮询/最少连接 | 高并发请求（如直播推流/拉流） | 需配置权重，避免单点故障 |
| 多级缓存 | 边缘-区域-核心三级缓存 | 边缘缓存热点，区域缓存次热点，核心缓存冷启动 | 降低核心服务器压力，提高响应速度 | 需缓存失效策略（如TTL），避免数据不一致 |
| 低延迟协议（RTMP） | 实时流传输协议，低延迟（≤1秒） | 专用于直播推流，实时性高 | 直播推流，需低延迟 | 兼容性稍差，需客户端支持 |
4) 【示例】
伪代码示例（用户请求视频流）：
用户请求：/live/123/stream
1. 负载均衡（Nginx）分发到边缘节点（edge1/edge2）。
2. 边缘节点检查边缘缓存：
- 有则直接返回流（HTTP-FLV/RTMP）。
- 无则查询区域节点：
a. 区域节点检查缓存：
- 有则返回流，并更新边缘节点缓存（TTL=60秒）。
- 无则查询核心节点：
i. 核心节点拉取视频流（源服务器）。
ii. 推送到区域节点（缓存，TTL=3600秒）。
iii. 区域节点推送到边缘节点（缓存，TTL=60秒）。
3. 用户播放端接收流，实时播放。
5) 【面试口播版答案】
“面试官您好，设计百万级直播系统，核心是构建分层架构，通过CDN加速、负载均衡、多级缓存和低延迟协议，实现低延迟和高可用。首先，核心组件包括CDN（边缘节点）、负载均衡（如Nginx轮询）、多级缓存（边缘-区域-核心），以及流媒体协议（RTMP低延迟）。低延迟方面，采用RTMP实时推流，减少中间处理；高可用通过多节点容灾，比如边缘节点故障时自动切换到其他节点，核心节点数据同步，确保数据一致性。具体来说，用户请求先到边缘节点，边缘节点缓存热门流，若没有则从区域节点拉取，区域节点再从核心节点拉取，核心节点负责冷启动视频流的拉取和缓存。通过CDN加速，用户延迟控制在1秒内；负载均衡确保每个节点负载均衡，避免单点过载；多级缓存降低核心服务器压力，提高响应速度。监控方面，实时监控各节点延迟和流量，当延迟过高时自动调整负载，保证系统稳定。总结来说，通过这些组件和策略，系统可支持百万级用户同时观看，低延迟（≤1秒），高可用（99.99%以上）。”
6) 【追问清单】
- 问：CDN选择时，如何平衡成本和性能？
答：根据用户分布选择区域，热门区域用更多边缘节点，冷门区域减少，动态调整。 - 问：低延迟具体如何实现？比如RTMP和HTTP-FLV的延迟差异？
答：RTMP是实时推流，延迟约0.5-1秒；HTTP-FLV是秒级延迟，适合回放；直播推流用RTMP，拉流用HTTP-FLV。 - 问：高可用设计，比如节点故障时的切换机制？
答：通过健康检查（如心跳），故障节点自动下线，用户请求自动切换到其他节点，数据同步通过缓存和日志保证一致性。 - 问：如何处理网络抖动导致的延迟？
答：采用自适应码率（ABR），根据网络状况调整码率，保证播放流畅。 - 问：协议选择，比如HLS是否适合直播？
答：HLS延迟1-3秒，适合回放或延迟要求不高的场景，直播用RTMP或低延迟HLS（如DASH的低延迟模式）。
7) 【常见坑/雷区】
- 忽略CDN的作用，直接用核心服务器处理，导致延迟过高，压力过大。
- 缓存策略错误，比如冷启动视频流没有从核心拉取，导致用户等待时间长。
- 协议选择不当，比如用HLS做直播推流，导致延迟过高，不符合直播需求。
- 高可用设计不足，比如没有健康检查，节点故障时无法自动切换，导致服务中断。
- 忽略网络抖动，没有自适应码率，导致播放卡顿。