TOS对象存储实战
1 抖音背后的存储
1.1 短视频架构初探
1.2 存储需求
把短视频生产/消费链路做更细粒度分解，到处都有视频/图片的公共存储需求
1.3 存储需求量细化
根据未来可能的用户量，简单计算，发现存储量真大
Day
1730TB 432块4TB磁盘 20亿个视频/图片
Month
51900TB 12960块4TB磁盘 622亿个视频/图片
Year
631450TB 157680块4TB磁盘 7568亿个视频/图片
1.4 寻找天选存储
要求：易用、海量、便宜
2 为什么需要对象存储
2.1 存储系统的分类
单机存储：文件系统，key-value存储
单机数据库：关系型数据库，非关系型数据库
分布式数据库：关系型数据库，非关系型数据库
分布式存储：分布式文件系统，对象存储
2.2 存储对比
2.3 分布式存储选型
| 海量 | 易用 | 便宜 | |
|---|---|---|---|
| 分布式文件系统HDFS | 支持PB—>EB海量存储 文件数量受Name Node限制 | 伪Posix文件接口，开发略复杂 非云原生，搭建维护较麻烦 视频/图片相关生态接入略复杂 | 使用普通X86服务器，成本低 |
| 对象存储TOS | 支持>EB海量存储 对象数量无限制 | Restful HTTP接口，开发极简单 云原生，按需申请使用 视频/图片相关生态丰富 | 使用普通X86服务器 具备冷热数据分级存储能力，成本更低 |
2.4 易用性：接口对比
弱Posix文件系统语义
- 目录/文件
- Append写
- 无法直接HTTP访问
接口速览
- Mkdirs
- Append
- Create
- CreateSymlink
- Delete
- Open
- Get
Bucket/Object语义
- Bucket：存储对象的桶
- Object：对象，包含如下三个部分
- Key：对象的名字，可类比Map的Key
- Data：对象的内容，例如视频/图片内容
- MetaData：对象的一些元信息，如对象大小，对象Content-Type，也可以存储自定义元信息
HTTP接口
- 任何时间、任何地点、任何互联网设备上传和下载数据
- 支持HTTP协议的各种客户端都可访问
接口速览
- GET：下载对象
- HEAD：查看对象元信息
- PUT：上传对象
- DELETE：删除对象
2.5 适用场景
视频、图片、文本、安装包、备份、前端js文件……
静态、Immutable
关系型数据：商品订单；KV:缓存记录；随机写：在线编辑文件；Append写：大数据计算中间结果；更新频繁：钱包余额......
结构化、Mutable
3 对象存储怎么用
3.1 对象存储的用法
- 申请Bucket
- 业务逻辑开发
- 视频上传
- 视频下载
- 视频删除
- 视频查看
- 上线测试
- 拍一条视频
- 给自己的视频点赞
3.2 申请Bucket
3.3 Restful 接口
PUT：
- 参数：Bucket, Key, 对象内容
- 返回：成功/失败
GET：
- 参数：Bucket, Key
- 返回：对象内容
HEAD：Lite版GET
- 参数：Bucket, Key
- 返回：对象元信息，如大小/Content—Type等
DELETE：
- 参数：Bucket, Key
- 返回：成功/失败
3.4 Restful 接口演示
3.5 MultiUpload 接口
InitUpload：
- 参数：Bucket, Key
- 返回：Uploadld
UploadPart：
- 参数：Uploadld, Partld, Part内容
- 返回：成功/失败
CompleteUpload：
- 参数：Uploadld, Partld Array
- 返回：成功/失败
3.6 Listprefix 接口
ListPrefix参数：
- prefix：key前缀
- delimiter：分隔符，默认为/
- max- keys：本次分页数量
- start- after：分页起始对象Key
ListPrefix返回:
- common-prefix：共同前缀
- objects：对象key列表
- isTruncated：是否已经列举完
4 TOS字节内部实践
4.1 开发一个对象存储
4.1.1 经典三层架构
- 接入层：接入解析并处理接口请求
- 元信息层：存储对象元信息
- 存储引擎层：存储对象内容
4.1.2 当前经典业务场景
- 容量型
代表业务
- 片源：用户上传源视频
- 转码：源文件转码后的视频
特点
- 容量：海量，> EB
- 吞吐：海量，>> 100GB/S
- 高持久度：用户视频不能丢
挑战
-
可扩展性：容量/吞吐需可线性扩展
-
成本：单位存储成本需要足够低
-
持久度：如何在保证成本的情况下，确保高持久度
-
QPS型
代表业务
- 抽帧：源视频审核用抽帧
特点
- QPS：极高，100K/s
挑战
- 可扩展性：QPS需可线性扩展
4.3 可扩展性解法之Partition
分布式存储=分布式+单机存储
分布式：
- 存储均匀分布
- 计算均匀分布
- 压力均匀分布
分布式系统相当于一个蜂群，每个节点都负责小部分数据存储和计算，达到1+1 >= 2的效果
4.4 可扩展性解法之Partitor
Partition (分而治之)
- 分而治之：不同数据映射至不同Partition分区
- Partition Logic：Hash/Range
可扩展性如何达成
- 数据量增加：扩容机器新建Partition
- Parition Logic：新增数据写入映射导向新Partition
4.5 持久度解法之Replication
持久度的敌人：不可靠的一切
- 不可靠的硬件
- 不可靠的软件
- 自然灾害
- 甚至是太阳黑子
数据单节点存储，一定有较大概率丢失无法找回
4.6 持久度解法之Replicatior
复制(Replication)
- 数据复制多份，即多个副本
- 副本放置策略:
- 多机架：可抵抗机架级别故障
- 多机房：可抵抗机房级别故障
- 多Region：可抵抗Region级别故障
带来
- 高持久度：不丢数据
- 强吞吐能力：多个副本可以提供服务
4.7 成本解法之EC
Replication虽然可以解决持久度问题，但是单纯多副本拷贝成本也非常高
EC (Erasure Coding)
- 冗余编码：可达到和多副本一样的持久度
特点
- 低冗余度：成本较单纯多副本低
- 额外计算：增加了额外的编码计算步骤
4.8 成本解法之温冷转换
4.9 架构细化
API：接入层
Bucket Meta：Bucket元信息服务
Object Meta：对象元信息服务
Distributed KV：Range Partition的分布式KV，用于持久化对象元数据
Storage Engine：对象内容存取服务
Distributed Storage Pool：分布式存储池，三副本 or EC存储
GC：垃圾回收后台服务
Lifecycle：温冷转换后台服务
4.10 高可用解法之拆分降低爆炸半径
首先想到的就是，一个集群拆分成多个集群，有效降低爆炸半径
4.11 高可用之粤核酸的启发
但对于很多业务，例如飞书等，是希望无论何种情况都保证服务可用
4.12 高可用之镜像灾备
完全镜像的主备Bucket,出现问题随时切换，真正100%的可用性
4.13 未来展望
5.总结
- 现代互联网应用存在普遍的视频/图片等静态内容的海量存储需求
- 对象存储以其极佳海量存储能力，低廉成本，易用性，成为这类场景的不二之选
- 对象存储的数据模型：Bucket/Object，基本接口 Put/Get/Head/Delete，高阶接口 MultiUpload/ListPrefix
- 对象存储工程上的挑战和解法:
- 可扩展性：Partition
- 持久度：Replication
- 成本：EC/温冷转换
- 可用性：集群拆分/镜像灾备
