06 | 短视频系统设计：如何支持三千万用户同时在线看视频？
该思维导图由 AI 生成，仅供参考
需求分析
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了一款名为QuickTok的短视频应用的需求与技术架构。QuickTok面向全球用户，预计用户总量为20亿，日活用户约10亿，每秒同时在线观看视频的用户数可达3千万。文章详细介绍了系统的需求分析、概要设计和详细设计，包括视频上传、处理、存储、搜索和播放等方面的技术架构。文章还重点介绍了如何存储海量视频文件以及解决高并发视频播放带宽压力的设计方案。 性能优化与CDN设计是其中的关键内容，通过合理使用CDN，QuickTok数据中心需要处理的带宽压力大约4Tb。另外，文章还介绍了缩略图生成与推荐设计，使用大数据和机器学习技术来生成和推荐视频缩略图，以提高用户点击率和播放体验。总体来说，本文提供了一个全面的短视频应用系统设计方案，涵盖了系统的高性能、高可用等关键技术挑战。
《李智慧 · 高并发架构实战课》，新⼈⾸单¥59
全部留言(23)
- 最新
- 精选
Geek2014置顶老师能不能关于某些架构设计多写一些取舍, 让读者知道what，why，how 。就拿这篇举例子的话老师并没有说出网盘海量储存和这次hfds的取舍。只是说了使用hdfs。不然会看起来就只知其然。我想读者可能更需要不仅仅需要抛砖引玉作者回复: 一方面，我们的文章是按设计文档的规范写作的，设计文档一般只描述设计结果，不描述为什么这么设计，否则设计文档就变成一篇论文了，设计文档的目的是为了开发落地实现，不是为了讨论架构的优劣。 另一方面，架构方案很多时候本身也没有优劣之分，几种方案其实都可以，短视频用HDFS或者Ceph这样块存储哪个好？根据公开资料，快手用了HDFS，YouTube早期用了Amazon S3，都可以。 但是，用了不同的技术方案，因为不同技术方案特点不同，相关系统设计也有很大不同，我们这个案例用了HDFS，就要关注文件合并存储，存储格式，索引方式这些问题，文章想展示的也正是这些。 也许我们可以专门写一些文章讲架构方案的取舍，以及取舍后落地实现的差异。大家有什么想法，欢迎一起交流讨论。
2022-03-1219
👽我觉得，推荐算法有这么几个 1 用户习惯。首先应该收集用户历史播放记录，播放时长，完播记录，定位出用户的喜好。算出第一个推荐包。 2 相关视频。有什么和当前视频关联度高的视频。包括，标签相似，点赞该视频的用户点赞的其他视频等。这是第二个推荐包。 3 视频作者。这个跟第一个有点类似。当前视频作者有什么其他作品，有什么类似的视频作者。推荐这些作者的高质量视频。 4当然还会有很多很多其他属性的推荐 接着及后续的用户行为，会进一步更新推荐算法。分别更新对于此用户用户习惯，和整个平台的全局推荐算法的相关权重。 然后根据这个权重再推荐视频，再根据用户行为更新权重，推荐视频，更新权重……无限套娃。 当然，不仅限于此，系统后台还会有任务再学习总结用户习惯。比如给某视频点赞的普遍是什么标签的用户等等。总之就是个无限优化的过程。作者回复: 不错
2022-03-02210
peter请教老师几个问题啊： Q1：视频为什么要进行“转码”处理？ Q2：视频搜索引擎为什么要用“倒排索引”？ Q3：如果手机不支持MPEG-DASH协议怎么办？ 服务器端采用MPEG-DASH协议，但如果手机不支持怎么办？ Q4：视频上传用什么协议？ http吗？ Q5：实际开发中，视频上传/下载用框架还是自己开发？有什么框架？ Q6：合规检查一般怎么做的？ Q7：本例子的成本大约多少？ 带宽费用多少？服务器费用大约多少？视频网站需要大带宽和大量服务器，是不是成本很高啊？本文中的例子，成本估计多少？100亿吗？（写文档需要估算成本，所以请教一下）作者回复: 1 我们这个场景需要进行两种转码，一种是用户上传的不同的视频编码格式需要统一转码成平台格式；一种是转码成不同清晰度的视频文件，根据用户带宽和会员等级进行传输。 2 视频搜索也是按照关键词进行搜索，我们需要按照标题，视频简介等内容进行搜索，本质是文本搜索。 3 手机端是App，是自己开发的，不存在不支持 4 视频上传可以支持多种协议，根据用户网络状况选择 6 AI检查为主，人工检查为辅 7 文中这个例子，支持20亿用户，100亿成本应该是远远不够的
2022-02-2810
neohopeQuickTok其实还有两个很难做的工作要做： 1、视频编解码及压缩：各种格式的视频上传后，需要把各种视频编码转换为同一编码，而且为了适应各种设备及带宽，还需要将视频压缩为多种分别率。这个工作完成后，才会去推送CDN。 2、视频合规性检查：视频内容、音频内容、视频中的文字，也涉及到大量的深度学习训练，并辅助以用户反馈、人工审查等。 视频内容推荐有多种方式： 1、根据视频的推荐：每个视频通过标签转换为向量，推荐时，使用用户当前观看的视频向量，查找类似的视频 2、根据用户的推荐：每个用户的标签转换为向量，先查找匹配类似用户，然后在类似用户中，选择评价好的视频进行推荐 3、根据关注的大V、好友或话题的推荐：大V好友喜欢的主播或视频，通过向量匹配推荐过来。在相同话题下的主播或视频，通过向量匹配推荐过来。 4、全站热门话题推荐；根据所在区域，选择热门话题进行推荐；根据所在行业，选择热门话题进行推荐； 5、广告及推广推荐：根据用户特征，匹配广告潜在用户特征，进行推荐；根据用户近期该兴趣的内容，比如搜索内容，进行推荐； 6、各种推荐算法，用一定比例混合，辅助一些实验性的视频推荐，最后呈现给用户； 7、还要收集用户体验相关信息，不短的对上述模型及标签进行迭代；作者回复: 赞
2022-04-288
ABC老师，有个疑问，视频元数据为什么不考虑ES来存储呢？作者回复: 文中的搜索引擎子系统就是用ES实现的。你的意思是不经过MySQL，数据直接写入ES？这个不合适吧，事务怎么保证，可用性怎么保证？
2022-03-2225
A9文中说到，对于短视频读多于写的这种场景，选择了HDFS进行存储。Ceph和HDFS都是成熟的分布式存储系统，请问这两个一般情况下应该如何抉择呢？作者回复: HDFS适合海量大文件，典型场景：机器学习等大数据场景。 Ceph适合海量中小文件，典型场景：云相册。
2022-03-145
linuxcoder老师，存储时候我们把几个视频文件合并存成一个大概55GB的文件存在HDFS上，那如果遇到删除视频文件，怎么处理？还是删除的时候我们只在元数据进行删除，实际存储在HDFS上的视频文件不删除？作者回复: 是的，不删除物理文件
2022-04-104- 丫丫请问视频一般是压缩的，那么怎么获取缩略图。 怎么存储缩略图，如果一个10min 60hz的4K视频存每一帧来进行分析的话，那么就是4K*36000 = 100M，岂不是很费空间
作者回复: 视频并不是压缩，而是视频文件协议本身就是自带压缩，OpenCV之类的工具可以从视频文件中提取任何一帧的图片，OpenCV也提供缩略图片的函数。 我们不需要把每一帧都存储成缩略图，缩略图的用途是做视频的封面，一张就够了。我们提取多张缩略图是为了推荐引擎挑选最能吸引用户的哪一张，有十几张或者几十张也够了。 另外，4K视频的每一帧图片大概是几M，不是4K，缩略图大概几十K
2022-03-134 
hph老师，短视频和云盘都有一个共同点就是网络带宽要求很高(不考虑CDN)，给用户下载文件的服务器集群面对这么大带宽需求，该如何设计和实现，能说的更详细一些吗，比如服务节点的数量，具体传输是如何做的，传输过程是直接用tcp吗，tcp的话断连续传如何做，短视频一边下载一边播放又是大概怎么做的，等等问题作者回复: CDN提供短视频95%以上的响应带宽，不能不考虑CDN
2022-02-2854
zhaobk老师好，在视频文件存储的时候，为什么要把多个视频文件存储到一个hdfs文件中呢？是因为存储为一个大文件读取速度快吗？这个大文件要控制在多大合适呢?作者回复: 合并一个文件主要是为了减少HDFS block碎片，看下这两个数字：block缺省大小64MB，视频文件不超过100MB。 大文件控制在每秒上传的视频存在一个文件较合适，也就是55GB
2022-03-033
