Go语言实战：TOS对象存储实战｜ 青训营

Vagabonder
82 阅读6分钟

一、抖音背后的存储

1. 短视频架构初探

image.png

  • 同学你通过仔细思考，设计了一个如图的架构;客户端我们肯定需要有一个， 然后也要有账号， 也要有评论服务;但核心的来说，像抖音这类APP都是UGC,就是用户生产内容的平台，所以重中之重我们的内容生产到推荐这一条链路;
  • 这一条链路上，会有片源，也就是承接用户上传的内容，然后还有个审核服务1对这些内容进行合规的审核，最后这些内容会根据机器学习打上标签，通过各位同学历史观看兴趣通过推荐服务推荐到各位同学的手机上。

2. 存储需求

image.png

  • 这里对短视频生产/消费链路做了更细粒度分解，分成了如图的几个服务，首先第1步是片源服务，将用户上传的视频存起来，这个用户原始的视频我们叫源视频;然后会有转码服务， 将源视频转为不同码率的视频，为什么需要转码呢，因为不同的客户端(如不同的手机/电脑)型号，能接受的分辨率是不一样的,因此需要转码来适配，这里转码完后的也需要存储起来，以供后续客户端拉取;然后图下面还有个抽帧服务，将视频抽成不一样的帧，用于审核服务做审核，这里也需要有个存储把这些图片存储起来;最后就是推荐服务了，将对应视频推荐出去 ，然后客户端就可以来拉取观看啦;

3. 存储需求量细化

image.png

  • 单视频假设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块盘

4. 寻找天选存储

image.png 现在的当务之急，是寻找一个合适的存储，要求:

  • 海量:从前面分析，这个存储系统一定要能够存储如此大的海量
  • 易用:好的存储能够解放业务，让业务专注于业务逻辑开发
  • 便宜:这么大的存储量，越便宜就越能省下宝贵的经费 那有没有这样的存储呢?

二、为什么对象存储

image.png

1. 存储对比

image.png 这里详细类比了各类存储，单机存储首先我们排除，数据量实在是太大了，单机肯定存不下， 单机数据库同理。 那分布式数据库呢，现代的分布式数据库在容量和弹性上面都有很大进展，是否可以呢?答案也是No,因为分布式数据库只适合存储结构化or半结构化数据，什么是结构化数据呢，上过上面提到课程的同学应该有印象，就是数据和数据之间有一定关系， 如用户信息，-个用户会关联包括电话号码，性别等各种维度的信息，这些信息一般都是不超过KB级别的，超过MB级别就不适合使用数据库处理了;唯一的选择就是分布式存储，分布式存储是针对海量存储场景特别设计的存储，能够存储海量的大数据;

2. 分布式存储选型

image.png

3. 易用性:接口对比

image.png

刚刚对比还是比较抽象的，我们来更详细的对比HDFS和TOS的接口;接口对于任何一种存储来说，都是最重要的表征，为什么呢，因为一种新的存储之所以提出来，是因为它在新场景下解决了其他存储很难解决的问题，针对这类场景提供了新的接口可大幅简化业务逻辑

image.png

4. 适用场景

image.png

三、对象存储怎么用

image.png

1. 申请Bucket

对象存储很多云厂商都支持，这里以字节的TOS为例

2. Restful接口

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

image.png

3. Restful接口演示

我已经了解了对象存储基本接口的使用，我向组里同事演示了对象存储PUT/GET/HEAD/DELETE接口的基本用法:

image.png

4. MultilUpload接口

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

5. Listprefix接口

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

image.png

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

四、TOS字节内部实践

1. 开发一个对象存储

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

image.png 现在另外一个重任又来了，我们需要研发自己的对象存储

2. 开发一个对象存储

但是架构如何细化呢，我想了又想，先梳理当前经典业务场景，总结挑战对症下药

image.png

3. 可扩展性解法之Partition

image.png

image.png

4. 持久度解法之Replication

image.png

image.png

5. 成本解法之EC

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

image.png

6. 成本解法之温冷转换

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

image.png

7. 架构细化

image.png

8. 存储需求量细化

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

image.png

  • 单视频假设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块盘

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

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

image.png

10. 高可用之粤核酸的启发

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

image.png

11. 高可用之镜像灾备

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

image.png

12. 未来展望

image.png

五、总结

实现一个对象存储客户端不是件容易的事

avatar
文章
阅读
粉丝