设计一个支持百万级学生同时在线的直播课系统，需要考虑哪些关键技术点（如实时音视频传输、低延迟、容错）？请简述系统架构。

1) 【一句话结论】百万级并发直播课系统需采用分布式微服务架构，核心通过WebRTC/RTMP等实时传输协议、CDN内容分发、负载均衡分发请求，结合多级缓存与N+1冗余容错，确保低延迟、高可用。

2) 【原理/概念讲解】老师口吻，解释关键技术：
实时音视频传输需解决“如何高效、低延迟传输”问题。

• WebRTC：端到端技术，浏览器原生支持，减少服务器中转，适合小范围互动（如1对多直播、学生与老师实时互动），但需信令服务器（STUN/TURN）协调连接。
• RTMP：中心化流媒体协议，由服务器推流到客户端，延迟低（通常<100ms），适合大规模直播（百万级用户），需专用流媒体服务器（如Nginx-RTMP）。
• CDN：分布式节点缓存视频/音频流，用户就近访问，降低网络延迟（如用户从离自己最近的CDN节点拉流，延迟<50ms）。
• 负载均衡：如Nginx/LVS，将用户请求分发到多台应用服务器，避免单点过载。
• 容错机制：主备服务器+心跳检测，故障时自动切换（如主服务器故障，备用服务器接管，用户无感知）。

3) 【对比与适用场景】

技术方案	定义	特性	使用场景	注意点
WebRTC	基于Web的实时通信技术，支持音视频、数据传输	端到端，低延迟，浏览器原生支持	小范围互动（如1对多直播，学生与老师实时互动），点对点或小规模群聊	需信令服务器协调连接，部署成本较高，对网络稳定性要求高
RTMP	流媒体传输协议，由服务器推流到客户端	中心化，延迟低（通常<100ms），适合大规模直播	大规模直播课（百万级用户），需要稳定的服务器推流能力	需要专用流媒体服务器（如Nginx-RTMP），对服务器带宽要求高，网络抖动时可能影响体验

4) 【示例】
系统架构伪代码示例：

用户请求 → 负载均衡器（Nginx） → 应用服务器集群（多台）  
应用服务器处理请求 → 流媒体服务器（Nginx-RTMP）推流 → CDN节点  
用户客户端（浏览器/APP） → 从CDN拉取流（HTTP/HTTPS）  

5) 【面试口播版答案】（约90秒）
“面试官您好，百万级并发直播课系统需解决高并发、低延迟、高可用问题。核心架构分为四层：接入层（负载均衡分发请求）、应用层（处理业务逻辑，如用户鉴权、课程调度）、流媒体层（通过Nginx-RTMP推流，支持百万级并发）、CDN层（缓存视频流，用户就近访问）。关键技术点包括：实时传输协议（WebRTC用于互动，RTMP用于大规模直播，两者结合覆盖不同场景），内容分发网络（CDN降低延迟，比如用户从离自己最近的节点拉流，延迟<50ms），负载均衡（Nginx或LVS分发请求到多台应用服务器，避免单点过载），容错机制（主备服务器，心跳检测，自动切换，比如主服务器故障时，备用服务器接管，用户无感知）。总结来说，通过分布式架构和多层技术手段，确保系统在高并发下仍能保持低延迟和高可用。”

6) 【追问清单】

• 问：WebRTC的部署成本和适用场景？
  答：WebRTC需要信令服务器（如STUN/TURN服务器）协调连接，部署成本较高，适合小范围互动或需要端到端加密的场景，大规模直播时可能需要结合RTMP。
• 问：CDN的选型标准？
  答：考虑节点覆盖范围（覆盖全国/全球）、缓存能力、带宽、价格，比如阿里云CDN、腾讯云CDN，根据用户分布选择。
• 问：如何处理网络抖动导致的卡顿？
  答：采用自适应码率（ABR），根据网络状况动态调整视频码率；结合RTCP（实时传输控制协议）监控网络质量，实时调整传输参数。
• 问：系统扩展性如何？
  答：采用微服务架构，各层可独立扩展，比如应用层增加服务器实例，流媒体层增加RTMP服务器节点，CDN节点可动态增加，支持水平扩展。

7) 【常见坑/雷区】

• 坑1：只说WebRTC而忽略中心化流媒体传输，导致大规模直播时服务器压力过大。
• 坑2：忽略CDN的作用，认为直接从服务器拉流，导致延迟过高，影响用户体验。
• 坑3：容错机制描述不具体，比如只说“冗余”，没有说明如何检测故障和切换，显得不专业。
• 坑4：未考虑网络抖动和丢包的处理，比如没有自适应码率或前向纠错（FEC），导致视频卡顿。
• 坑5：架构分层不清晰，比如将所有功能放在一层，没有区分接入、应用、流媒体、CDN，显得架构设计不合理。