视频流系统设计 (YouTube/Netflix)

发表于 分类于

Netflix 占全球互联网下行流量的 15%，YouTube 每分钟上传 500 小时视频。视频流系统的挑战在于：海量存储、实时转码、全球低延迟分发、以及千人千面的推荐。

一、核心需求

需求 说明
上传视频 支持各种格式、码率、分辨率
转码处理 将原始视频转为多个分辨率+码率版本
自适应流 根据用户网络状况动态切换清晰度
全球分发 CDN 边缘节点缓存，就近服务
搜索推荐 基于用户行为的个性化推荐

二、视频上传与存储

2.1 上传流程

1
2
3
4
5
6
7
8
9
10
11
12
客户端 → 分片上传 → 对象存储(S3)
                      │
                  [消息队列]
                      │
              ┌───────┴───────┐
              │   转码服务     │
              │  (异步处理)    │
              └───────┬───────┘
                      │
              多分辨率版本 → 对象存储
                      │
                    CDN 预热

2.2 分片上传

大视频（>100MB）必须分片上传：

  • 将视频切分为 5-10MB 的 chunk
  • 支持断点续传：上传中断后可从中断位置继续
  • 合并：上传完成后，服务端合并所有分片（或直接保存分片元数据）

2.3 存储架构

Netflix 将视频存储到 Amazon S3，但实际播放是从 Open Connect CDN 直接分发。存储和分发解耦：

  • 原视频存储：S3/OSS 对象存储，原始的高码率视频
  • 转码版本：同样存储在对象存储，生成 1080p/720p/480p/360p/240p 多版本
  • 元数据存储：MySQL/PostgreSQL 存储视频标题、描述、标签、时长

三、视频转码

3.1 为什么需要转码

原始视频通常是单一高分格式（如 4K 60fps H.264），但用户设备差异巨大：

  • iPhone 13 支持 HEVC 硬解
  • Android 低端机可能只支持 H.264 Baseline
  • 浏览器 Web 端用 VP9 或 AV1
  • 弱网用户需要 360p 低码率版本

3.2 转码流水线

1
2
3
4
原始视频 → 分析(场景检测) → 切片(按场景切段) → 并行转码 → 合并 → 输出多版本
                │
           [机器学习]
           (内容分类/敏感内容检测/字幕生成)

关键优化：

  • DAG 调度：每个转码任务抽象的 DAG 节点，利用工作流引擎（如 Netflix Maestro）编排
  • 自适应码率 (ABR)：HLS/DASH 协议将视频切为 2-4 秒的小片段，每片段有多个码率版本。播放器根据当前缓冲和带宽动态切换。
  • GPU 加速：使用 NVIDIA GPU + NVENC 硬件编码，比 CPU 编码快 10x

四、内容分发网络 (CDN)

4.1 Netflix Open Connect

Netflix 不依赖第三方 CDN，而是构建了自己的 CDN 网络 Open Connect：

  1. 将视频内容预推送到全球 1000+ 个 ISP 机房
  2. 用户点播时，请求首先路由到最近的 Open Connect 节点
  3. 节点有缓存则直接返回，没有则回源拉取

关键指标：Netflix 的直播流可以在 60 秒内推送到 1 亿台设备。

4.2 CDN 缓存策略

策略 说明
热门内容 预热到所有边缘节点（如热门剧集全集）
长尾内容 仅存储在中心节点，按需回源
分层缓存 L1（边缘）→ L2（区域）→ L3（中心/源站）
TTL 设置 不同内容设置不同 TTL，热门内容缓存更久

五、直播 vs 点播

5.1 架构差异

维度 点播 (VOD) 直播 (Live)
延迟要求 秒级可接受 毫秒-秒级（体育赛事）
内容处理 可提前转码 实时转码
分发方式 CDN 缓存 边缘节点实时转发
协议 HLS (10-30s 延迟) WebRTC/RTMP (500ms-2s)

5.2 直播架构

1
2
3
主播端 → RTMP 推流 → 直播服务器 → 实时转码(ABR) → 
    ├→ HLS 切片生成 → CDN 分发 → 普通观众 (10s 延迟)
    └→ WebRTC 低延迟通道 → 交互式观众 (500ms 延迟)

Netflix 在 2024 年首次支持全球直播（如体育赛事、脱口秀），技术要点：

  • 使用 Fastly CDN 边缘计算处理实时转码
  • HLS 低延迟模式（LL-HLS）将延迟降到 2-3 秒
  • 全球同步：通过 NTP 时间同步保证不同地区观众看到同一时刻内容

六、播放器自适应码率

6.1 ABR 算法

播放器持续监测：

  • 缓冲区长度：当前缓冲了多少秒数据
  • 下载速度：每个片段下载耗费的时间

决策逻辑：

1
2
3
4
5
6
if buffer < 5s:
    切换到最低码率（防止卡顿）
elif buffer > 15s:
    切换到更高码率（提高清晰度）
else:
    保持当前码率

6.2 预加载策略

  • Netflix 在浏览页面时后台预加载预告片
  • YouTube 预加载推荐列表前 3 个视频的首个片段
  • 利用用户行为预测下一个可能播放的视频

七、数据架构与搜索

7.1 视频元数据

1
2
3
4
5
6
7
8
9
video_id: 主键
title: 标题
description: 描述
tags: [数组]
duration_seconds: 时长
uploader_id: 上传者
urls: {1080p: "...", 720p: "...", 480p: "..."}
view_count: 播放量 (定期更新)
created_at: 上传时间

7.2 搜索引擎

YouTube 的搜索基于 Elasticsearch：

  • 倒排索引覆盖标题、描述、字幕
  • 排序公式综合播放量、点赞、评论、上传时间
  • 个性化排序通过机器学习模型（用户历史、兴趣特征 + 视频特征）计算相关性分数

八、容量估算

假设 10 亿视频，平均大小 500MB，总存储 = 10亿 × 500MB = 500PB（不含多码率版本和副本）

  • 每日上传 100 万视频，100万 × 500MB = 500TB/天
  • 如果 10% 是热门内容需要 CDN 缓存：50TB × 3副本 = 150TB CDN 存储

YouTube 使用 Google 自研的 Colossus 文件系统 + Spanner 数据库，Netflix 使用 AWS S3 + Cassandra。

九、小结

视频流系统的核心挑战是规模——从存储、转码、分发到播放的完整链路都必须在亿级用户和海量内容上保持稳定。关键技术：分片上传 + 异步转码流水线 + 自适应码率 (ABR) + 全球 CDN 分层缓存。Netflix 和 YouTube 分别代表了”自建 CDN”和”云原生”两种路线，都验证了各自在超大规模下的可行性。