阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 疯狂打码中 「细节探索者」欢迎转载，保留摘要，谢谢！

• 1、需求分析
• 2、概要设计
• 3、详细设计
• 4、总结

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

一、前言

这个业务不熟悉。但是抖音的崛起，短视频场景也会是面试的考点。希望能够属性一下相关的大致数据。

短视频应用QuickTok的需求与技术架构详解

视频，尤其是短视频，以其时长在15分钟以内的精炼形式，成为了移动智能终端上拍摄、美化编辑、加特效并实时分享的新型视频形式。短视频凭借时间短、信息承载量高等特点，完美契合了当下网民的手机使用习惯，其用户流量更是孕育了巨大的商业机遇。

在此背景下，我们着手开发一个面向全球20亿用户的短视频应用——QuickTok。

相较于其他媒体文件，视频文件体积较大，这意味着存储短视频需要更为庞大的存储空间，播放时也需要更高的网络带宽。因此，QuickTok面临的主要技术挑战在于：如何应对高并发用户访问时的网络带宽压力，以及如何高效存储海量的短视频文件。接下来，让我们深入探讨QuickTok的需求与技术架构。

1、需求分析

QuickTok的核心功能需求简洁明了：用户能够轻松上传、搜索并观看视频。在此基础上，我们将深入剖析其非功能需求的重要性。

QuickTok预计将迎来20亿用户的庞大群体，其中日活跃用户将达到约10亿。若每位用户日均浏览10个短视频，那么短视频的日播放量将惊人地达到100亿次：

10亿 × 10 = 100亿

进一步推算，平均每秒的播放查询量（QPS）约为11万次：

100亿 ÷ （24小时 × 60分钟 × 60秒） ≈ 11万次/秒

这意味着每秒有11万用户点击视频。假设用户平均观看时长为5分钟，那么同时在线观看的视频数量将高达3000万个：

11万次/秒 × 5分钟 × 60秒 = 3000万

再考虑每个短视频平均被播放200次，为了支撑如此庞大的播放量，每秒需上传的视频数量达到550个：

11万次/秒 ÷ 200 = 550个/秒

鉴于每个短视频的平均大小为100MB，每秒上传至服务器的数据量即为55GB：

100MB × 550 = 55GB

虽然视频并非在瞬间全部上传至服务器，但此估算方法依然有效。

对于每年新增的视频内容，所需的存储空间高达1700PB：

55GB × 24小时 × 60分钟 × 60秒 × 365天 = 1700PB

然而，为了确保视频数据的高度可用性和防止数据丢失，QuickTok采用双副本备份存储策略，即每个视频文件存储三份。因此，总存储空间需求跃升至5200PB：

1700PB × 3 = 5200PB

此外，播放视频所需的总带宽也极为可观，达到88Tb：

11万次 × 100MB × 8bit = 88Tb

综上所述，我们需要构建的短视频应用需具备每秒上传550个视频文件、处理11万次播放请求、新增165GB（55GB×3）存储空间以及支持88Tb总带宽的高并发处理能力。这一系统不仅要求高性能，能够迅速响应用户的上传和播放需求，还必须确保高可用性，为全球用户提供7×24小时的稳定服务。

2、概要设计

QuickTok的核心部署模型如图所示：

用户上传视频时，请求会经过负载均衡服务器和网关服务器，最终到达视频上传微服务。该服务需完成两项任务：一是将上传文件数据流写入视频文件暂存服务器；二是将用户名、上传时间、视频时长、视频标题等元数据写入分布式MySQL数据库。

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

视频内容处理器是一个由责任链模式构建的管道，视频将在此管道中依次进行内容合规性审查、内容重复性及质量审查、内容标签生成、视频缩略图生成以及统一视频转码处理等操作。

合规且非重复的视频经过统一转码后，将被写入分布式文件存储和CDN。至此，视频上传处理流程完成，具体时序图如下所示：

以上是对视频上传环节的设计概述。接下来，我们将探讨视频搜索及播放部分的设计，即核心部署模型图中标红的部分：

视频搜索引擎会根据用户提交的视频标题、上传用户等元数据，以及视频内容处理器生成的内容标签构建倒排索引。用户搜索时，系统会根据倒排索引检索符合条件的视频，并返回结果列表。结果列表在App端呈现时，会展示视频缩略图，以便用户初步了解视频内容。

用户点击缩略图后，App开始播放视频。无需下载整个视频文件，App以流的方式边下载边播放，确保用户获得流畅的观看体验。QuickTok采用MPEG-DASH流媒体传输协议进行视频流传输，该协议具有自适应能力且支持HTTP，完美满足QuickTok的视频播放需求。

3、详细设计

为解决QuickTok面临的两大挑战：如何存储海量视频文件以及如何解决高并发视频播放导致的带宽压力，我们的详细设计将聚焦于视频存储系统、性能优化与CDN的使用。

此外，“如何生成更吸引用户的缩略图”也是提升短视频应用用户体验的关键问题，因此详细设计还将涵盖缩略图的生成与推荐。

（1）视频存储系统设计

由需求分析可知，QuickTok每年需新增5200PB的存储。面对如此海量的存储需求，“如何存储视频文件”成为QuickTok设计的重要挑战之一。虽然我们可以尝试使用与前述网盘相似的存储技术方案，将视频文件拆分成若干block并使用对象存储服务进行存储，但QuickTok最终选择了另一种方案：使用Hadoop分布式文件系统HDFS进行存储。

HDFS非常适合大文件存储的一次写入多次读取场景，完美契合视频一次上传多次播放的需求。同时，HDFS还能自动进行数据备份（缺省配置下每个文件存储三份），满足我们对数据存储高可用性的要求。

由于HDFS适合存储大文件，大文件能减少磁盘碎片并有利于存储空间的利用，同时减轻HDFS NameNode的访问压力，因此我们需要将若干个视频文件合并成一个HDFS文件进行存储，并将存储细节记录到HBase中。

举例来说，当用户上传一个视频文件时，系统会自动生成一个视频ID（假设为123）。视频内容处理器对视频进行处理后，会调用视频文件存储服务进行存储。存储服务首先通过HDFS创建一个文件（如/data/videos/clust0/p0/000000001），然后将视频数据顺序写入HDFS。写入完成后，存储服务会获取HDFS文件的全路径名、视频在HDFS中的偏移量以及文件大小等信息，并将这些信息记录到HBase中。主键为视频ID（123），value为包含路径、偏移量和大小等信息的字符串。

若另一个用户上传的视频ID为456，文件大小为100,000,000B，且紧随上一个视频文件保存在同一个HDFS文件中，则HBase中会记录主键为456的条目，value为包含该视频在HDFS中的路径、偏移量和大小等信息的字符串。

当用户播放视频456时，播放微服务会根据视频ID在HBase中查找对应条目，获取HDFS文件路径及偏移量等信息，然后从HDFS文件中指定位置开始读取数据，即可获取完整的视频文件数据。

（2）性能优化与CDN设计

如前所述，QuickTok所需的总带宽高达88Tb，这是一个极为庞大的数字。若仅凭QuickTok自己的数据中心来承担这一带宽压力，将面临巨大的技术挑战和成本支出。因此，我们通过CDN将用户的网络通信请求就近返回，以缓解数据中心的带宽压力。

当用户请求获取视频数据流时，App会优先检查附近的CDN中是否有所需视频数据。若有，则直接从CDN加载数据；若无，才会从QuickTok数据中心获取视频数据流。

若用户的大部分请求都能通过CDN得到满足，则一方面能极大加快用户请求的响应速度，另一方面又能有效减轻数据中心的网络和硬盘负载压力，进一步提升应用的整体性能。

通常的CDN设计是在CDN中没有用户请求的数据时进行回源操作，即由CDN请求数据中心返回所需数据并缓存在CDN本地。但QuickTok考虑到了短视频的特点：大V、网红等发布的短视频会被更快速、更广泛地播放。因此，针对粉丝量超过10万的用户，QuickTok系统采用主动推送至CDN的方法以提高CDN命中率并优化用户体验。

从图中可以看出，视频内容处理器在完成视频处理后，一方面会将视频存储到视频存储系统中，另一方面会调用CDN推送服务。CDN推送服务会调用大数据平台获取视频上传者的活跃粉丝数、粉丝分布区域等数据。若用户粉丝量超过10万，则CDN推送服务会根据其粉丝活跃区域将视频推送到对应区域的CDN服务器上。

鉴于短视频的完播率通常不足30%，QuickTok无需将完整视频推送到CDN。相反，我们会根据视频发布者的历史播放记录计算其完播率和播放期望进度，然后将短视频切分成若干chunk，并将部分chunk推送到CDN即可。

业界普遍认为，视频应用CDN处理的带宽占总带宽的95%以上。这意味着通过合理使用CDN，QuickTok数据中心需要处理的带宽压力将降至不到4Tb。

（3）缩略图生成与推荐设计

用户可以在App主页、搜索结果页、视频推荐页等页面看到视频列表，每个视频都配备有缩略图。用户点击缩略图即可开始播放视频。

缩略图通常由视频的某一帧画面缩略而成。事实上，缩略图的选择会极大地影响用户点击和播放视频的意愿。一个10分钟的视频大约包含3万帧画面，那么选择哪一帧画面才能最大化用户点击视频的可能性呢？此外，针对不同用户分类是否选择不同的缩略图会产生更高的点击率呢？

为了解答这些问题，我们需要借助大数据平台的机器学习引擎来完成缩略图的生成和推荐。

缩略图的生成和推荐可以分为两个具体过程：实时在线的缩略图推荐过程a和利用离线机器学习生成优质缩略图的过程b。

在过程a中，用户通过搜索引擎搜索视频后，搜索引擎会生成搜索结果视频列表，并根据视频ID从缩略图存储中获取对应的缩略图。然而，一个视频可能对应多个缩略图。为了显示最吸引当前用户的那个缩略图，搜索引擎需要调用QuickTok大数据平台的缩略图推荐引擎进行推荐。推荐引擎会获取当前用户的偏好特征标签以及视频对应的多个

在过程a中，用户借助搜索引擎寻找视频内容。当搜索引擎呈现出搜索结果视频列表后，它会根据视频ID，从缩略图存储系统中精准地获取对应的缩略图。

然而，值得注意的是，一个视频往往与多个缩略图相关联。为了展示最能吸引当前用户的缩略图，搜索引擎巧妙地调用了QuickTok大数据平台中的缩略图推荐引擎。这一推荐引擎具备强大的功能，它能捕获当前用户的偏好特征标签，同时掌握视频对应的多个缩略图的特征。借助已经通过XGboost算法精心训练的模型，推荐引擎能够精准地将用户特征标签与缩略图特征进行匹配，从而挑选出最可能被当前用户点击的缩略图ID。随后，搜索引擎依据这个ID，将相应的缩略图巧妙地融入搜索结果页面，呈现给用户。

当用户浏览搜索结果列表，并点击某些缩略图进行播放时，App应用会实时地将用户的浏览与点击数据反馈给QuickTok大数据平台，这标志着过程b——利用机器学习生成优质缩略图的开始。

机器学习系统如饥似渴地吸收着海量用户的浏览和点击数据，同时，它也细致地捕捉着每个缩略图的特征。一方面，通过不断学习，机器能够洞察出哪些特征的缩略图更容易赢得用户的点击，进而构建出一个优质缩略图特征标签库；另一方面，机器还能精准地捕捉到每个用户独特的图像偏好特征标签，为之前的推荐引擎提供有力的支持。

有了机器学习系统的强大助力，视频内容处理器便能游刃有余地运用优质特征标签库来处理上传的视频内容。它精准地抽取符合优质特征的帧，进而生成引人入胜的缩略图。

a、b两个过程相辅相成，不断循环迭代，使得优质特征标签库得以持续优化，缩略图也愈发贴合用户的喜好。

那么，在最初缺乏特征库的情况下，我们又该如何应对呢？此时，视频内容处理器会采取一种巧妙的随机策略，抽取一些帧作为缩略图，以此实现冷启动。随后，机器学习系统会从这些随机抽取的缩略图中汲取知识，从而开启循环优化的旅程。

4、总结

在缩略图生成的环节，我们融入了大数据与机器学习的先进技术。对于初次接触的朋友来说，这或许会带来一定的挑战。但如今，人工智能与机器学习已成为众多颇具规模的互联网系统中不可或缺的一部分。作为整个系统的规划者与技术领航者，架构师或许无法深入到算法的每一个细微之处进行优化，但对于算法在整体架构中的核心作用、相关数据的处理流程与传输机制，他们必须了如指掌。只有这样，才能设计出真正贴合业务需求、高效稳健的架构方案。