抖音背后的存储

短视频生产/消费架构

我们关注抖音短视频服务中的生产/消费链路。
抖音短视频服务由片源系统、审核系统、推荐系统按照下图流程依次运行。

graph LR
片源系统 --> 审核系统 --> 推荐系统

• 片源系统：用于用户上传视频，并对视频进行相应的处理。
• 审核系统：用于人工或机器审核视频内容，确保视频内容符合规范。
• 推荐系统：将审核通过的视频按照用户喜好进行推送。

将其中的片源系统进一步细化分析其存储需求

1. 片源系统：存储原始视频。
2. 片源系统到审核系统：将视频抽帧为图片并存储，减少审核成本。
3. 片源系统到推荐系统：存储不同码率的视频，满足用户选择的需求。

我们可以发现在短视频服务架构中随处都存在着存储的需求，并且随着用户量的提升、业务的发展存储需求量将会大量增长，存储成本也会相应提高。
因此，抖音短视频服务需要有一个能够同时满足海量、易用并且便宜的存储系统。

为什么需要对象存储

主流存储系统

首先，我们需要比较各类主流的存储系统，并从中选出最符合存储需求的。

有哪些

• 单机存储
  • 文件系统：APFS、NTFS等操作系统中使用的文件系统。
  • Key-Value存储：XML、JSON等数据组织形式。
• 单机数据库（单服务器）
  • 关系型数据库：MySQL等
  • 非关系型数据库：Redis等
• 分布式数据库（服务器集群）
  • 关系型数据库
  • 非关系型数据库
• 分布式存储
  • 分布式文件系统：HDFS
  • 对象存储：TOS

横向对比

我们从数据承载力和适合的数据类型两个方面比较主流的存储系统。

1. 数据承载力
   由于单机存储和单机数据库均采用单个主机，无法承载海量数据的存储，因此我们选择分布式集群的组织形式。
2. 适合的数据类型
   由于数据库主要存储（半）结构化的数据，比如表、属性等，而短视频服务需要在存储系统中大量存取视频、图片、音乐等这类超文本，非结构化的数据，因此也不能选择分布式数据库。

所以我们选用分布式存储这一存储形式。

分布式文件系统 VS 对象存储

特点对比

我们先从海量、易用、便宜三个维度对两者进行分析。

1. 海量

• HDFS：文件数量受到Node的限制
• 对象存储：对象数量无限制
  对象存储能够做到真正的海量级存储

2. 便宜
   均可使用普通服务器进行存储，但是对象存储具有冷热数据分级存储的功能，成本可以更加低廉。
3. 易用

• HDFS：
  • 文件接口，开发复杂
  • 非云原生，服务搭建复杂
  • 视频、图片等接入复杂
• 对象存储：
  • 使用HTTP接口，开发简单
  • 云原生，可直接开放服务
  • 视频、图片等接入简易

由此可见，对象存储对于网络应用服务的支持更加丰富、更加方便。

接口对比

分布式文件系统

语义：文件系统语义

• 组织结构采用目录和文件
• 使用Append追加写入
• 通过TCP私有协议访问，非应用层直接访问

接口：类似操作系统中的文件系统

对象存储

使用Bucket和Object组织对象

• Bucket：存储对象的桶，类似数据库中的db
• Object：对象
  • Key：对象的名字
  • Data：对象的内容
  • MetaData：元信息，对象大小等描述信息

使用HTTP接口：原生支持云应用，使用URL即可操作任何对象

接口：支持CRUD

• GET：获取对象
• HEAD：获取对象元信息
• PUT：上传对象
• DELETE：删除对象

因此，对于短视频服务这类网络应用层的服务我们应该使用对象存储作为其存储的中间件，不仅能够满足海量、易用和便宜的三种需求，并且能够满足短视频这类超文本、非结构化的内容的存储需求。而对对象存储的深入理解是学习后端所必须的。

对象存储适用场景

适用：静态资源（不可变）

视频、图片、文本、前端js文件等资源

不适用：结构化资源（可变）

关系型数据、KV对、随机写入、追加写、频繁更新等资源