TOS对象存储
TOS，意为顶级的对象存储(Top Object Storage)，是字节跳动自主研发的一款云原生对象存储系统，下面将从三个阶段介绍这款产品
- 为什么需要对象存储
- TOS的使用方式
- TOS的高级特性
1、为什么需要对象存储
下面以抖音为例，阐述对象存储的必要性。
- 抖音作为现象级的短视频软件，每一分每一秒都在产生大量数据，对数据存储容量大小是以PB乃至EB为计的
- 传统的分布式文件系统对视频，图片等资源支持较差
- 传统分布式文件系统开发，维护较繁杂
- etc..
在需求下，出现了TOS
2、TOS的简单介绍与使用
2.1、TOS简单介绍
-
存储桶：存储桶（bucket）是用户存储对象（Object）的容器，区别于文件系统多层级树形目录结构，存储桶采用扁平化存储方式，桶内所有对象都处于统一逻辑层级。
-
对象：对象（Object）是TOS存储数据的基本单元，本帮助文档中对象、文件、Object均具有相同含义。对象由键(Key)，数据(Data)和元数据(Metadata)三部分组成。
- key：对象名，类似MAP的key
- Data：对象内容，是存储主题
- MetaData：对象的一些元数据，如对象大小、类型，也可自定义 以上介绍来自火山引擎.对象存储
TOS的使用极为简单，一般只要以下几步
2.2、申请bucket
通过厂商提供的云平台，填写申请即可
2.3、使用Restful风格API操作bucket
通过http请求即可操作bucket
-
PUT：修改
- 参数：bucket，key，对象内容
- 返回：成功、失败
-
GET：获取
- 参数：bucket，key
- 返回：对象内容
-
HEAD
- 参数：bucket，key
- 返回：对象元信息
-
DELETE
- 参数：bucket，key
- 返回：成功、失败
2.4、操作优化
-
MultiUpload接口：可以将大文件分解为小文件上传，在网络不稳定情况下优势大
-
InitUpload
- 参数：bucket，key
- 返回：uploadId
-
UploadPart
- 参数：uploadId，partId，part内容
- 返回：成功、失败
-
CompleteUpload
- 参数：uploadId，partId Array
- 返回：成功、失败
-
-
ListPrefix接口：提供分页功能
-
ListPrefix参数:
- prefix: key前缀
- delimiter:分隔符，默认为/
- max-keys :本次分页数量
- start-after: 分页起始对象
-
KeyListPrefix返回:
- common-prefix:共同前缀
- objects: 对象key列表
- isTruncated:是否已经列举完
-
3、TOS实现中的挑战以及解决方案
3.1、分布式
作为一个云原生存储系统，每日都会有大量数据涌入，这便要求TOS有海量数据的存储能力
解决方案：分布式，实现分布式集群，在各个节点均匀存储数据，并且做到能够动态扩容
3.2、持久性与吞吐量
存储介质在长期存储中难免遇到突发情况，导致其不可用，包括但不限于设备老化、机房断电、光缆挖断等
并且在用户请求量大的情况下，需要保持服务的强吞吐能力
解决方案：复制（Replication），为一份文件作多机房多地域副本，可以在一处发生意外时仍能提供服务；并且多服务器让服务的吞吐量得到翻倍提升
3.3、冗余编码
3.2中的复制策略虽然提高了容灾能力，但同时也提升了存储成本
解决方案：冗余编码（Erasure Coding），通过特定的编码方式，即使在文件部分损坏的情况下仍然能恢复完全文件，但是这种方式也会带来计算成本
3.4、温冷转换
互联网上的数据在不同时期有着不同的访问量，当下热点的数据在一个月后可能无人问津
解决方案：温冷转换，将高访问的数据存储在高速度的存储介质中，将低访问的数据存储在高存储的存储介质中
3.5、集群拆分
如果所以系统共用一个集群，那么集群发送故障时，所有功能都会瘫痪
解决方案：集群拆分，将一个集群拆分为多个，在一个集群瘫痪时仍有其它的集群可以提供服务，降低了爆炸半径
3.6、镜像灾备
bucket自身也可能会出现问题
解决方案：镜像灾备，复制一个和原bucket一模一样的备份，同时向外提供服务，当主bucket出现问题时切换备份bucket，待主bucket问题修复时再复原
3.7 展望
TOS仍然有可以针对具体问题改善的地方，需要研发人员进行优化
