TOS对象存储实战 | 青训营

玛奇玛1005
34 阅读7分钟

一、抖音背后的存储

1、短视频架构初探

通过仔细思考，设计了一个架构：

客户端我们肯定需要有一个，然后也要有账号，也要有评论服务；

但核心的来说，像抖音这类APP都是UGC，就是用户生产内容的平台，所以重中之重我们的内容生产到推荐这一条链路；这一条链路上，会有片源，也就是承接用户上传的内容，然后还有个审核服务，对这些内容进行合规的审核，最后这些内容会根据机器学习打上标签，通过各位同学历史观看兴趣通过推荐服务推荐到各位同学的手机上。

image.png

2、存储需求

把短视频生产/消费链路做更细粒度分解，小明发现到处都有视频/图片的公共存储需求。

  • 第一步是片源服务，将用户上传的视频存起来，这个用户原始的视频我们叫源视频；
  • 然后会有转码服务，将源视频转为不同码率的视频。因为不同的客户端能够接受的分辨率是不一样的，因此需要转码来适配。转码完后的也需要存储起来，以便后续客户端拉取；
  • 抽帧服务是将视频抽成不一样的帧，用于审核服务做审核，这里也需要把这些图片存储起来；
  • 最后来到推荐服务，将对应视频推荐出去，然后客户端就可以拉取观看了。

image.png

3、存储需求量细化

小明根据未来可能的用户量，简单做数学计算，发现存储量真的大。

假设一个视频10MB：

  • 转码3个码率：10MB；
  • 抽帧20张图片：1MB；
  • 总计21MB，24个视频/图片

1000/s视频上传：

  • Day：1730TB，20亿个视频/图片
  • Month:51900TB,622亿个视频/图片
  • Year：631450TB，7568亿个视频/图片

一块磁盘4TB：

  • Day：432块盘
  • Month：12960块盘
  • Year：157680块盘

image.png

4、寻找天选存储

image.png

二、为什么对象存储

1、存储种类

image.png

2、存储对比

image.png

单机存储先排除，因为数据量实在太大了，单机肯定存不下，单机数据库同理。

现代的分布式数据库在容量和弹性方面都有很大进展，但是分布式数据库只适合存储结构化或半结构化的数据。

【注】结构化数据：数据和数据之间有一定关系，比如用户信息，一个用户会关联包括电话号码、性别等各种维度的信息，这些信息一般不超过KB级别，超过MB级别的就不适合使用数据库处理了。

因此，唯一选择是分布式存储。分布式存储时针对海量存储特别设计的存储，能够存储海量数据。

4、分布式存储选型

但分布式存储也有分布式文件系统和对象存储，应该选择哪个呢?

image.png

5、易用性：接口对比

接口对于任何一种存储来说都是最重要的表征，因为一种新的存储之所以提出来，是因为它在新场景下解决了其他存储很难解决的问题，针对这类场景提供了新的接口可以大幅简化业务逻辑。

Bucket/Object语义：

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

HTTP接口：

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

接口速览：

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

image.png image.png

6、适用场景

image.png

三、对象存储怎么用

image.png

1、Restful接口

申请完Bucket后，要开启开发，了解到对象存储对外提供的一般都是Restful风格的接口。

image.png

了解对象存储PUT/GET/HEAD/DELETE接口的基本使用。

image.png

2、MultiUpload接口

随着开发的深入，小明发现一个问题，自己上传数GB的大视频时，由于网络不好，总是上传到99%就网络卡住了，他很恼火，翻遍对象存储各类手册，终于发现了一个解决此场景的闪电三连鞭：MultiUpload。

image.png

3、分页列举：Listprefix接口

把上传/下载/删除对象存储等基本场景搞定后，但是想看看桶里面有哪些对象，这时候他又犯难了，继续翻遍开发手册后，他发现了一个分页列举接口: ListPrefix。

ListPrefix接口是用于查看桶下面有哪些对象，它是一个分页接口，循环调用该接口可以遍历桶下面所有对象。

image.png

四、TOS字节内部实践

短视频应用上线后，大获成功，对象存储在公有云的使用量特别大，数据量大了，领导决定自研对象存储，这个重任又交给了小明。小明很快想出了一个经典的三层架构：

  • 接入层：接入解析并处理接口请求
  • 元信息层：存储对象元信息
  • 存储引擎层：存储对象内容

image.png

1、开发一个对象存储

image.png

2、可扩展解法之Partition

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

分布式：

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

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

image.png

image.png

3、持久度算法之Replication

复制：

  • 数据复制多份，即多个副本
  • 副本放置策略：
    • 多机架：可抵抗机架级别故障
    • 多机房：可抵抗机房级别故障
    • 多Region:可抵抗Region级别故障

带来：

  • 高持久度：不丢数据
  • 强吞吐能力：多个副本可以提供服务

image.png

image.png

4、成本解法之EC

Replication虽然可以解决持久度问题，但是单纯多副本拷贝成本也非常高！

EC（冗余解码）：可达到和多副本一样的持久度

特点：

  • 低冗余度：成本较单纯多副本低
  • 额外计算：增加了额外的编码计算步骤

image.png

5、成本解法之温冷转换

数据都是有温度的，将冷数据转移到性能更差但更廉价的存储介质不就可以省下来成本么?

image.png

6、架构细化

API：接入层

  • Bucket Meta:Bucket元信息服务
  • Object Meta:对象元信息服务
  • Disstributed KV:Range Partition的分布式KV，用于持久化对象元数据
  • Storage Engine：对象内容存取服务
  • Distributed Storage Pool：分布式存储池，三副本 or EC存储
  • GC：垃圾回收后台服务
  • Lifecycle：温冷转换后台服务

image.png

7、存储需求量细化

小明自研的对象存储上线后，公司其他业务也想使用，但是他们的要求不一样:超高的可用性!

image.png

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

首先想到的就是，一个集群拆分成多个集群，有效降低爆炸半径。

image.png

9、高可用之粤核酸的启发

但对于很多业务，例如飞书等，是希望无论情况，都保证服务可用，那应该怎么办呢? ! ! !

image.png

10、高可用之镜像灾备

完全镜像的主备Bucket,出现问题随时切换，真正100%的可用性！

image.png

image.png

avatar
文章
阅读
粉丝