请设计好未来APP的直播课功能系统架构，包括视频流传输（前端播放、后端推流）、互动消息（弹幕、问答）、学习进度同步（回放、记录），并说明如何保证视频播放的流畅性和数据一致性。
答案
1) 【一句话结论】采用分层架构（前端播放层、实时通信层、数据服务层、存储层），结合CDN加速、实时通信协议（如WebRTC、WebSocket）和分布式数据库，通过推拉流技术保障视频低延迟播放，互动消息实时同步，学习进度数据一致。
2) 【原理/概念讲解】视频流传输分为推流和拉流。推流是后端服务器主动将视频流通过RTMP协议发送至CDN节点（类似“服务器将视频数据打包发送到中转仓库”），CDN负责分发；拉流是前端客户端通过HTTP请求CDN提供的HLS M3U8索引文件和分段流文件（类似“用户主动从仓库取视频片段”），支持移动端缓存和断点续传。互动消息采用WebSocket长连接实现实时推送（如弹幕、问答），通过消息队列（如Kafka）分发确保高并发下的消息可靠性。学习进度同步依赖MySQL存储主数据，Redis缓存热点数据（如当前课程进度），通过数据库事务和缓存更新策略（如写时复制、缓存失效）保证多设备数据一致性。
3) 【对比与适用场景】
视频传输协议对比：
| 协议 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| RTMP | Real-Time Messaging Protocol | 低延迟（约100ms），适合直播推流 | 直播推流（后端推流到CDN） | 需专用服务器，移动端兼容性一般 |
| HLS | HTTP Live Streaming | 基于HTTP，支持移动端缓存、断点续传 | 移动端播放、回放 | 延迟稍高（1-2秒），适合稳定网络 |
| WebRTC | Web Real-Time Communication | 点对点，低延迟（<100ms），无需服务器 | 低延迟互动（如实时问答、画中画） | 需信令服务器，网络质量依赖 |
| 互动消息协议对比： | ||||
| 协议 | 定义 | 特性 | 使用场景 | 注意点 |
| ------ | ------ | ------ | ---------- | -------- |
| WebSocket | 双向实时通信 | 低延迟，需保持连接 | 弹幕（实时性要求高） | 需维护长连接，高并发下需消息队列优化 |
| MQTT | 发布订阅协议 | 消息持久化，支持离线重连 | 大规模弹幕（如万人同时发送） | 消息延迟较高，适合消息量大的场景 |
| 自适应码率（ABR）优化：根据网络带宽和延迟动态切换视频码率（如从1080P切换到720P），结合CDN边缘节点就近加载，减少网络抖动导致的卡顿。 |
4) 【示例】
推流端伪代码（Java，使用FFmpeg）：
public void startPushStream(String streamId, String rtmpUrl) {
ProcessBuilder pb = new ProcessBuilder("ffmpeg", "-re", "-i", "input.mp4", "-c:v", "h264", "-c:a", "aac", "-f", "flv", rtmpUrl);
pb.start();
}
// 拉流播放（前端请求HLS）
GET /api/v1/live/stream/123/playlist.m3u8 // 请求M3U8索引文件
GET /api/v1/live/stream/123/segment/123.ts // 请求分段视频文件
学习进度同步流程：
- 用户更新学习进度（如“完成第3章”），后端更新MySQL中的学习记录表。
- 通过消息队列（如RabbitMQ）发送“进度更新”事件。
- Redis订阅该事件，更新缓存中的用户进度数据（如
user_progress:{userId}:chapter=3）。
5) 【面试口播版答案】面试官好，我来设计好未来APP的直播课系统架构。核心是分层架构，分为前端播放层、实时通信层、数据服务层和存储层，结合CDN加速、实时通信协议和分布式数据库。视频流传输分推流和拉流：推流是后端服务器用RTMP协议将视频流推送到CDN节点（类似中转仓库），前端通过HLS请求CDN的M3U8和分段文件播放；互动消息用WebSocket长连接实时推送弹幕和问答，通过消息队列确保高并发下的消息可靠性；学习进度同步依赖MySQL存储主数据，Redis缓存热点数据，通过数据库事务和缓存更新策略保证多设备数据一致。比如推流时，服务器主动发送视频流到CDN，用户通过HLS请求播放，弹幕通过WebSocket实时更新，学习记录同步到数据库和缓存，这样能保证视频流畅（CDN加速、ABR自适应码率）和数据一致（分布式存储+缓存）。如果网络波动，系统会自动切换视频质量；学习进度更新时，数据库和缓存同步，避免多端不同步。
6) 【追问清单】
- 问：如何处理网络波动导致视频卡顿？答：采用自适应码率（ABR），根据网络带宽和延迟动态切换视频码率（如从1080P切换到720P），结合CDN边缘节点就近加载，减少卡顿。
- 问：数据一致性如何保证？答：学习进度更新时，先更新MySQL数据库，再通过消息队列通知Redis缓存更新（写时复制策略），高并发下用分布式锁保证并发安全。
- 问：回放功能如何实现？答：录制推流到OSS存储，用户请求回放时，从OSS拉取流并解析为HLS格式，支持倍速播放和离线缓存。
- 问：多端同步（PC和手机同时看）如何处理？答：统一存储学习进度，通过WebSocket推送状态变更，用版本号机制解决冲突（最后写入者胜出）。
- 问：互动消息实时性如何优化？答：消息队列批量处理弹幕消息，减少延迟，结合CDN边缘节点缓存弹幕消息，确保实时推送。
7) 【常见坑/雷区】
- 忽略自适应码率（ABR）优化，只说协议，导致视频卡顿问题被反问。
- 数据一致性只说数据库，没提缓存更新策略（如写时复制），导致多设备不同步。
- 回放功能只说本地缓存，没提云端存储（如OSS），无法支持离线回放。
- 互动消息只说WebSocket，没提消息队列的吞吐量优化，高并发下延迟问题。
- 视频流传输只说RTMP，没提HLS的移动端缓存优势，导致移动端体验差。