后端与系统架构4134 字

如何设计亿级用户短视频系统

·全库 532 / 611

《如何设计亿级用户短视频系统》共 0.4 万字,通篇围绕 需求、架构、微服务、并发 展开,归在「后端与系统架构」这一层。

覆盖需求架构微服务并发部署合规

适合给 AI 系统搭底座、要管得住的人

目录骨架(8 节)
  1. 业务介绍
  2. 1、需求分析
  3. 2、概要设计
  4. 3、详细设计
  5. 4、总结
  6. 1、视频存储系统设计
  7. 2、性能优化与 CDN 设计
  8. 3、缩略图生成与推荐设计
目录 · 4 节

本次分享

  1. 短视频系统业务介绍
  2. 短视频系统需求分析
  3. 短视频系统详细设计(视频存储、性能优化、CDN设计、缩略图生成、智能推荐)
  4. 总结

业务介绍

视频(short video)通常时长在 15 分钟以内,主要是在移动智能终端上进行拍摄、美化编辑或加特效,并可以在网络社交平台上进行实时分享的一种新型视频形式。短视频具有时间短、信息承载量高等特点,更符合当下网民手机使用行为习惯,短视频的用户流量创造了巨大的商机。

我们准备开发一个面向全球用户的短视频应用,用户总量预计 20 亿,应用名称:QuickTok。

视频文件和其他媒体文件相比,会更大一点,这就意味着存储短视频文件需要更大的存储空间,播放短视频也需要更多的网络带宽。因此,QuickTok 的主要技术挑战是:如何应对高并发用户访问时的网络带宽压力,以及如何存储海量的短视频文件。接下来我们就来看看 QuickTok 的需求与技术架构。

1、需求分析

QuickTok 的核心功能需求非常简单:用户上传视频、搜索视频、观看视频。我们将主要分析非功能需求。

QuickTok 预计用户总量为 20 亿,日活用户约 10 亿,每个用户平均每天浏览 10 个短视频,由此可以预估,短视频日播放量为 100 亿:

10 亿 × 10 = 100 亿

平均播放 QPS 为 11 万 / 秒:

100 亿 ÷ (24 × 60 × 60) ≈ 11 万 / 秒

每秒 11 万用户点击视频,假设用户平均观看 5 分钟,那么同时在观看的视频数就是:

11 万 / 秒 × 5 × 60 秒 = 3 千万

假设每个短视频的平均播放次数 200 次,那么为了支撑这样体量的播放量,平均需要每秒上传视频数:

11 万 / 秒 ÷ 200 = 550 / 秒

每个短视频平均大小 100MB,每秒上传至服务器的文件大小为:

100_MB_ × 550 = 55_GB_

视频虽然不是一秒内上传至服务器的,但是这样计算依然没有问题。

每年新增视频需要的存储空间:

55_GB_ × 60 × 60 × 24 × 365 = 1700_PB_

事实上,为了保证视频数据的高可用,不会因为硬盘损坏导致数据丢失,视频文件需要备份存储,QuickTok 采用双副本的备份存储策略,也就是每个视频文件存储三份,需要的总存储空间:

1700_PB_ × 3 = 5200_PB_

而播放视频需要的总带宽:11 万 × 100_MB_ × 8_bit_ = 88_Tb_

因此,我们需要设计的短视频应用是一个每秒上传 550 个视频文件、11 万次播放、新增 165GB 存储以及 88Tb 总带宽的高并发应用系统。这个系统呢需要是高性能的,能迅速响应用户的上传和播放操作,也需要是高可用的,能面向全球用户提供 7 * 24 小时稳定的服务。

2、概要设计

QuickTok 的核心部署模型如下图:

​

用户上传视频时,上传请求会通过负载均衡服务器和网关服务器,到达视频上传微服务。

视频上传微服务需要做两件事:一是把上传文件数据流写入视频文件暂存服务器;二是把用户名、上传时间、视频时长、视频标题等视频元数据写入分布式 MySQL 数据库。

视频文件上传完成后,视频上传微服务会生成一个视频上传完成消息,并将其写入到消息队列服务器。视频内容处理器将消费这个上传完成消息,并根据消息内容,从视频文件暂存服务器获取视频文件数据,进行处理。

视频内容处理器是一个由责任链模式构建起来的管道。在这个管道中,视频将会被顺序进行内容合规性审查、内容重复性及质量审查、内容标签生成、视频缩略图生成、统一视频转码处理等操作,如下图:

​

合规且非重复的视频会经过统一转码,最终被写入分布式文件存储和 CDN。这样视频上传处理就完成了,具体时序图如下:

​

以上就是对视频上传环节的设计,接下来我们将讨论对视频搜索及播放部分的设计,即核心部署模型图中标红的部分,如下:

​

视频搜索引擎会根据用户提交的视频标题、上传用户等元数据,以及视频内容处理器生成的内容标签构建倒排索引。当用户搜索视频时,系统会根据倒排索引来检索符合条件的视频,并返回结果列表。结果列表在 App 端向用户呈现时,会将此前视频内容处理器生成的缩略图展现给用户,使用户对视频内容有个初步而直观的感受。

当用户点击缩略图时,App 开始播放视频。App 并不需要下载完整个视频文件才开始播放,而是以流的方式一边下载视频数据,一边播放,使用户尽量减少等待,获得良好的观看体验。QuickTok 使用 MPEG–DASH 流媒体传输协议进行视频流传输,因为这个协议具有自适应能力,而且支持 HTTP,可以应对 QuickTok 的视频播放需求。

3、详细设计

为解决 QuickTok 的两个重要问题:如何存储海量视频文件?如何解决高并发视频播放导致的带宽压力?详细设计将关注视频存储系统、性能优化与 CDN。

资料里没有你的场景?

把你手上的数据和想解决的那个环节发上来,我们按具体情况回,不复述方法论。

发布需求