TOS对象存储实战
抖音背后的存储
发/刷抖音背后有何流程？背后有何种存储需求？
短视频架构
客户端我们肯定需要有一个，然后也要有账号，也要有评论服务。但核心的来说，向抖音这类APP都是UGC，就是用户生产内容的平台，所以重中之重我们的内容生产到推荐这一条链路； 这一条链路上，会有片源，也就是承接用户上传的内容，然后还有个审核服务，对这些内容进行合规的审核，最后这些内容会根据机器学习打上标签，通过各位同学历史观看兴趣通过推荐服务推荐到各位同学的手机上
存储需求
把短视频生产/消费链路做更细粒度分解，有视频/图片的公共存储需求。
对短视频生产/消费链路做了更细粒度分解，分成了如图的几个服务。
- 第1步是片源服务，将用户上传的视频存起来，这个用户原始的视频我们叫源视频；
- 然后会有转码服务，将源视频转为不同码率的视频，为什么需要转码呢，因为不同的客户端（如不同的手机/电脑）型号，能接受的分辨率是不一样的，因此需要转码来适配，这里转码完后的也需要存储起来，以供后续客户端拉取；
- 然后图下面还有个抽帧服务，将视频抽成不一样的帧，用于审核服务做审核，这里也需要有个存储把这些图片存储起来；
- 最后就是推荐服务了，将对应视频推荐出去，然后客户端就可以来拉取观看啦；
存储需求量细化
根据未来可能的用户量，简单做数学计算，发现存储量很大：
单视频假设10MB：
- 转码3个码率：10MB
- 抽帧20张图片：1MB
- 总计：21MB，24个视频/图片
1000/S视频上传：
- Day：1730TB, 20亿个视频/图片
- Month：51900TB, 622亿个视频/图片
- Year：631450TB, 7568亿个视频/图片
一块磁盘4TB：
- Day： 432块盘
- Month：12960块盘
- Year：157680块盘
寻找天选存储
寻找一个合适的存储方案，要求：
- 海量：从前面分析，这个存储系统一定要能够存储如此大的海量
- 易用：好的存储能够解放业务，让业务专注于业务逻辑开发
- 便宜：这么大的存储量，越便宜就越能省下宝贵的经费
为什么使用对象存储
存储对比：
这里详细类比了各类存储。单机存储我们先排除，数据量实在是太大了，单机肯定存不下，单机数据库同理。
那分布式数据库呢，现代的分布式数据库在容量和弹性上面都有很大进展，是否可以呢？答案也是No，因为分布式数据库只适合存储结构化or半结构化的小数据。
什么是结构化数据呢，就是数据和数据之间有一定关系，如用户信息，一个用户会关联包括电话号码，性别等各种维度的信息，这些信息一般都是不超过KB级别的，超过MB级别就不适合使用数据库处理了；
唯一的选择就是分布式存储，分布式存储是针对海量存储场景特别设计的存储，能够存储海量的大数据；
分布式存储选型
但分布式存储也有分布式文件系统和对象存储，应该选择哪个呢?
易用性：接口对比
刚刚对比还是比较抽象的，我们来更详细的对比HDFS和TOS的接口。
接口对于任何一种存储来说，都是最重要的表征，为什么呢，因为一种新的存储之所以提出来，是因为它在新场景下解决了其他存储很难解决的问题，针对这类场景提供了新的接口可大幅简化业务逻辑。
Bucket/Object语义
-
Bucket：存储对象的桶，可类比一个云上的Map
-
Object：对象，包含如下三个部分
- Key：对象的名字，可类比Map的Key
- Data：对象的内容，例如视频/图片内容
- MetaData：对象的一些元信息，如对象大小，对象Content-Type,也可以存储自定义元信息
HTTP接口
- 任何时间、任何地点、任何互联网设备上传和下载数据
- 支持HTTP协议的各种客户端都可访问
接口：
- GET：下载对象
- HEAD：查看对象元信息
- PUT：上传对象
- DELETE：删除对象
- …
场景
对象存储使用
申请Bucket
Restful接口
对象存储对外提供的一般都是Restful风格的接口。
了解对象存储PUT/GET/HEAD/DELETE接口的基本使用
MultiUpload接口
上传数GB的大视频时，由于网络不好，总是上传到99%就网络卡住了，解决此场景的闪电三连鞭：MultiUpload
分页列举：Listprefix接口
把上传/下载/删除对象存储等基本场景搞定后，但是想看看桶里面有哪些对象：分页列举接口: ListPrefix
ListPrefix接口是用于查看桶下面有哪些对象，它是一个分页接口，循环调用该接口可以遍历桶下面所有对象
TOS字节内部实践
开发一个对象存储
数据量大了，自研对象存储，这个重任又交给了小明。小明很快想出了一个经典的三层架构：
- 接入层：接入解析并处理接口请求
- 元信息层：存储对象元信息
- 存储引擎层：存储对象内容
架构如何细化：
可扩展性解法之Partition
分布式存储 = 分布式 + 单机存储：
分布式：
- 存储均匀分布
- 计算均匀分布
- 压力均匀分布
分布式系统相当于一个蜂群，每个节点都负责一小部分数据存储和计算，达到1+1>=2的效果
持久度解法之Replication
range：key
复制(Replication) ：
-
数据复制多份，即多个副本
-
副本放置策略:
- 多机架：可抵抗机架级别故障 多机房：可抵抗机房级别故障
- 多Region：可抵抗Region级别故障
带来
- 高持久度：不丢数据
- 强吞吐能力：多个副本可以提供服务
思考
- Replication的拷贝方式有哪些?
- Replication如何解决一致性问题?
成本解法之EC
Replication虽然可以解决持久度问题，但是单纯多副本拷贝成本也非常高！
EC (Erasure Coding 纠删码)
- 冗余编码：可达到和多副本一样的持久度
特点
- 低冗余度：成本较单纯多副本低
- 额外计算：增加了额外的编码计算步骤
思考
- 当前的EC编码算法有哪些?
- 多机房的EC如何实现?
成本解法之温冷转换
数据都是有温度的，将冷数据转移到性能更差但更廉价的存储介质不就可以省下来成本么?
光盘？
架构细化
API：接入层
- Bucket Meta： Bucket元信息服务
- Object Meta：对象元信息服务
- Distributed KV： Range Partition的分布式KV，用于持久化对象元数据
- Storage Engine：对象内容存取服务
- Distributed Storage Pool：分布式存储池，三副本or EC存储
- GC：垃圾回收后台服务
- Lifecycle：温冷转换后台服务
存储需求细化
公司其他业务也想使用，但是他们的要求不一样:超高的可用性!
高可用解法之拆分降低爆炸半径
首先想到的就是，一个集群拆分成多个集群，有效降低爆炸半径
高可用之镜像灾备
高可用之粤核酸的启发
但对于很多业务，例如飞书等，是希望无论情况，都保证服务可用，那应该怎么办呢?
完全镜像的主备Bucket,出现问题随时切换，真正100%的可用性！
