设计YouTube，支持视频上传，视频点播，以及评论、分享、点赞、保存播放列表、频道收藏等功能。

Step 1 - 明确需求

完整的YouTube功能繁杂，这里可以通过以下讨论来缩小设计范围：

  1. 需要支持哪些重要特性？=> 上传视频，观看视频
  2. 需要支持哪些客户端？=> 移动端，浏览器，智能电视
  3. 日活多少？=> 500万
  4. 用户平均每天的使用时间是多少？=>30分钟
  5. 需要支持国际用户吗？=>需要
  6. 支持的分辨率有哪些？=> 需要支持大部分视频格式和分辨率
  7. 支持加密传输吗？=> 支持
  8. 视频大小有什么限制？=>以中小文件为主，最大文件不超过1GB
  9. 可以借助Amazon、Google等云服务商提供的服务吗？=> 可以

这里以下列需求作为本系统设计的目标：

  • 支持快速上传视频
  • 流畅的视频观看体验
  • 支持切换视频分辨率
  • 低成本架构
  • 高可用性，扩展性，可靠性
  • 支持移动端，浏览器，智能电视

规模预估：

  • 假设产品有500万每日活跃用户
  • 用户平均每天观看5个视频
  • 10%的用户每天会上传一个视频
  • 视频大小为300MB
  • 每日视频存储空间需求：500万 * 10% * 300MB = 150 TB
  •  CDN成本。
    • CDN按流量计费
    • 假设CDN流量费用为$0.02/GB，则每日视频流量的CDN费用为：500万 * 5 * 0.3GB * $0.02 = $150000

CDN成本占据费用的大头。

Step 2 - 概要设计

借助现有的云服务来简化设计，可供使用的云服务包括CDN和对象存储（blog storage），下面系统包含的组件设计：

客户端：包括浏览器，APP，智能电视。

CDN：用于保存视频，当点击观看一个视频时，视频来自于CDN。

API服务器：除了视频流外的全部其他服务都走API服务器，包括视频流推荐，生成视频上传的URL，更新元数据库和缓存，用户注册等。

接下来探讨视频上传和视频点播的概要设计。

视频上传

包含以下组件：

  1. 用户：电脑，手机，智能电视
  2. 负载均衡：将请求平摊到各个API服务器
  3. API服务器：用于处理视频流之外的所有请求
  4. 元数据库：存储视频元数据，比如分辨率。使用分片和复制技术以提高可用性和可靠性。
  5. 元数据缓存：缓存视频元数据和用户对象，以提升性能。
  6. 原始存储：用于存储原始视频的对象存储系统。
  7. 转码服务器：用于将视频进行转码，以实现对不同的设备提供最适合的视频流。
  8. 转码存储：用于存储转码过的视频的对象存储系统。
  9. CDN：用于缓存视频，加速用户点播。
  10. 完成队列：用于存放视频转码结束的消息队列。
  11. 完成处理：用于从完成队列中取出消息，并更新视频的元数据和缓存。

整个上传过程可以分为两部分，先上传原始视频，再调整视频的元数据，比如视频URL，大小，分辨率，格式，用户信息等。

流程图1：上传原始视频

过程如下：

  1. 上传原始视频到原始存储中。
  2. 转码服务器从原始存储中取出视频并进行转码。
  3. 一旦转码完成，并行执行下两步：
    1. 将转码后的视频存储到转码存储中。
    2. 转码完成消息被推入消息队列。
  4. 转码后的视频被推送到CDN上。
  5. 转码事件处理集群从消息队列中取出消息，并更新元数据库和缓存
  6. API服务器通知客户上传结束。

流程图2：更新元数据

当客户端将视频上传到原始存储后，客户端会立即上传视频的元数据，这些数据会被保存到元数据缓存和数据库。转码完后应该还会再更新一次，增加转码后的元数据，比如新的格式和分辨率。

视频点播

使用流媒体传输协议进行点播，意味着不需要先下载整个视频再播放，而是边下边播。常用的流媒体传输协议有以下几种：

  1. MPEG-DASH
  2. Apple HLS
  3. Miscrosoft Smooth Streaming
  4. Adobe HDS

视频从CDN上下载，距离用户最近的CDN结点充当点播服务器，以降低点播延时。

Step 3 - 详细设计

优化上面的视频上传和视频点播服务，并增加一些错误处理机制。

视频转码

基因以下原因通常要对视频进行转码，以改变视频格式和码率：

  • 原始视频往往占用大量存储空间，转码之后可以进行压缩
  • 许多设备和播放器只支持某几种类型的格式，转码有助于提高兼容性
  • 为了保持点播流畅，需要预备几种不同分辨率的视频，对高带宽的用户提供高分辨率的视频，而对低带宽的用户提供低分辨率的视频，以保证流畅
  • 网络条件经常变化，尤其是在移动设备上，为了保证在不同网络条件下都能流畅播放，需要根据网络条件动态切换分辨率

转码时主要考虑以下两项因素：

  • 封装，比如.avi，.mov，.mp4
  • 编码：比如H264，VP9，HEVC

有向无环图（DAG）模型

视频转码是计算密集型任务，通常比较耗时。并且，不的内容创作者有不同的处理需求，比如有的需要加水印，有的需要生成缩略图，有的可能需要上传高清视频。为了支持不同的视频转码需求，必须按将转码设计成流水线形式，并且充分利用计算机的并行处理能力。这里可以将转码流程进行抽象，提取出不同的层次供客户进行选择。比如，Facebook使用有向无环图模式来定义各个阶段的任务，使得任务可以按顺序执行或是并行执行。这里采用一个类似的设计，以兼顾并行和灵活性。

这里将原始视频分成视频，音频，元数据来分别处理，以下是一些可用的任务：

  • 检查：确保视频格式正常
  • 视频转码：将视频转换成不同的分辨率、编码格式、码率等
  • 缩略图：自动生成视频的缩略图，也可以由用户手动上传
  • 水印：增加水印

视频转码架构

包含6个主要组件：预处理，DAG调度器，资源管理器，任务集群，临时存储，输出已转码视频。

预处理

包含以下四个处理：

  1. 视频分割。将视频按GOP进行分割。
  2. 一些老的移动设备或浏览器不支持视频分割，预处理器可以预先进行GOP分割以适配老设备。
  3. 生成DAG。根据客户勾选的转码选项或是预置的配置文件，生成DAG处理流程。
  4. 缓存数据。缓存分割后的视频，包括GOP和元数据。

DAG调度器

将DAG按阶段划分成不同的任务并且保存到资源管理器的任务队列中，以下是一个DAG调度器的示例：

上面的示例将原始视频分成两个阶段来处理，第1阶段，将原始视频划分成视频、音频、元数据；第2阶段，将视频文件划分成两个并行任务：转码和生成缩略图；音频需要在第2阶段再单独处理。这里第1阶段的所有任务和第2阶段的所有任务都可以并行处理。

资源管理器

用于管理资源的分配，包含三个队列以及一个任务调度器，如下图所示：

任务队列：存储即将执行的任务，是一个优先队列。

集群队列：存储集群的利用率，也是一个优先队列。

运行队列：包含当前正在运行的任务和工作服务器。

任务调度器：从任务队列中取出任务，从集群队列中取出工作服务器，然后把任务绑定到工作服务器上执行，并记录该信息到运行队列，当任务运行给后，释放工作服务器，并从运行队列中删除记录。

工作集群

执行DAG中预定的任务，包含不同种类的工作服务器，如下：

临时存储

用于存储元数据，转码过程中的临时音视频数据。根据存储需求可选用不同的存储系统，比如对元数据类的存储，则于内容往往较小，可使用缓存进行存储，而对于音视频数据，则需要使用对象存储。一旦完成转码，需要释放相关的资源。

转码视频

最终生成的文件，比如funny_720p.mp4。

系统优化

速度优化：并行上传视频

在客户端将视频按GOP拆分不同的块，然后并行上传，这种处理方式不但增加了并行能力，还可以有效处理重传问题，因为一旦上传失败，只需要重传那些失败的块就可以了。

速度优化：设立靠近用户的上传中心

好处显而易见。

速度优化：处处并行化

构造一个松耦合的系统，以充分利用并行能力。当前的系统设计如下：

上面的方式从原始视频到最终上传CDN，每一步都依赖上步执行的结果，这种方式不利于并行。为了充分达到并行处理的目的，需要将系统解耦合，一种设计方法是使用消息队列，像下面这样：

经转码模块为例，引入消息队列后，转码模块不再需要等待下载模块下载完数据，而是可以直接从消息队列中取任务进行执行。

安全优化：预签名的上传URL

用于确保只有经过认证的用户才能上传视频到指定的位置，操作流程如下：

用户在上传视频之前，必须先通过HTTP请求获取一个预签名的URL地址，URL中包含了本次上传许可，只有使用服务器返回的预签名URL才可以上传视频。

安全优化：保护你的视频

处理盗版视频问题，一般有以下方法：

  • 数据版权管理系统（DRM）：有三个主要的DRM系统，Apple FairPlay, Google Widevine, Microsoft PlayReady.
  • AES加密：对视频进行加密，并配置一个授权策略，然后在播放时进行解密，这样可以保证只有授权过的用户才可以解密视频。
  • 视觉水印：添加logo或制作者名称，用于声明视频的作者信息。

省成本优化

CDN是本系统的成本大头。根据长尾分布效应，只有少数受欢迎的视频会被频繁访问，而大部分视频都没多少观众，由此，可以引入下面的优化措施：

  1. 只对最受欢迎的视频提供CDN服务，其他大部分视频走服务器硬盘访问。
  2. 对于不常访问的视频，只存储少量转码后的版本，并且对于小文件，可以使用即时转码的方式。
  3. 某些视频只在特定区域受欢迎，因些不需要将这些视频发布到全部区域。
  4. 自建CDN，比如B站。

以上的优化措施与视频的访问量，用户模式，视频大小有关，需要有强大的数据分析进行支持。

错误处理

错误可分为两类：

  • 可恢复错误：比如转码失败，一般是再重试特定次数，如果仍然失败，则返回错误码给客户端。
  • 不可恢复错误：比如视频格式错误，一般会立即停止相关的任务，并且返回错误码。

以下是一些典型的错误：

  • 上传失败：重试一定次数。
  • 分割视频失败：如果是客户端版本老旧的问题，则可以将视频整个上传到服务器，则服务器来进行分割。
  • 转码失败：重试。
  • 预处理失败：重新生成DAG流程图。
  • DAG调度失败：重新调度。
  • 资源管理器队列掉线：使用备份。
  • 工作服务器掉线：重新分配服务器。
  • API服务器掉线：使用无状态设计，重新分配一个新的API服务器。
  • 元数据缓存服务器掉线：使用复制技术，当一台服务器掉线时，切换到另一台即可。
  • 元数据服务器掉线：
    • 主服务器掉线，则将一台从服务器临时提升成主服务器。
    • 从服务器掉线：切换到另一台从服务器。

Step 4 - 总结

以下是一些可供讨论的点：

  • 扩展API层：使用无状态设计可使API层扩展相对容易。
  • 扩展数据库：使用数据库分片和复制技术。
  • 直播流：
    • 直播流对延时要求较高，可能需要不同的流媒体协议
    • 直播流对并行处理要求相对较低，因为直播流本来就是分块按顺序实时到达的。
    • 直播流的错误处理不能花太多时间。
  • 视频拦截：为构建社会主义和协社会，对盗版视频、色情视频等不合法视频应及时移除。有些类型可在上传时由系统发现并处理，另一些则可能需要人工辨识。



















































  • 无标签