设计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：更新元数据

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