TOS Object Storage: Fundamentals and Architecture

August 27, 2023 · 12 min read

If you have any questions, feel free to comment below. Click the block can copy the code.
And if you think it's helpful to you, just click on the ads which can support this site. Thanks!

抖音背后的存储 #

• 短视频生产/消费：片源系统->审核系统->推荐系统
• 公共系统：客户端、账号系统、评论系统

处理流程：

1. 手机上传视频到片源服务，片源服务将视频存储。
2. 片源服务将视频发送抽帧服务和转码服务。
3. 抽帧服务将视频抽帧采样并存储。
4. 转码服务将原视频转换为不同清晰度、不同码率的视频并存储。
5. 抽帧后的图片被送往审核服务。
6. 机器或人工审核过后视频被传给推荐服务。
7. 用户可以获取推荐列表或下载推荐视频/图片。

存储量分析：

因此存储要求：易用、海量、便宜。

为什么对象存储 #

存储系统的分类 #

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

这里冷热数据分级存储是指对于冷数据可以将之存储在更加便宜的存储设备上，这样可以降低成本。而热数据（例如热搜视频等等）则可以根据实际访问情况做相应的优化。

分布式存储 #

易用性：接口对比

HDFS #

HDFS 客户端与服务端使用 TCP 私有协议连接。服务端 HDFS 使用树状文件目录，操作命令多，且与目录文件操作息息相关。

弱POSIX文件系统语义：

• 目录/文件
• Append写
• 无法直接HTTP访问

接口速览

• Mkdirs
• Append
• Create
• CreateSymlink
• Delete
• Open
• Get
• ….

对象存储 TOS #

对象存储对外展现一个桶（Bucket）（Bucket 类似与对象存储中的 DB，里面可以放无限多的对象），使用 HTTP 协议 URL：{bucket}.xxx.com/{object}即可访问对象。

Bucket/Object 语义：

• Bucket：存储对象的桶，可类比一个云上的Map
• Object：对象，包含三部分：
  • Key（对象的名字）可类比 Map 的 Key
  • Data（对象的内容，如视频、图片等）
  • MetaData: 对象的一些元信息，如对象大小，对象 Content-Type，也可以存储自定义元信息

HTTP 接口相比 TCP 接口在应用性上有极大的优势：

• HTTP 接口可以在任何时间、任何地点、任何互联网设备上传和下载数据。
• 支持 HTTP 协议的各种客户端都可以访问。

接口速览

• GET: 下载对象
• HEAD: 查看对象元信息
• PUT: 上传对象
• DELETE: 删除对象
• …

适用场景

对象存储主要是大容量的场景。

• 适用于：视频、图片、文本、安装包、备份、前端 js 文件等静态（Immutable）文件。
• 不适用于：关系型数据库（只存储，无法理解关系，难以存储结构化数据）、KV（性能不如 redis）、随机写（只支持静态内容，不支持改写）、Append 写、更新频繁等场景。

对象存储怎么用 #

1. 申请 bucket
2. 业务逻辑开发（视频上传、视频下载、视频删除、视频查看）
3. 上线测试（拍一条视频，给自己的视频点赞等等）

申请bucket

对象存储很多云厂商都支持，此处介绍字节的TOS。

构建bucket名称。数据描述（数据类别、数据访问级别、保密级别等。用于系统审计）。填写吞吐需求。提交。

restful 接口

对象存储对外提供的一般都是 Restful 风格的接口。（竖着看每列参数）

MultiUpload接口

防止大对象上传失败：将大对象分为小对象，标上每个小对象的 uploadID，然后分开上传，最后合并即可。

Listprefix接口（分页查询）

参数：

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

TOS 字节内部实践 #

三层架构 #

• 接入层：接入解析并处理接口请求，解析HTTP、安全校验等。
• 元信息层：存储对象元信息。
• 存储引擎层：存储对象内容。

总结业务场景 #

经典业务场景分为容量型和QPS型。

容量型 #

代表业务

• 片源: 用户上传源视频
• 转码: 源文件转码后的视频（为了适配不同的客户端，因此需要转换不同的码率） 特点
• 容量: 海量 >EB
• 吞吐: 海量 »100 GB/S
• 高持久度: 用户视频不能丢 挑战
• 可扩展性: 容量/吞吐需可线性扩展
• 成本: 单位存储成本需要足够低
• 持久度: 如何在保证成本的情况下，确保高持久度

QPS 型 #

代表业务：

• 审核抽帧存储 特点：
• QPS 极高 » 100 K/s 挑战：
• QPS 需可扩展性。

问题解决 #

可拓展性解法Partition #

分布式存储：

• 存储均匀分布
• 计算均匀分布
• 压力均匀分布 分布式系统相当于一个蜂群，每个节点都负责一小部分数据存储和计算，达到 1+1 >=2 的效果。

Partition (分而治之)

• 分而治之: 不同数据映射至不同 Partition 分区
• Partition Logic: Hash/Range 可扩展性如何达成
• 数据量增加: 扩容机器新建 Partition
• Parition Logic: 新增数据写入映射导向新 Partition

持久度解法 Replication #

持久度的敌人: 不可靠的种种因素

• 不可靠的软件/硬件
• 自然灾害
• 太阳黑子等等

复制 (Replication)

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

成本解法之 EC 与冷热转换 #

单纯多副本拷贝成本也非常高

EC（Erasure Coding）冗余编码，用更少的空间达到多副本一样的持久度。降低成本，但是也增加了额外的编码计算。

冷热转换：将热点存在快而小的存储介质中，冷数据存于大而慢的磁盘中。

架构细化 #

每一层的介绍在右侧：

存储需求量细化 要求超高的可用性：

• SLA：99.999% 服务在一年内只能 5 分钟不可用
• RPO：出现不可用后数据不一致的时间仅能 1 分钟
• RTO：出现不可用后数据需要在 5 分钟内修复可用

高可用 #

• 集群拆分，降低爆炸半径（机房故障后，不可用机器的占比）。
• 增量双向同步（所有机器记录增量，把增量更改传给其它机器，例如粤合算）。
• 镜像灾备：完全镜像的主备 Bucket，出现问题随时切换。