
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
加载中...