TOS对象存储
存储需求
把短视频生成/消费链路做更细粒度分解，发现到处都有视频/图片的公共存储需求
存储需求量细化
根据未来可能的用户量，简单做数学计算，发现存储量真是大
Day
1730TB
432块4TB磁盘
20亿个视频/图片
Month
51900TB
12960块4TB磁盘
622亿个视频/图片
Year
631450TB
157680块4TB磁盘
7568亿个视频/图片
寻找天选存储
现在的当务之急，是寻找一个合适的存储，要求：
存储系统分类
单机存储
文件系统
Key-Value存储
单机数据库
关系型数据库
非关系型数据库
分布式数据库
关系型数据库
非关系型数据库
分布式存储
分布式文件系统
对象存储
存储对比
| 存储备选 | 海量支持 | 适合数据类型 | 是否入选 |
|---|---|---|---|
| 单机存储 | NO | 单机文件/KV | NO |
| 单机数据库 | NO | 少量（半）结构化数据 | NO |
| 分布式数据库 | Yes | 大量（半）结构化数据 | NO |
| 分布式存储 | Yes | 大数据计算中间结果/视频/图片等 | Yes |
分布式存储选型
分布式存储也有分布式文件系统和对象存储，应该选择哪个呢？
| 类型 | 海量 | 易用 | 便宜 | 是否入选 |
|---|---|---|---|---|
| 分布式文件系统HDFS | 支持PB→EB海量存储 文件数量受Name Node限制 | 伪Posix文件接口，开发略复杂 非云原生，搭建维护较麻烦 视频/图片相关生态接入略复杂 | 使用普通x86服务器，成本低 | NO |
| 对象存储TOS | 支持>EB海量存储 对象数量无限制 | Restful HTTP接口，开发极简单 云原生，按需申请使用 视频/图片相关生态丰富 | 使用普通x86服务器 具备冷热数据分级存储能力，成本更低 | Yes |
对象存储
易用性：接口对比
弱Posix文件系统语义
目录/文件
Append写
无法直接HTTP访问
接口速览
MKdirs
Append
Create
CreareSymlink
Delete
Open
Get
......
Bucket/Object语义
Bucket：存储对象的桶，可类比一个云上的Map
Object：对象，包含如下三个部分
Key：对象的名字，可类比Map的Key
Data：对象的内容，例如视频/图片内容
MetaData：对象的一些元信息，如对象大小，对象Content-Type，也可以存储自定义元信息
HTTP接口
任何时间、任何地点、任何互联网设备上传和下载数据
支持HTTP协议的各种客户端都可访问
接口速览
GET：下载对象
HEAD：查看对象元信息
PUT：上传对象
DELETE：删除对象
......
适用场景
适用于静态、Immutable：视频、图片、文本、安装包、备份、前端js文件等
不适用于结构化、Mutable：关系型数据（商品订单等）、KV（缓存记录等）、随机写（在线编辑文件等）、Append写（大数据计算中间结果等）、更新频繁（钱包余额等）
用法
申请Bucket
去云厂商申请，这里就不做过多的介绍了
Restful接口
PUT
参数：Bucket，Key，对象内容
返回：成功/失败
GET
参数：Bucket，Key
返回：对象内容
HEAD：Lite版GET
参数：Bucket，Key
返回：对象元信息，如大小/Content-Type等
DELETE
参数：Bucket，Key
返回：成功/失败
Restful接口演示
MultiUpload接口
问题发现：上传数GB的大视频时，由于网络不好，总是上传到99%就网络卡住了，翻遍对象存储各类手册，终于发现了一个解决次场景的闪电三连鞭：MultiUpload
InitUpload
参数：Bucket，key
返回：UploadId
UploadPart
参数：UploadId，PartId，Part内容
返回：成功/失败
CompleteUpload
参数：UploadId，PartId Array
返回：成功/失败
Listprefix接口
把上传/下载/删除对象存储等基本场景搞定后，但是想看看桶里面有哪些对象，翻遍开发手册后，发现了一个分页列表接口：ListPrefix
ListPrefix参数
prefix：key前缀
delimiter：分隔符，默认为/
max-keys：本次分页数量
start-after：分页起始对象Key
ListPrefix返回
common-prefix：共同前缀
objects：对象key列表
isTruncated：是否已经列举完
实践使用
开发一个对象存储
经典的三层架构
接入层：接入解析并处理接口请求
元信息层：存储对象元信息
存储引擎层：存储对象内容
但是架构如何细化，先梳理当前经典业务场景，总结挑战对症下药
容量型
代表业务
片源：用户上传原视频
转码：源文件转码后的视频
特点
容量：海量，>EB
吞吐：海量，>>100GB/S
高持久度：用户视频不能丢
挑战
可扩展性：容量/吞吐需可线性扩展
成本：单位存储成本需要足够低
持久度：如何在保证成本的情况下，确保高持久度
QPS型
代表业务
抽帧：原视频审核用抽帧
特点
QPS：极高，>>100k/s
挑战
可扩展性：QPS需可线性扩展
可扩展性解法之Partition
分布式存储 = 分布式 + 单机存储
分布式
存储均匀分布
计算均匀分布
压力均匀分布
分布式系统相当于一个蜂群，每个节点都负责一小部分数据存储和计算，达到1+1>=2的效果
Partition（分而治之）
分而治之：不同数据映射至不同Partition分区
Partition Logic：Hash/Range
可扩展性如何达成
数据量增加：扩容机器新建Partition
Parition Logic：新增数据写入映射导向新Partition
持久度解法之Replication
持久度的敌人：不可靠的一切
不可靠的硬件
不可靠的软件
自然灾害
甚至是太阳黑子
数据单节点存储，一定有较大概率丢失无法找回！
复制（Replication）
数据复制多份，即多个副本
副本放置策略
多机架：可抵抗机架级别故障
多机房：可抵抗机房级别故障
多Region：可抵抗Region级别故障
带来
高持久度：不丢数据
强吞吐能力：多个副本可以提供服务
成本解法之EC
Replication虽然可以解决持久度问题，但是单纯多副本拷贝成本也非常高
EC（Erasure Coding）
冗余编码：可达到和多副本一样的持久度
特点
低冗余度：成本较单纯多副本低
额外计算：增加了额外的编码计算步骤
成本解法之温冷转换
数据都是有温度的，将冷数据转移到性能更差但更廉价的存储介质不就可以省下来成本么
架构细化
API：接入层
Bucket Meta：Bucket元信息服务
Object Meta：对象元信息服务
Distributed KV：Range Partition的分布式KV，用于持久化对象元数据
Storage Engine：对象内容存取服务
Distributed Storage Pool：分布式存储池，三副本 or EC存储
GC：垃圾回收后台服务
Lifecycle：温冷转换后台服务
存储需求量细化
超高的可用性
高可用解法之拆分降低爆炸半径
首先想到的就是，一个集群拆分成多个集群，有效降低爆炸半径
高可用之奥核算的启发
但对于很多业务，是希望无论什么情况，都保证服务可用，那应该怎么办呢？
高可用之镜像灾备
完全镜像的主备Bucket，出现问题随时切换，真正100%的可用性
