设计一个支持好未来在线平台高并发直播课的系统，需考虑实时互动、回放、数据一致性，请说明系统架构、关键技术选型及容灾方案。
答案
1) 【一句话结论】采用微服务架构+流媒体技术栈，结合消息队列解耦、分布式存储与缓存，通过多级缓存、CDN加速及多活部署实现高并发、实时互动、回放与数据一致性。
2) 【原理/概念讲解】
老师口吻：首先，实时互动是直播的核心，我们用WebRTC技术，它基于P2P传输音视频，但需要信令服务器（如基于WebSocket的信令服务）来交换连接信息——就像打电话要先拨号（信令）建立连接，然后直接通话（WebRTC传输）。为了应对高并发，信令服务器部署多实例，通过负载均衡（如Nginx）分发请求，同时前端使用WebRTC的ICE（Interactive Connectivity Establishment）协议自动选择最佳网络路径，减少延迟。
其次，回放功能需要录制直播流并存储。我们采用录制服务（录制微服务）捕获原始流（如RTMP或WebRTC流），通过FFmpeg实时录制并存储到分布式存储（如MinIO），同时启动转码服务（转码微服务）将流转码为HLS（HTTP Live Streaming）和MP4格式，存储到对象存储，供用户点播。转码任务使用消息队列（如Kafka）异步处理，避免影响录制性能，同时通过任务队列（如Redis队列）保证转码顺序。
数据一致性方面，我们采用最终一致性方案：用户加入直播时，通过消息队列异步更新用户状态（如观看状态、观看时长），确保高并发下不丢失数据；录制开始时，先发送消息到消息队列，由录制服务处理，再更新数据库状态，通过分布式锁保证关键操作（如录制开始）的原子性，避免并发冲突。
最后，容灾方案采用多活部署：核心服务（如信令、录制、转码）部署在多个可用区（如阿里云的可用区A和B），通过DNS轮询或负载均衡实现跨可用区访问，同时存储层（分布式存储）采用多副本存储，确保数据不丢失。
3) 【对比与适用场景】
| 流媒体传输协议 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| RTMP | Real-Time Messaging Protocol | 依赖Flash，延迟低，适合单点传输 | 传统直播平台（如早期视频网站） | 需要Flash插件，兼容性差 |
| WebRTC | Web Real-Time Communication | P2P传输，低延迟，无需插件 | 在线教育、实时会议 | 需信令服务器，网络复杂时可能切换到中继 |
| SRT | SRT (Secure Reliable Transport) | 基于RTP/RTSP，支持加密、拥塞控制 | 高延迟、低带宽环境（如跨地域直播） | 需要专用编解码器 |
4) 【示例】
用户加入直播课流程伪代码：
// 用户加入直播课流程
1. 用户请求加入直播课（URL: /join?courseId=123）
2. 前端通过WebSocket连接信令服务器（signaling-server.com）
3. 信令服务器返回SDP（Session Description Protocol）信息
4. 前端根据SDP信息建立WebRTC连接（peer connection）
5. 后端记录用户状态（状态：watching，课程ID：123）
6. 如果是首次加入，触发录制任务（通过消息队列发送录制指令）
5) 【面试口播版答案】
“面试官您好，针对好未来高并发直播课系统设计，我的核心思路是构建一个以流媒体技术为核心、微服务解耦的架构，通过分层设计实现高并发、实时互动、回放与数据一致性。具体来说：
首先，实时互动模块采用WebRTC技术，配合信令服务器（如基于WebSocket的信令服务）实现低延迟音视频传输，信令服务器负责用户连接建立与SDP交换，类似打电话先拨号（信令）再通话（WebRTC传输）。为了应对高并发，信令服务器部署多实例，通过负载均衡（如Nginx）分发请求，同时前端使用WebRTC的ICE协议自动选择最佳网络路径，减少延迟。
其次，回放功能需要录制直播流并存储。我们采用录制服务捕获原始流，通过FFmpeg实时录制并存储到分布式存储（如MinIO），同时启动转码服务将流转码为HLS和MP4格式，存储到对象存储，供用户点播。转码任务使用消息队列异步处理，避免影响录制性能，同时通过任务队列保证转码顺序。
然后，数据一致性方面，我们采用最终一致性方案：用户加入直播时，通过消息队列异步更新用户状态，确保高并发下不丢失数据；录制开始时，先发送消息到消息队列，由录制服务处理，再更新数据库状态，通过分布式锁保证关键操作的原子性，避免并发冲突。
最后，容灾方案方面，我们采用多活部署：核心服务部署在多个可用区，通过DNS轮询或负载均衡实现跨可用区访问，同时存储层采用多副本存储，确保数据不丢失。另外，监控告警系统实时监控服务状态，当某个服务故障时，自动切换到备用实例，保证系统可用性。”
6) 【追问清单】
-
“如何保证实时互动的低延迟？”
回答要点：通过WebRTC的ICE协议自动选择最佳网络路径，信令服务器部署多实例并负载均衡，前端使用WebRTC的STUN/TURN服务器处理NAT穿越，减少延迟。 -
“回放功能如何处理大文件存储与访问？”
回答要点：使用分布式对象存储（如MinIO）存储原始录制流和转码后的多格式文件，通过CDN加速用户访问，转码为分片文件（如HLS的分片），提高访问速度。 -
“数据一致性如何处理？”
回答要点：采用最终一致性方案，通过消息队列异步处理用户状态更新和录制指令，使用分布式锁保证关键操作的原子性（如录制开始），同时定期同步数据到主数据库。
7) 【常见坑/雷区】
- 忽略实时互动的延迟问题，只关注传输，而忽略信令服务器和WebRTC的配置（如STUN/TURN服务器）。
- 回放功能只考虑存储，而忽略转码和CDN加速，导致用户访问慢。
- 数据一致性只考虑数据库事务，而忽略异步处理的顺序，导致数据不一致（如录制未完成就显示已录制）。
- 容灾方案只考虑服务多活，而忽略数据多副本，导致数据丢失。
- 架构设计过于复杂，没有分层，导致维护困难（如把所有功能放在一个服务里，而不是微服务拆分）。