这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记.
听过青训营老师讲的Tos对象存储课程，我对Tos存储对象的基础知识做了一些总结和归纳：
首先我们对TOS的概念做解释：
TOS：t是头条的意思（t也可以代表top），os是对象存储
以抖音为例，大致的短视频架构为：
片源系统 ——> 审核系统 ——> 推荐系统 短视频生产、消费
公共系统：
上传视频——>存储视频
但是短视频系统要承载非常多的用户访问量，根据未来的可能的用户数量，做了简单数学计算，结果发现存储量非常之大：
每天: 432块4tb磁盘
每月：12960块4tb磁盘
每年： 157680块4tb盘
为了应对如此之大的访问量，我们需要寻找一个合适的存储去承载数据，这个储存需要满足以下三个条件：
海量：需要一个无限扩展的内存
易用：搭建方便
便宜：在每tb上省一块钱
根据可选的存储，可以分为以下四类：
单机存储（文件系统），
单机数据库（关系型数据库，非关系型数据库），
分布式存储（分布式文件系统，对象存储），
分布式数据库（关系型数据库，非关系型数据库）
经过性能分析，发现：
单机存储——>不支持海量，适合的数据类型（单击文件）——>未入选
单机数据库——> 不支持海量,只支持结构化和半结构化数据——>未入选
分布式数据库——>支持海量，但是单条记录存储的容量太少——>未入选
分布式存储——> 大数据计算中间结果/视频/图片——>入选
分布式文件系统（HDFS）：
海量：支持PB——>EB海量存储
易用：伪Posix文件接口，开发略微复杂，非云原生，搭建维护麻烦，视频、图片相关生态接入略微复杂
便宜：使用普通x86服务器，成本低
对分布式对象存储TOS进行性能分析性能分析：
海量：支持>eb海量存储
易用：RestFul HTTP接口，开发极其简单，云原生，按需申请使用
便宜：使用普通x86服务器，具备冷热数据分级存储能力，成本更低
相比之下，Tos更适合生态.
Tos提供了多个接口： 接口速览：（围绕对象的增删改查）
Mkdirs创建文件夹
Append：写
GET：下载对象
HEAD：查看对象上传
PUT：上传对象
DELETE：删除对象
Tos中Bucket/Object语义：
Bucket：存储对象的桶，可类比一下
Object：对象，包含以下三个部分
key:对象的名字，可类比于Map的key
Data：对象的内容，例如视频、图片内容
MetaData：对象的一些元信息
前面我们已经了解了Tos，那么Tos对象存储的使用流程是什么？
流程： 申请一个bucket——>业务逻辑的开发——>上线测试
TOS在实际应用过程中：
对象存储在公有云使用量特别大。改进出了一个三层架构：
接入层（介入解析并处理接口请求）——>原信息层（存储对象元信息）——>存储引擎层（存储对象内容）
目前主要的存储框架有两种：
1.容量型：
片源：用户上传源视频
转码：源文件转码后的视频
容量：海量，>EB
吞吐：海量，>>100 GB/S
挑战：成本要低，而持久度要高，可线性扩展
2.QPS型：
抽帧：原视频审核用抽帧
特点：QPS：极高，>> 100K/S
挑战：可线性扩展
