这是我参与「第三届青训营 -后端场」笔记创作活动的的第11篇笔记

01 抖音背后的存储

1.1存储需求

1.2 存储需求量细化

DAY

1730TB
432快4TB磁盘
20亿的视频/图片 MONTH
51900TB
12960块4TB磁盘
622亿个视频/图片 YEAR
631450TB
157680块4TB磁盘
7568亿个视频/图片存储量很大

1.3 天选存储

需要找到一种支持海量、易用、便宜的存储系统

02 为什么对象存储

2.1 存储对比

2.2 易用性：接口对比

Bucket/object语义
bucket：存储对象的桶，可以类比云上的map
Object：对象，包含三个部分
key：对象的名字，可类比map中的key
data：对象的内容，例如视频/图片
metadata：对象的一些元信息，例如对象的大小，对象的内容类型，也可以存储自定义元信息 HTTP接口
任何时间、任何地点、任何互联网设备下载和上传数据
直接HTTP协议的各种客户端都可以访问接口速览
GET:下载对象
HEAD:查看对象元信息
PUT:上传对象
DELETE:删除对象

2.3 适用场景

静态、immutable

视频
图片
文本
安装包
备份
前端js文件

03 对象存储怎么用

graph TD
申请bucket --> 业务逻辑开发 --> 上线测试

3.1 申请bucket

3.2 restful接口

PUT:

参数：bucket，key，对象内容
返回：成功/失败 GET:
参数：bucket，key
返回：对象内容 HEAD:
参数：bucket，key
返回：对象元信息，大小/content-type等 DELETE:
参数：bucket，key
返回：成功/失败

3.3 multiupload接口

适用场景：当上传数GB的大视频的时候由于网络不好，总是上传到99%就卡住了解决方案: multiupload

initupload

参数：bucket，key
返回：upload uploadpart
参数：uploadid，partid，part内容
返回：成功/失败 completeupload
参数：upload，partid array
返回：成功/失败

3.4 listprefix接口

listprefix参数：

prefix：key前缀
delimiter:分隔符，默认为/
max-keys:本次分页数量
start-after:分页起始对象key

listprefix返回：

common-prefix:共同前缀
objects:对象key列表
isTruncated:是否已经列举完

04 TOS字节内部实践

4.1 开发一个对象存储

接入层：接入解析并处理接口请求
元信息层：存储对象元信息
存储引擎层：存储对象内容不同的业务场景有不同的需求

容量型代表业务

片源：用户上传视频
转码：源文件转码后的视频特点
容量海量
吞吐海量
高持久度挑战
可扩展性：容量/吞吐可线性扩展
成本：单位存储成本需要足够低
持久度：高持久度

QPS型代表业务

抽帧：源视频审核用抽帧特点
QPS:极高挑战
可扩展性：QPS可按需线性扩展

4.2 可扩展性解法之Partition

分布式存储= 分布式 + 单机存储分布式：

存储均匀分布
计算均匀分布
压力均匀分布

partiton(分而治之)

分而治之：不同数据映射至不同的partition分区
partition logic：hash/range 可扩展性如何达成数据量增加：扩容机器新建partition partion logic:新增数据写入映射导入新partition

思考

hash/range方式优劣？一致性哈希比较好，range比较僵硬，不灵活
各partition之间如何负载均衡呢？可以按照已有的数据与还能存储的数据之比进行一个动态的权重安排

4.3 持久度解法之replication

复制

数据复制多份，即多副本
副本防止策略：多机架、多机房、多region 好处高持久度：不丢数据强吞吐能力：多个副本可以提供服务思考 replication的拷贝方式有哪些？主从一致 replication如何解决一致性问题？ raft、paxos

4.4 成本解法之ec

EC(erasure coding) 冗余编码：可达到和多副本一样的持久度特点

低冗余度：成本较单纯多副本低
额外计算：增加了额外的编码计算步骤思考
当前的EC编码有哪些？
多机房的EC如何实现？

4.5 成本解法之冷热转换

数据是有温度的，将冷数据转移到性能更差但更廉价的存储介质可以大大减少成本

4.6 高可用解法之拆分降低爆炸半径

将一个集群拆分为多个集群

TOS对象存储实战 | 青训营笔记