设计YouTube

在本章中，您被要求设计YouTube。这个问题的解决方案可以用于其它面试，比如设计B站、NetFlix和Hulu等视频共享平台。下图显示了YouTube主页：

YouTube看起来很简单：内容创作者上传视频，观众点击播放。

但真的那么简单么？并不是，简单的背后有许多复杂的技术。

让我们来看看2020年YouTube一些令人印象深刻的统计数据：

• 月活跃用户总数：20亿
• 用户每日观看的视频数量：50亿
• 73%的美国成年人使用YouTube
• YouTube上有5000万创作者

从这些数据中我们可以知道YouTube的体量是巨大的，能够带来许多收益。

Step1：Understand the problem and establish design scope

除了看视频，你还以在YouTube上做许多事情，例如：评论、点赞、分享和订阅等。我们不可能在一场短短的面试中设计出所有功能，因此提出问题来缩小范围是很重要的。

对于”设计YouTube“这个系统设计话题，我们可以向面试官提出以下问题：

• Q：哪些功能很重要？

  A：能够上传视频和观看视频

• Q：我们需要支持哪些用户？

  A：移动应用程序、Web浏览器和智能电视

• Q：我们每天有多少活跃用户？

  A：500万

• Q：用户平均每天花在产品上的时间是多少？

  A：30分钟

• Q：我们需要支持国际用户么？

  A： 是的，很大一部分是国际用户

• Q：视频最高支持多少分辨率？

  A：这个系统接受大多数视频分辨率格式，最高支持4K

• Q：视频需要加密么？

  A：是的

• Q：视频的文件大小有什么要求么？有没有最高上限？

  A：我们主打中小视频，因此视频上传大小最大为1GB

• Q：我们能利用一些现有的云基础设施么？如亚马逊、谷歌、微软提供的云服务。

  A：这是一个很好的问题。对大多数公司来说从零开始构建是不现实的，建议利用现有的第三方云服务

Step2：Propose high-level design and get buy-in

正如前面所说，面试官建议利用现有的云服务，而不是从头开始构建所有内容。CDN和blob存储是我们将利用的云服务。我们借助第三方bolb存储用于存储源视频，这里不展开讨论blob存储的详细设计。

在High-Level，该系统包含三个组件：

• Client：你可以在电脑、手机和智能电视上观看YouTube
• CDN：视频缓存在CDN服务器中，当您按下播放键时，会从CDN中播放视频。
• API Servers：除了视频流外，其它所有请求都通过API服务器，包括视频推荐、生成视频上传URL、更新元数据库和数据库缓存、用户注册等。

在问答环节，面试官对以下两个方面表现出兴趣：

• Video Uploading Flow（视频上传流程）
• Video Streaming Flow（视频流）

我们将探索这两个方面的高级设计。

Video Uploading Flow

下图展示了视频上传流程的所有组件：

它由以下组件组成：

• Users：用户在电脑、手机或智能电视等设备上观看Youtube。

• Load Balancer：负载均衡器在API Servers之间均匀地分配请求

• API Servers：除了视频流外，所有请求都通过API Servers

• MetaData DB：视频元数据存储在源数据库中，它是分片和复制的，以满足性能和高可用性需求

• Original Stortage：bolob存储系统用于存储原始视频

• Transcoding Servers：视频转码，它将视频格式转换为其它格式，用于不同设备的最佳视频流

• Transcoding Stroage：这是一种存储转码视频文件的bolb存储

• CDN：视频缓存在CDN中。

• Completion Queue：完成队列，它是一个消息队列，存储有关视频转码完成事件的信息

• Completion handler：它从完成队列中中提取事件数据并更新元数据缓存和数据库的Workers列表

现在我们分别了解了每个组件，让我们来看看视频上传流程是如何工作的：

流程被分解为两个并行运行的进程：

• a：Upload the actual video（上传实际视频）
• b：Update video metadata（更新视频元数据）

Flow a：upload the actual video

上图显示了如何上传实际视频：

1. 视频上传到原始存储服务器
2. 转码服务器从原始存储服务器中获取视频并开始转码
3. 一旦转码完成，以下两个步骤将同时执行
   • 转码的视频被发送到转码存储服务器
   • 转码完成事件在完成队列中排队
4. 将转码后的视频分发到CDN；Completion Hander从完成Completion Queue中提取事件数据
5. Completion Hander更新元数据库和缓存
6. API Servers通知Client视频已成功上传并准备好流式传输

Flow b：update the metadata

当一个文件被上传到原始存储时，客户端并行地发送一个更新视频元数据的请求，如下图所示：

请求包含视频元数据，包括文件名、大小、格式等；API服务器更新元数据缓存和数据库。

Video Streaming Flow

每当你在YouTube上观看视频时，它通常会立刻开始流媒体播放，而且你并不需要等待整个视频加载完毕。

这是因为流媒体技术，流媒体意味着您的设备不断接收来自服务器源视频的视频流，当你观看流媒体视频时，你的设备一次加载一点数据，这样你就可以立即连续地观看视频。

在讨论视频流之前，让我们先来了解一个重要的协议：流媒体协议。流媒体协议是控制视频流的标准方式。

目前常用的流媒体协议有以下几种：

• MPEG-DASH
• Dynamic Adaptive Streaming over HTTP
• Apple HLS. HLS stands for “HTTP Live Streaming”
• Microsoft Smooth Streaming
• Adobe HTTP Dynamic Streaming(HDS)

你不需要记住这些流媒体协议的名称，只需要注意不同的流媒体协议支持不同的视频编码和视频播放器。

视频直接从CDN流式传输–离您最近的服务器将提供视频，因此延迟非常小

Step3：Design deep dive

在高层设计中，整个系统分为两个部分，video uoloading flow和video streaming flow，在本章中，我们将使用重要的优化来完善这两个流程，并介绍错误处理机制。

video transcoding

录制视频时，设备会为视频文件提供特定格式。如果希望视频在其他设备上流畅播放，则必须将视频编码为其他设备上兼容的比特率和格式。较高的比特率意味着较高的视频质量。

DAG Model

对视频进行编码转换在计算上既昂贵又耗时。此外，不同的内容创作者可能会有不同的视频处理要求。例如，一些内容创作者要求在视频顶部添加水印，一些创作者自己提供视频缩略图，一些创作者本身会上传超高清视频。

为了支持不同的视频处理流程，并且保持高并发，添加一些抽象级别并让客户端程序员定义要执行的任务是很重要的。facebook的流媒体视频引擎使用有向无环图模型。该模型分阶段定义任务，以便可以顺序或并行执行任务。

下图展示了用于视频转码的DAG模型：

在上图中，原始视频被切分为了视频、音频和元数据。
对于视频：有检查视频完整性、视频编码、缩略图生成、水印生成等任务

continue

后面的内容都和前面讲的几章有重复，gop对齐也没什么亮点。就不搬运了

Step4：Warm up

在本章中，我们介绍了像youtube这样的视频流服务的架构设计。如果距离面试结束还有一段时间，这里还有几点可以和面试官讨论：

• 扩展API层：由于API服务器是无状态的，因此很容易横向扩展api层
• 扩展数据库：您可以讨论数据库复制和分片
• 直播：现在大部分视频网站都有直播内容，您可以与面试官讨论如何实时录制和播放视频的过程。
  • 尽管我们的系统不是专门为直播而设计的，但直播和非直播有一些相似之处：都需要上传编码和流媒体协议
  • 直播和非直播的显著区别在于：
    • 但直播具有更高的延迟要求，因此可以需要不同的流媒体协议
    • 直播对并行性要求低，因为小块数据已经实时处理
    • 直播需要不同的错误处理，任何需要花费长时间的错误处理都是不可接受的
• 视频删除：违反版权、涩情火其他非法行为的视频应该被删除，一些可以在上传过程中被发现，而另一些可能通过用户标记（举报）发现

good job and goo luck!