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

等待救赎的波
164 阅读4分钟

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

抖音背后的存储

短视频架构初探

image.png

存储需求

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

image.png

存储需求量细化

image.png

寻找天选存储

image.png

为什么对象存储

前情回顾

image.png

存储对比

image.png

分布式存储选型

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

image.png

易用性：接口对比

弱Posix文件系统语义

  • 目录/文件
  • Append写
  • 无法直接HTTP访问 接口速览
  • Mkdirs
  • Append
  • Create
  • CreateSymlink
  • Delete
  • Open
  • Get
  • ...

image.png

Bucket/Object语义

  • Bucket:存储对象的桶，可类比一个云上的Map
  • Object:对象，包含如下三个部分
    • Key: 对象的名字，可类比Map的Key
    • Data:对象的内容,例如视—/图片内容
    • MetaData:对象的一些元信息，如对象大小，对象Content-Type，也可以存储自定义元信息 HTTP接口
  • 任何时间、任何地点、任何互联网设备上传和下载数 据
  • 支持HTTP协议的各种客户端都可访问 接口速览
  • GET:下载对象
  • HEAD:查看对象元言息
  • PUT:上传对象
  • DELETE:删除对象
  • ...

image.png

适用场景

image.png

对象存储怎么用

image.png

申请Bucket

对象存储很多云厂商都支持.小明选择了字节的TOS:

Restful 接口

PUT: -参数：Bucket, key。对象内容

  • 返回:成功/失败 GET:
  • 参数: Bucket, Key
  • 返回:对象内容 HEAD: Lite版GET
  • 参数: Bucket, Key
  • 返回:对象元信息，如大小/Content-Type等 DELETE:
  • 参数:Bucket, Key。
  • 返回:成功/失败

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

image.png

Restful接口演示

image.png

MultiUpload接口

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

lnitUpload:

  • 参数:Bucket , Key
  • 返回:uploadld UploadPart:
  • 参数:uploadld, Partld , Part内容
  • 返回:成功/失败 CompleteUpload:
  • 参数:uploadld, Partld Array
  • 返回:成功/失败 当一口吃不成胖子时，你应该慢慢来，到最后你会发现，肚子总会比钱包先鼓起来!

image.png

Listprefix 接口

image.png

image.png

TOS字节内部实战

开发一个对象存储

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

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

image.png

开发一个对象存储

image.png

可扩展性解法之Partition

分布式存储=分布式＋单机存储 分布式:

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

image.png

artition (分而治之)

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

image.png

持久度解法之Replication

持久度的敌人:不可靠的一切

  • 不可靠的硬件
  • 不可靠的软件
  • 自然灾害
  • 甚至是太阳黑子! 数据单节点存储，一定有较大概率丢失无法找回!!!

image.png

复制(Replication)

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

image.png

成本解法之EC

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

EC (Erasure Coding)

  • 冗余编码:可达到和多副本一样的持久度 特点
  • 低冗余度:成本较单纯多副本低
  • 额外计算:增加了额外的编码计算步骤 思考

image.png

成本解法之温冷转换

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

image.png

架构细化

  • API:接入层
  • Bucket Meta: Bucket元信息服务
  • Object Meta:对象元信息服务
  • Distributed Kv: Range Partition的分布式KV、用于持久化对象元数据
  • Storage Engine:对象内容存取服务
  • Distributed storage Pool:分布式存储池.三副本 or Ec存储
  • GC:垃圾回收后合服务
  • Lifecycle:温冷转换后合服务

image.png

存储需求量细化

image.png

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

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

image.png

高可用之粤核算的启发

image.png

高可用之镜像灾备

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

image.png

avatar
文章
阅读
粉丝