短视频流媒体平台的系统设计

1. 功能需求:

我们的系统有两类参与者

内容创作者

•上传任何类型的视频（格式+编解码器）•视频可以被删除•视频元数据•必填项: 标题，作者，描述•选填项: 分类/标签列表•可以随时更新•当视频对观众可用时，向内容创作者发送电子邮件

不在讨论范围内:

•直播•视频修改•支付和订阅

用户/观众

•需要注册+订阅•使用自由文本搜索视频属性/元数据•在以下设备上观看视频•任何设备（移动设备，平板电脑，桌面电脑）•使用网络浏览器/专用应用•在不同的网络条件下

2. 非功能需求:

内容创作者

•可扩展性•1000名用户平均每周上传1个视频•视频可以达到60 FPS，时长数小时，高分辨率且未压缩•视频大小约50 GB（>50 TB/周）•可用性（低停机时间）•99.9%的正常运行时间•性能•响应时间在99pt时< 500 ms•视频在几小时内对用户可用•数据一致性（CAP）•在我们的案例中，对于内容创作者：一致性 (CP) > 可用性 (AP)

用户/观众

•可扩展性•数亿每日用户•可用性•99.9%的正常运行时间•性能•响应时间在99pt时< 500 ms•无论用户的设备大小和网络如何，播放时都无缓冲时间•数据一致性（CAP）•在这种情况下，可用性 (AP) > 一致性 (CP)

3. 视频传输流程理解:

1*wxdVdbXya9eoyEjjTlEJSw.png

点播视频传输图:

视频编解码器: H.264 / AVC, H.265 / HEVC, VP9, AV1

音频编解码器: AAC, WAV, MP3, WMA

向终端用户传输压缩视频我们如何为个别用户决定比特率？根据设备决定比特率风险:

•高估用户的带宽•低估用户的带宽

如果我们只考虑设备，可能会有很多网络变化，最好的方法是考虑网络条件。这种技术称为自适应比特率 (ABR)。在这种技术中，我们基本上将不同比特率的转码视频流分解成通常为5-10秒的片段，并在清单文件中引用它们，所以当用户开始播放视频时，它首先下载清单文件并缓冲前3个片段，之后它会重新评估带宽，从更高或更低比特率的版本中选择片段。如果您想了解更多关于ABR的信息，请点击这里

最后一步是我们的转码视频作为包被提供，不同的浏览器，应用遵循不同的协议和交付格式，所以我们必须将我们的视频打包成每一种协议，并且我们必须使用DRM（数字版权管理）来保护我们的视频。

4. 符合内容创作者和用户功能需求的系统架构图:

以下图表符合我们所有的功能需求。

5. 符合非功能需求的系统架构图:

现在是时候让我们的应用程序可扩展，以满足非功能需求了。

内容创作者:

可扩展性

•由于上传视频的频率并不很高，所以我们可以在我们的Web应用和视频数据服务前面放置负载均衡器，并运行每个服务的几个实例。•相反，每个视频的体积非常大，所以我们需要识别我们流程中的瓶颈，因此之前我们的视频文件首先被发送到API网关，然后是web应用，最终web应用将文件存储到我们的对象存储中，但是我们可以使用签名URL，因为我们在API和web应用服务上浪费了大量的网络和计算能力。签名URL将允许直接访问对象存储的时间和权限有限的访问。

可用性

•通过在我们的服务中使用冗余，我们已经提供了高可用性，此外，通过使用云托管的对象存储进行转码和打包服务，我们可以直接获得可用性。对于最后一步，我们需要在NoSql数据库上进行复制，以便视频服务。

性能

•如果我们的所有内容创作者都想在同一天或同一时间上传视频怎么办？我们可能无法在合理的时间内处理它们。为了确保成功，我们需要在视频处理管道中提供足够的并行性。

数据一致性

•为了随时更新元数据，我们需要选择视频服务数据库的DB技术或配置，以提供一致性（CP）在分区容错上优先于可用性（AP）。

以上所有内容，我们现在已经完成了内容创作者的所有非功能需求。

用户/观众:

可扩展性

•为了满足数百万用户的请求，我们需要将搜索服务放在负载均衡器后面，并将其作为一组相同的实例运行，然后复制搜索数据库，以便我们可以支持新请求并将它们分散到多个数据库实例中。

可用性

•关于高可用性，我们已经基本上覆盖了，我们需要做的唯一事情是在多个隔离区域和地理位置运行我们的系统，例如美国西部，美国东部，亚太地区，欧洲。

性能

•解决性能问题的最重要组件是添加CDN。此外，我们不会更新视频数据服务与对象存储中的视频位置，而是将CDN url添加到视频服务数据库。所以现在当用户通过API请求视频URL时，它将提供指向CDN的url，并且它将从最近的边缘服务器将内容提取到用户的设备，这将导致视频的前两个片段更快地到达用户，之后自适应比特率流媒体将启动，并将缓冲时间减少到几乎为零。