设计一个支持在线直播课程的系统，要求支持百人以上实时互动、低延迟、高可用。请说明网络架构、服务器部署、负载均衡策略，以及如何保障课程录制和回放的稳定性。
中国人民公安大学教师岗难度：困难
答案
1) 【一句话结论】：采用CDN边缘节点+流媒体服务器集群+负载均衡的混合架构，结合WebRTC实时互动与RTMP推拉流，通过分布式存储和CDN加速回放，确保百人以上直播的低延迟、高可用及录制回放稳定性。
2) 【原理/概念讲解】：
老师口吻解释关键概念：
- CDN（内容分发网络）：像“快递中转站”，边缘节点部署在用户附近，减少数据传输距离，降低延迟（类比：用户从本地快递点取货比从总部取货快）。
- 边缘计算：在边缘节点处理实时互动（如弹幕、问答），减少数据回传延迟（类比：小区门口的快递柜，用户取件不用等快递员送上门）。
- 流媒体服务器（如Nginx-RTMP）：负责直播的推流（主播端）和拉流（用户端），支持RTMP协议（类比：电视信号发射站，接收主播信号并广播给用户）。
- 负载均衡：像“交通指挥中心”，分发请求到多个服务器，避免单点过载（类比：高峰期路口的交警，分流车辆避免拥堵）。
- WebRTC：浏览器原生支持，实现点对点或服务器中转的实时音视频通信，延迟低（通常<50ms），适合实时互动（类比：手机视频通话，直接连接对方，无需中转）。
3) 【对比与适用场景】：
以流媒体协议（RTMP vs WebRTC）为例：
| 协议 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| RTMP | Real-Time Messaging Protocol，Adobe开发，专用于流媒体传输 | 依赖服务器中转，延迟较高（100-200ms），支持大规模推流 | 传统直播平台（如YouTube直播） | 需要专用服务器，兼容性好 |
| WebRTC | Web Real-Time Communication，浏览器原生API | 支持点对点（P2P）或服务器中转（STUN/TURN），延迟低（<50ms），适合实时互动 | 在线教育、视频会议 | 需要信令服务器，网络环境复杂时可能依赖中转 |
4) 【示例】：
伪代码示例（用户连接流程）：
- 用户请求连接：
GET /api/connect?courseId=123 - 负载均衡器（Nginx）将请求转发到边缘节点（北京、上海、广州的CDN节点）
- 边缘节点处理WebRTC信令：建立连接，用户端发送ICE候选，服务器返回STUN/TURN服务器地址
- 主播端推流：
RTMP://edge-node/stream?courseId=123，流媒体服务器接收RTMP流 - 用户端拉流：通过WebRTC或HLS从边缘节点获取流，播放直播
5) 【面试口播版答案】：
各位面试官好，针对百人以上直播课程系统，我设计的核心方案是构建CDN边缘节点+流媒体服务器集群的混合架构。首先，网络层面，采用全球CDN节点部署边缘服务器，靠近用户，通过WebRTC实现低延迟实时互动（如弹幕、问答），同时支持RTMP推流。服务器部署上，流媒体服务器（如Nginx-RTMP）集群部署在核心机房，通过负载均衡（LVS+Nginx双级）分发请求，确保高可用。负载均衡策略中，前端LVS做七层负载，后端Nginx做四层，结合会话保持，避免用户请求被拆分。录制回放方面，采用分布式存储（如Ceph）+CDN缓存，录制时流媒体服务器将直播流推送到存储，回放时通过CDN分发，保证回放速度和稳定性。整体架构通过边缘计算减少回传延迟，通过集群和负载均衡避免单点故障，满足百人以上直播的低延迟、高可用需求。
6) 【追问清单】：
- 问题1：如何处理大规模用户同时加入时的带宽压力？
回答要点：通过CDN边缘节点分流，结合流媒体服务器的带宽限流，以及WebRTC的P2P中转减少服务器压力。 - 问题2：低延迟具体如何保障？
回答要点：WebRTC的P2P连接（延迟<50ms），边缘节点处理实时互动，减少数据传输距离。 - 问题3：高可用具体方案，比如主备切换？
回答要点：流媒体服务器集群（主备），负载均衡器检测服务器状态，故障时自动切换到备用节点。 - 问题4：实时互动功能（如弹幕、问答）的实现？
回答要点：边缘节点处理互动数据，通过WebSocket或HTTP长连接同步到用户端，确保实时性。 - 问题5：不同网络环境（如4G、Wi-Fi）的适配？
回答要点：支持HLS（HTTP Live Streaming）自适应码率，根据用户网络环境调整流媒体质量。
7) 【常见坑/雷区】：
- 坑1：忽略网络延迟，只谈服务器性能。
雷区：认为服务器性能足够就能解决低延迟，实际网络延迟是关键。 - 坑2：负载均衡方案单一，未考虑多级。
雷区：只用Nginx做负载均衡，未结合LVS，导致大规模流量时性能瓶颈。 - 坑3：录制回放存储方案简单，未考虑数据安全或检索。
雷区：直接用本地存储，未考虑分布式存储的容灾和检索效率。 - 坑4：未考虑实时互动的同步问题。
雷区：弹幕或问答数据不同步，导致用户体验差。 - 坑5：忽略CDN的缓存策略，导致回放延迟。
雷区：回放时直接从源服务器获取，未用CDN缓存，导致延迟高。