这是我参与「第三届青训营 -后端场」笔记创作活动的的第6篇笔记。 主要介绍TOS对象存储的相关知识，包括对象存储系统的架构、对象存储的适用场景、对象存储的使用。

一 抖音背后的存储

短视频架构
片源系统 -> (送审) -> 审核系统 -> (放出) -> 推荐系统

1 上传到片源系统，需要存储源视频
2 在送审阶段，抽帧机审，需要存储抽帧图片
3 放出阶段，转成不同码率的视频，需要存储不同码率的视频

特点：存储量大
存储要求：易用、便宜、海量

二 对象存储的由来

• 存储分类和选择对比

分类

单机存储：文件系统、key-value存储
单机数据库：关系型数据库、非关系型数据库
分布式数据库：关系型数据库、非关系型数据库
分布式存储：分布式文件系统、分布式对象存储

对比
单机存储/数据库不支持海量存储
分布式数据库支持海量存储，但是存储结构化数据，对单个数据大小有限制，一般只处理kb级别数据
分布式对象存储支持海量存储，数据个数和数据大小都无限制，且支持冷热数据转换，适合选用

• HDFS和TOS

HDFS：弱posix文件系统语义

    目录/文件
    append写
    无法直接http访问
接口：Mkdirs、Append、Create、CreateSymlink、Delete、Open、Get...

TOS：Bucket/Object语义
Bucket：存储对象的桶，类比map
Object：对象，包含key、data、metadata三个部分
    Key：对象的名字，类比map的key
    Data：对象的内容，视频、图片等
    Metadata：对象的一些元信息，如对象大小，对象内容类型，自定义元信息等
    
    
接口：http接口
任何时间、任何地点、任何互联网设备上传和下载数据
支持http协议的各种客户端都可访问

• TOS应用场景

对象存储适用场景：静态数据、immutable

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

对象存储不适用场景：结构化、mutable
关系型数据、kv、随机写、append写、更新频繁...

三 对象存储的使用

• Restful代码风格

GET：下载对象

HEAD：查看对象元信息
PUT：上传对象
DELETE：删除对象

• MultiUpload接口

弱网环境下，上传大对象分而治之

InitUpload
参数：Bucket，Key
返回：UploadId

UploadPart
参数：UploadId，PartId，Part内容
返回：成功/失败

CompleteUpload
参数：UploadId，PartId Array
返回：成功/失败

• ListPrefix接口

一个Bucket可以存储无限多对象，查看Bucket中的对象，分页列举

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

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

四 字节对象存储实践

4.1 TOS 架构

自研对象存储系统：元信息层 <- 接入层 -> 存储引擎层
接入层：接入解析并处理接口请求
元信息层：存储对象元信息
存储引擎层：存储对象内容

4.2 业务场景

• 容量型

代表业务

片源：用户上传视频
转码：源文件转码后的视频

特点
容量：海量， >> EB
吞吐：海量， >> 100GB/s
高持久度：用户视频不能丢

挑战
可扩展性：容量/吞吐需要可线性扩展
成本：单位存储成本需要足够低
持久度：在保证成本的情况下，确保高持久度

• QPS型

代表业务

抽帧：源视频审核抽帧

特点
QPS：极高，>> 100k/s

挑战
可扩展性：QPS需要可线性扩展

4.3 解决方案

• 可扩展性解决方案-Partition

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

1 存储均匀分布
2 计算均匀分布
3 压力均匀分布

Partition
分而治之：不同数据映射至不同Partition分区
Partition Logic：hash/range(保持原有顺序，如keyw为a-d开头的映射到1，e-j开头映射到2...)

可扩展性
数据量增加：扩容机器新建Partition
Partition Logic：新增数据写入映射导向新Partition

思考
Hash/Range优劣？
各Partition如何负载均衡？

• 持久度解决方案-Replication

持久度的敌人

1 不可靠的硬件
2 不可靠的软件
3 自然灾害
4 太阳黑子

数据单节点存储，一定有较大概率丢失无法找回

Replication
数据复制多份，即多个副本
副本放置策略
    多机架：可抵抗机架级别故障
    多机房：可抵抗机房级别故障
    多Region：可抵抗Region级别故障
    
优点  
1 高持久度：不丢数据
2 强吞吐能力：多个副本提供服务

思考
1 拷贝方式有哪些？
2 如何解决一致性问题？

• 成本解决方案-EC编码 & 数据温冷转换

EC：冗余编码，可达到和多副本一样的持久度

特点
1 低冗余度：成本比单纯多副本低
2 额外计算：增加了额外的编码计算步骤

思考
1 当前EC算法？
2 多机房EC？

数据温冷转换
将冷数据转移到性能更差但更廉价的存储介质

• 高可用性解决方案-集群拆分

SLA：99.999%，正常服务时间的百分比，即服务一年最多5分钟不可用

RPO：出现故障后，容忍的数据丢失量
RTO：5分钟，出现不可用后，多久可以恢复

一个集群拆分为多个集群，有效降低爆炸半径
完全镜像的主备Bucket，出现问题随时切换，真正100%的可用性

五 未来展望

1 容量治理
2 成本优化
3 大数据生态
4 稳定性提升