这是我参与「第三届青训营 -后端场」笔记创作活动的的第3篇笔记
记录了课上讲解的一些内容，对于一些思考题给出了自己的想法，可能存在错误。若有问题，敬请指出改正。
抖音背后的存储
短视频架构初探
短视频生产消费流程：片源系统->送审系统->推荐系统
短视频公共系统：客户端，账号系统，评论系统
存储需求的量化
假设一个视频大小10MB，经过转码后不同码率大小10MB，审核用的抽帧图片1MB共计21MB。每秒钟有1K视频上传 则一套需要内存空间
简而言之，需要一个能存储海量数据的系统。从经济角度来说，还需要便宜，从开发角度来说还需要易用
对象存储
| 存储备选 | 是否支持海量数据 | 适合数据类型 |
|---|---|---|
| 单机存储 | 否 | 单机文件/KV |
| 分布式存储 | 是 | 大数据计算中间结果,视频，图片等 |
| 单机数据库 | 否 | 结构化数据（少量） |
| 分布式数据库 | 是 | 结构化数据（大量） |
根据各种存储备选直接的对比可以看出：在面对海量数据的时候，单机是完全无法满足需求，必须采用分布式。与此同时，视频图片一类的非结构化数据不适合用数据库存储。因此选用分布式存储
分布式存储也分分布式文件系统HDFS与对象存储。
对象存储适用的场景：图片，视频，文本，安装包....简而言之就是静态的，不可变的数据
对象存储不擅长的场景：关系型数据，键值对（KV），随机写入（在线编辑），更新频繁.... 简而言之就是结构化的，可修改的数据
对象存储的使用
常用参数
PUT,GET,HEAD,DELETE
高级参数
multiUpload:在文件较大（1GB）时，一次性完全传输容易因网络问题失败。因此将文件分为为多个块，传输。
listprefix:查看桶（Bucket）中对象列表
实践
对象存储架构
三层架构
接入层：接收请求
元信息层：存储对象元信息（大小，类型等）
存储引擎层：存储对象内容
业务需求
容量型：如用户上传的视频。需求容量大，吞吐强，持久度高。 QPS型：如审核抽帧。需求QBS极高 拓展性：可以线性拓展
拓展性的解决方案
Partition:将数据映射至不同分区。映射的算法通常有Hash和Range
hash与range方式的优劣？
Hash:可以快速定位数据所在分区，但无法顺序获得数据 Range:数据保持原来的顺序，但可能出现数据扎堆的情况。
各partition之间如何负载均衡？
hash：采用一致性hash并数据迁移 range:根据数据的聚集性，分裂或合并数据range。
replication:数据复制多个副本，在服务崩溃时调用副本抵抗故障
replication拷贝方式：联想数据库的主从同步
replication如何解决一致性问题：Raft一致性算法
EC(erasure coding) 冗余编码：可达到和多副本一样的持久度。
特点：成本较单纯多副本低，但是增加了额外的编码计算步骤
温冷转换：大致思路是将热点数据存储到一些性能好但昂贵的介质中，待到数据热度下降（访问量趋于平稳）再转移到存储量大，价格便宜的介质中。
集群拆分：将集群拆分为多个集群。当其中一个集群故障时，其余集群可以不受影响。同时，可以将故障的集群业务暂时转移到正常集群保证尽快恢复。
