System Design Interview by Alex Xu
System Design Interview
目录
设计 YouTube 设计 YouTube
- 重要组件：元数据存储、转码服务、视频存储、CDN、API 服务
- 重要概念：流式传输（边下边播）有对应的协议
- 视频转码：DAG 调度一系列任务，视频、音频、元数据，视频检查、缩略图生成、添加水印、编码等
- 错误处理：重试、兜底、告警、扩容等
- 成本优化：针对长尾，热门走 CDN 冷门走存储，冷门少编码、按需编码
主流流式传输协议
- HTTP 自适应流（点播 / 直播主流）
- HLS（HTTP Live Streaming）
- 苹果主导，基于 HTTP/TCP，将视频切为ts 分片（2–10 秒），用m3u8索引管理
- 支持自适应码率（ABR）、跨终端、CDN 友好、兼容性极强
- 延迟：普通版10–30 秒，低延迟版（LL-HLS）可至3–5 秒
- DASH（Dynamic Adaptive Streaming over HTTP）
- MPEG 标准，通用型自适应协议，切片为 MP4/TS，索引为MPD
- 比 HLS 更灵活，适配更多编码 / 加密 / 码率策略，被视为下一代通用协议
- 延迟：普通版10–30 秒，低延迟版（LL-DASH）可至3–5 秒
- HTTP-FLV
- 基于 HTTP 封装 FLV，延迟3–5 秒，适合直播拉流，浏览器需插件 / 播放器支持
- HLS（HTTP Live Streaming）
- 实时 / 推流协议（直播专用）
- RTMP/RTMPS
- Adobe 开发，基于 TCP，低延迟（1–3 秒），主要用于主播推流到服务器
- 浏览器原生不支持，需 Flash / 播放器，现多用于推流而非分发
- WebRTC
- 浏览器原生实时通信，延迟 <400ms，适合视频会议、低延迟互动直播
- SRT
- 低延迟、抗丢包，适合专业直播 / 广电传输，延迟 <1 秒
- RTSP/RTP
- 控制 + 传输分离，多用于监控、IPTV，需专用服务器，防火墙穿透差
- RTMP/RTMPS
- HTTP 自适应流（点播 / 直播主流）
常见视频网站技术方案
- YouTube
- 点播 / 直播分发（观众端）：HLS 为主，DASH 为辅，适配 HTML5 播放器与多终端
- 直播推流（主播端）：RTMP/RTMPS为主，也支持 HLS、DASH 推流
- Bilibili
- 点播 / 直播分发（观众端）：DASH 为主，HLS 兼容，适配多终端与自适应码率
- 直播推流（主播端）：RTMP为主，部分场景用 HTTP-FLV 拉流
- 行业主流协议现状
- 点播 / 大规模直播分发：HLS 与 DASH 双主流，HLS 兼容性更强、DASH 更灵活
- 直播推流：RTMP/RTMPS仍是事实标准，WebRTC、SRT 在低延迟场景快速崛起
- 低延迟互动直播：WebRTC、LL-HLS、LL-DASH成为趋势
- YouTube
直播流媒体与点播的异同
- 相同点
- 核心分发协议通用：HLS/DASH均可用于直播与点播，均支持ABR、CDN 分发、多终端兼容
- 均需视频转码、切片、元数据管理、缓存 / CDN等基础架构
- 不同点
维度 点播（VOD） 直播（Live） 内容源 预录制、存储在服务器 实时采集、边录边传 延迟要求 高（10–30 秒可接受） 中 / 低（普通 1–30 秒，互动 < 1 秒） 用户控制 完整（暂停、快进、后退） 有限（仅暂停 / 播放，无快进） 协议侧重 分发优先（HLS/DASH） 推流 + 分发并重（RTMP 推流 + HLS/DASH 分发） 架构差异 转码后永久存储、按需拉取 实时转码、实时分发、无永久存储 错误处理 可重试、容错空间大 低延迟、快速恢复、不可长时间重试
- 相同点
- Directed Acyclic Graph 有向无环图
- DAG 就是一套 “有先后顺序、没有循环、可并行” 的任务依赖关系图
- DAG 任务调度 = 根据 DAG 定义的依赖关系，自动按顺序 / 并行执行一批任务，并处理：依赖、重试、失败、超时、资源分配、状态流转
- 它解决的核心问题：一堆任务之间有复杂依赖，我不想手动一个个跑，也不想写一堆 if/else，让调度器自动帮我安排。
- DAG 调度的核心能力
- 任务依赖管理
- 分布式执行
- 容错与重试
- 资源调度
- 可视化与监控
- 事件触发
- DAG 调度的通用工作流程
- 定义 DAG：用代码 / 界面画出任务和依赖
- 提交 DAG：交给调度系统
- 调度器解析：计算哪些任务可运行（依赖满足）
- 放入任务队列
- Executor / Worker 拉取执行
- 更新状态
- 触发下游任务
- 全部完成 → DAG 结束
- 失败 → 重试 / 告警 / 终止下游
- DAG 调度典型应用场景
- 视频 / 音频媒体处理（YouTube、B 站、抖音）：典型 DAG 密集型场景，任务多、依赖复杂、必须并行
- 大数据 ETL / 数据仓库：每天几万个任务，必须 DAG 调度
- 机器学习流水线 MLOps：一步错，全流程作废，必须强依赖
- CI/CD 构建发布：Argo Workflows / Tekton 都是 K8s 上的 DAG 调度
- 批量计算、离线任务
- 主流开源 DAG 调度工具
- Apache Airflow（最主流、行业标准）：Python 定义 DAG，灵活、生态极强、支持几乎所有系统
- Apache DolphinScheduler（国产、易用、可视化）：拖拽式 DAG、中文友好、企业级稳定
- Argo Workflows（K8s 原生）：适合 CI/CD、微服务任务、云转码
- Taier（大数据专用、分布式）：分布式 DAG 调度系统，专注大数据任务管理
- Goflow（轻量级、Go 语言）：轻量级 DAG 调度与监控平台，Go 编写、部署极简
设计 YouTube
加载中...
