设计Youtube或Netflix

设计Youtube或Netflix
让我们设计一个类似YouTube的视频共享服务，用户可以在其中上传/查看/搜索视频。类似服务：netflix.com，vimeo.com，dailymotion.com，veoh.com

1.为什么要使用YouTube？

Youtube是世界上最受欢迎的视频共享网站之一。该服务的用户可以上传，查看，共享，评分和报告视频，以及在视频中添加评论。

2.系统的要求和目标

为了进行此练习，我们计划设计一个满足以下要求的更简单版本的Youtube：

功能要求：

1. 用户应该可以上传视频。
2. 用户应该可以共享和观看视频。
3. 用户应能够基于视频标题进行搜索。
4. 我们的服务应能够记录视频的统计信息，例如喜欢/不喜欢，观看总数等。
5. 用户应该能够添加和查看视频评论。

非功能需求：

1. 该系统应高度可靠，上传的任何视频都不应丢失。
2. 该系统应具有很高的可用性。一致性可能会受到影响（为了可用性）；如果用户没有马上看到上传的视频，也是可以接受的。
3. 用户在观看视频时应该具有实时体验，并且不会感到任何滞后。

不在范围内：视频推荐，最受欢迎的视频，频道，订阅，稍后观看，收藏夹等。

3.容量估算和约束

假设我们有15亿总用户，其中8亿是日常活动用户。如果用户平均每天观看五个视频，则每秒的视频观看总数将为：

800M * 5/86400秒=> 46K视频/秒

假设我们的上传：观看比例为1：200，即，每上传一个视频，我们就会观看200部视频，从而使我们每秒可上传230部视频。

46K / 200 => 230个视频/秒

存储空间估算：假设每分钟有500小时的视频上传到Youtube。如果平均而言，一分钟的视频需要50MB的存储空间（视频需要以多种格式存储），则在一分钟内上传的视频所需的总存储空间为：

500小时* 60分钟* 50MB => 1500 GB /分钟（25 GB /秒）

这些是估计的数字，忽略了视频压缩和复制，这会更改实数。

带宽估算值：每分钟上传500小时的视频（每分钟上传30000分钟的视频），假设每分钟上传视频需要10MB的带宽，那么我们每分钟将获得300GB的上传资源。

500小时* 60分钟* 10MB => 300GB / min（5GB / sec）

假设上载/观看比例为1：200，则我们需要1TB / s的传出带宽。

4.系统API

＃
我们可以使用SOAP或REST API来公开我们服务的功能。以下可能是用于上传和搜索视频的API的定义：

uploadVideo(api_dev_key, video_title, video_description, tags[], category_id, default_language, recording_details, video_contents)

参数：
api_dev_key (string)：注册帐户的API开发人员密钥。除其他外，这将用于根据分配的配额限制用户。
video_title（string）：视频的标题。
video_description（string）：视频的可选描述。
tags（string []）：视频的可选标签。
category_id（string）：视频的类别，例如电影，歌曲，人物等
default_language（string）：例如英语，普通话，北印度语等
record_details（string）：录制视频的位置。
video_contents（stream）：要上传的视频。

返回：（字符串 String）
成功上传将返回HTTP 202（接受请求），视频编码完成后，将通过电子邮件通知用户并提供访问视频的链接。我们还可以公开一个可查询的API，以使用户知道其上传的视频的当前状态。

searchVideo(api_dev_key, search_query, user_location, maximum_videos_to_return, page_token)

参数：
api_dev_key（string）：我们服务的注册帐户的API开发人员密钥。
search_query（string）：包含搜索词的字符串。
user_location（string）：执行搜索的用户的可选位置。
maximum_videos_to_return（number）：一个请求中返回的最大结果数。
page_token（string）：此令牌将在结果集中指定应返回的页面。

返回：（JSON）
JSON，其中包含有关与搜索查询匹配的视频资源列表的信息。每个视频资源将具有视频标题，缩略图，视频创建日期和观看次数。

streamVideo(api_dev_key, video_id, offset, codec, resolution)

参数：
api_dev_key (string)：我们服务的注册帐户的API开发人员密钥。
video_id（string）：标识视频的字符串。
offset (number)：我们应该能够从任何偏移量流式传输视频；此偏移量是从视频开始算起的时间（以秒为单位）。如果我们支持从多个设备播放/暂停视频，则需要将偏移量存储在服务器上。这将使用户能够从上次停止观看视频的任何位置开始在任何设备上观看视频。
codec (string) & resolution(string)：我们应该从客户端通过API发送编解码器和分辨率信息，以支持来自多个设备的播放/暂停。想象一下，您正在电视的Netflix应用程序上观看视频，将其暂停，然后开始在手机的Netflix应用程序上观看。在这种情况下，您将需要编解码器和分辨率，因为这两个设备都具有不同的分辨率和使用不同的编解码器。

返回：（STREAM）来自给定偏移量的媒体流（视频块）。

5. 架构设计

从总体上讲，我们将需要以下组件：

1. Processing Queue 处理队列：每个上载的视频将被推送到处理队列，以便稍后进行出队以进行编码，缩略图生成和存储。
2. Encoder 编码器：将每个上传的视频编码为多种格式。
2. Thumbnails generator 缩略图生成器：为每个视频生成一些缩略图。
3. Video and Thumbnail storage 视频和缩略图存储：将视频和缩略图文件存储在某些分布式文件存储中。
4. User Database 用户数据库：用于存储用户信息，例如姓名，电子邮件，地址等。
5. Video metadata storage 视频元数据存储：一个元数据数据库，用于存储有关视频的所有信息，例如标题，系统中的文件路径，上载用户，总观看次数，喜欢，不喜欢等。它还将用于存储所有视频评论。

6.数据库架构

视频元数据存储-MySql
视频元数据可以存储在SQL数据库中。每个视频应存储以下信息：

• VideoID
• 标题
• 描述
• 尺寸
• 缩图
• 上载者/使用者
• 总点赞次数
• 不喜欢总数
• 总观看次数

对于每个视频评论，我们需要存储以下信息：

• 评论ID
• VideoID
• 用户身份
• 评论
• 创造时间

用户数据存储-MySql

• 用户ID，名称，电子邮件，地址，年龄，注册详细信息等。

7.详细的组件设计

该服务将是繁重的工作，因此我们将专注于构建可以快速检索视频的系统。我们可以预期我们的读取：写入比率为200：1，这意味着每上传一个视频，就有200个视频观看次数。

视频将存储在哪里：可以将视频存储在HDFS或GlusterFS之类的分布式文件存储系统中。

我们应该如何有效地管理读取流量？我们应该将读取流量与写入流量分开。由于每个视频都有多个副本，因此我们可以将读取流量分配到不同的服务器上。对于元数据，我们可以具有主-次配置，其中写入将首先到达主/次，然后在所有辅助上应用。这样的配置可能会导致数据过时，例如，当添加新视频时，其元数据将首先插入到主要视频中，而在将其应用于辅助视频之前，我们的辅助视频将无法看到它。因此，它将把过时的结果返回给用户。这种陈旧性在我们的系统中可能是可以接受的，因为它的生命周期非常短，并且用户可以在几毫秒后看到新的视频。

缩略图将存储在哪里：缩略图比视频要多得多。如果我们假设每个视频都有五个缩略图，则我们需要一个非常高效的存储系统，可以提供巨大的读取流量。在确定应将哪个存储系统用于缩略图时，将有两个注意事项：

1. 缩略图是小文件，每个缩略图最大为5KB。
2. 与视频相比，缩略图的阅读流量将是巨大的。用户一次只能观看一个视频，但他们可能正在查看包含20个其他视频缩略图的页面。

让我们评估一下将所有缩略图存储在磁盘上。鉴于我们有大量的文件，我们必须对磁盘上的不同位置执行多次查找才能读取这些文件。这是相当低效的，将导致更高的延迟。

在这里Bigtable可能是一个合理的选择，因为它将多个文件组合成一个块存储在磁盘上，并且在读取少量数据方面非常有效。这两项都是我们服务的两个最重要的要求。将热门缩略图保存在缓存中也将有助于提高延迟，并且鉴于缩略图文件很小，我们可以轻松地在内存中缓存大量此类文件。

视频上传： 由于视频可能很大，因此如果上传时连接断开，我们应该支持从同一点恢复。

视频编码：新上传的视频存储在服务器上，新任务添加到处理队列中，以将视频编码为多种格式。完成所有编码后，将通知上传者，并且视频可供观看/共享。

8.元数据分片

由于我们每天都有大量新视频，并且读取负载非常高，因此，我们需要将数据分发到多台计算机上，以便我们可以高效地执行读取/写入操作。我们有很多选项可以分片数据。让我们研究一下将数据一一分拆的不同策略：

基于UserID的分片： 我们可以尝试将特定用户的所有数据存储在一台服务器上。在存储时，我们可以将UserID传递给哈希函数，该哈希函数会将用户映射到数据库服务器，我们将在其中存储该用户视频的所有元数据。在查询用户的视频时，我们可以要求哈希函数找到保存用户数据的服务器，然后从那里读取数据。要按标题搜索视频，我们必须查询所有服务器，并且每个服务器都将返回一组视频。然后，集中式服务器将汇总这些结果并对其进行排名，然后再将其返回给用户。

这种方法有两个问题：

1. 如果某个用户变得受欢迎，该怎么办？拥有该用户的服务器上可能有很多查询；这可能会造成性能瓶颈。这也将影响我们服务的整体性能。
2. 随着时间的流逝，与其他用户相比，某些用户最终可能会存储很多视频。维持不断增长的用户数据的均匀分布非常棘手。

为了从这些情况中恢复，我们要么必须重新分区/重新分配数据，要么使用一致的哈希来平衡服务器之间的负载。

基于VideoID的分片：我们的哈希函数会将每个VideoID映射到随机服务器，我们将在其中存储该视频的元数据。要查找用户的视频，我们将查询所有服务器，每个服务器将返回一组视频。集中式服务器将汇总这些结果并对其进行排名，然后再将其返回给用户。这种方法解决了我们的热门用户问题，但将其转移到了热门视频上。

我们可以通过引入将热点视频存储在数据库服务器前面的缓存来进一步提高性能。

9.视频重复数据删除

随着大量用户上传大量视频数据，我们的服务将不得不处理广泛的视频复制。重复的视频通常在宽高比或编码方面有所不同，包含重叠或其他边框，或者是较长的原始视频的摘录。重复视频的泛滥可在多个层面上产生影响：

1. 数据存储：我们可能会通过保留同一视频的多个副本来浪费存储空间。
2. 缓存：重复的视频会占用可用于唯一内容的空间，从而导致缓存效率降低。
3. 网络使用情况：重复的视频还会增加必须通过网络发送到网络内缓存系统的数据量。
4. 能源消耗：更高的存储空间，低效的缓存和网络使用情况可能会导致能源浪费。
   对于最终用户，这些低效率将以重复的搜索结果，更长的视频启动时间以及流媒体中断的形式实现。

对于我们的服务而言，重复数据删除很早就有意义。用户上传视频时与后期处理以找到重复的视频相比。内联重复数据删除将为我们节省大量资源，可用于编码，传输和存储视频的重复副本。任何用户开始上传视频后，我们的服务便可以运行视频匹配算法（例如， 块匹配，相位相关等）以查找重复项。如果我们已经有要上传的视频的副本，则可以停止上传并使用现有的副本，或者如果质量更高，可以继续上传并使用新上传的视频。如果新上传的视频是现有视频的子部分，反之亦然，我们可以智能地将视频分成较小的块，以便仅上传缺少的部分。

10.负载平衡

我们应该在缓存服务器之间使用一致性哈希，这也将有助于平衡缓存服务器之间的负载。由于我们将使用基于静态哈希的方案将视频映射到主机名，由于每个视频的受欢迎程度不同，它可能导致逻辑副本的负载不均衡。例如，如果视频变得流行，则与该视频对应的逻辑副本将比其他服务器经历更多的流量。然后，逻辑副本的这些不均匀负载可以转化为相应物理服务器上不均匀的负载分配。要解决此问题，一个位置中的任何繁忙服务器都可以将客户端重定向到同一缓存位置中的较不繁忙的服务器。在这种情况下，我们可以使用动态HTTP重定向。

但是，重定向的使用也有其缺点。首先，由于我们的服务会尝试在本地进行负载平衡，因此如果接收重定向的主机无法为视频提供服务，则会导致多次重定向。同样，每个重定向都要求客户端发出一个额外的HTTP请求；在视频开始播放之前，也会导致更长的延迟。此外，层间（或跨数据中心）重定向会将客户端引导到遥远的缓存位置，因为更高层的缓存仅存在于少数位置。

11.缓存

为了服务于全球分布的用户，我们的服务需要大规模的视频交付系统。我们的服务应使用大量按地理位置分布的视频缓存服务器将其内容推近用户。我们需要制定一种策略，以最大程度地提高用户性能，并在其缓存服务器上平均分配负载。

我们可以为元数据服务器引入缓存，以缓存热数据库行。在命中数据库之前使用Memcache缓存数据和应用程序服务器可以快速检查缓存是否具有所需的行。对于我们的系统，最近最少使用（LRU）可能是合理的缓存逐出策略。在此政策下，我们将首先丢弃最近浏览最少的行。

我们如何建立更智能的缓存？如果我们遵循80-20规则，即视频的每日阅读量的20％产生了80％的流量，这意味着某些视频非常受欢迎，以至于大多数人都观看它们；因此，我们可以尝试将视频和元数据的每日阅读量的20％进行缓存。

12.内容交付网络（CDN）

CDN是一种分布式服务器系统，可根据用户的地理位置，网页的来源和内容交付服务器将网络内容交付给用户。

我们的服务可以将热门视频移至CDN：

• CDN在多个位置复制内容。视频更有可能靠近用户，并且跳数越少，视频将从更友好的网络流式传输。
• CDN机器大量使用缓存，并且大多数情况下可以将视频提供给内存不足的人。

CDN不会缓存的不太受欢迎的视频（每天1-20次观看）可以由我们在各种数据中心的服务器提供。

13.容错

我们应该使用一致性哈希在数据库服务器之间进行分配。一致的哈希不仅有助于替换死服务器，而且还有助于在服务器之间分配负载。