一、抖音背后的存储
发 / 刷抖音背后有何流程？背后有何种存储需求？
短视频架构初探
同学小明，进入了互联网顶尖大厂子虚乌有公司工作
某一天领导说，短视频这么火，我们也做一个短视频 APP，这个重担就交给小明你了。
小明：机会来咯，要是做成抖音那样火爆，那升职加薪走向人生巅峰，岂不是分分钟？
小明通过彻夜钻研，终于研究出了如下架构：
客户端肯定需要有一个，然后也要有账号，还要有评论服务；但核心的来说，像抖音这类 APP 都是 UGC，就是用户生产内容的平台，所以重中之重是我们的内容生产到推荐这一条链路。
这一条链路上，会有片源，也就是承接用户上传的内容，然后还有个审核服务，对这些内容进行合规的审核，最后这些内容会根据机器学习打上标签，通过用户历史观看兴趣通过推荐服务推荐到用户的手机上
存储需求
对短视频生产 / 消费链路做更细粒度分解，分成了如图的几个服务，小明发现到处都有视频 / 图片的公共存储需求。
首先第一步是片源服务，将用户上传的视频存起来，用户原始的视频称为源视频。 然后会有转码服务，将源视频转为不同码率的视频。为什么需要转码呢，因为不同的客户端（如不同的手机 / 电脑）型号，能接受的分辨率是不一样的，因此需要转码来适配，转码完后的也需要存储起来，以供后续客户端拉取。然后图下面还有个抽帧服务，将视频抽成不一样的帧，用于审核服务做审核，这里也需要有个存储把这些图片存储起来。最后就是推荐服务了，将对应视频推荐出去，然后客户端就可以来拉取观看啦。
存储需求量细化
小明根据未来可能的用户量，简单做数学计算，发现存储量真是大！！！
单视频假设 10 MB，转码 3 个码率：10 MB，抽帧 20 张图片：1 MB，总计：21 MB，24 个视频 / 图片
1000/S 视频上传：
- Day：1730 TB，20 亿个视频 / 图片
- Month：51900 TB，622 亿个视频 / 图片
- Year：631450 TB，7568 亿个视频 / 图片
一块磁盘 4 TB：
- Day：432 块盘
- Month：12960 块盘
- Year：157680 块盘
寻求天选存储
小明现在的当务之急，是寻找一个合适的存储，要求：
- 海量：从前面分析，这个存储系统一定要能够存储如此大的海量
- 易用：好的存储能够解放业务，让业务专注于业务逻辑开发
- 便宜：这么大的存储量，越便宜就越能省下宝贵的经费
那有没有这样的存储呢？
二、为什么对象存储
存储对比
小明通过之前课程的学习，了解了存储系统的几大分类：
小明回顾之前课程，详细对比了各类存储：
单机存储首先排除，数据量实在太大了，单机肯定存不下，单机数据库同理。
那分布式数据库呢，现代的分布式数据库在容量和弹性上面都有很大进展，是否可以呢？答案也是 No，因为分布式数据库只适合存储结构化 or 半结构化数据。什么是结构化数据呢，就是数据和数据之间有一定关系，如用户信息，一个用户会关联包括电话号码、性别等各种维度的信息，这些信息一般都是不超过 KB 级别的，超过 MB 级别就不适合使用数据库处理了。
唯一的选择就是分布式存储，分布式存储是针对海量存储场景特别设计的存储，能够存储海量的大数据。
分布式存储选型
但分布式存储也有分布式文件系统和对象存储，应该选择哪个呢
易用性：接口对比
刚刚对比还是比较抽象的，我们来更详细的对比 HDFS 和 TOS 的接口。
接口对于任何一种存储来说，都是最重要的表征。为什么呢？因为一种新的存储之所以提出来，是因为它在新场景下解决了其他存储很难解决的问题，针对这类场景提供了新的接口可大幅简化业务逻辑
弱 Posix 文件系统语义：
- 目录 / 文件
- Append 写
- 无法直接 HTTP 访问
接口速览：
- Mkdirs
- Append
- Create
- CreateSymlink
- Delete
- Open
- Get
- ......
Bucket / Object 语义：
- Bucket：存储对象的桶，可类比一个云上的 Map
- Object：对象，包含如下三个部分
- Key：对象的名字，可类比 Map 的 Key
- Data：对象的内容，例如视频 / 图片内容
- MetaData：对象的一些元信息，如对象大小、对象 Content-Type，也可以自定义元信息
HTTP 接口：
- 任何时间、任何地点、任何互联网设备上传和下载数据
- 支持 HTTP 协议的各种客户端都可以访问
接口速览：
- GET：下载对象
- HEAD：查看对象元信息
- PUT：上传信息
- DELETE：删除对象
- .......
适用场景
适用场景：静态、Immutable
- 视频
- 图片
- 文本
- 安装包
- 备份
- 前端 js 文件
- ......
不适用场景：结构化、Mutable
- 关系型数据：商品订单......
- KV：缓存记录......
- 随机写：在线编辑文件......
- Append 写：大数据计算中间结果......
- 更新频繁：钱包余额......
- ......
