这是我参与「第三届青训营 -后端场」笔记创作活动的第3篇笔记
背景
类似于抖音这种 APP，每天产生的视频/图片的数目是巨大的，粗略地计算，每天可能会产生 20 亿个视频/图片，需要 432 块 4 TB的磁盘。因此这种软件背后对海量存储有很大的需求
一个合适的存储，要求
海量：随着软件的发展，对存储的需求只会越来越高，不能说只满足当下软件运行所需的存储，还要考虑到未来会有更多海量数据
易用：存储本身不应花费太多的适配，搭建的时间，好的存储应该解放业务，即开发人员可以专注于业务的开发而不需要花费一部分时间在存储的搭建上
便宜：成本不应太高
为什么需要对象存储
存储系统的分类以及选择
存储系统可以分为四类：
- 单机存储：文件系统，K-V 存储
- 单机数据库：关系型数据库，非关系型数据库
- 分布式数据库：关系型数据库，非关系型数据库
- 分布式存储：分布式文件系统，对象存储
单机肯定无法撑起海量数据；而分布式数据库适合存储大量结构或半结构化数据，即数据本身占用空间不大，尽管产生了很多数据，累积起来总共的占用空间也可以接受，如存储全国人民的工资；而大数据计算中间结果，视频，图片等，本身容量就很大的数据，还是适合于分布式存储
再分别从海量，易用，便宜三个角度对比分布式文件系统 HDFS 和对象存储：
- 对象存储比分布式文件系统支持更大数据量的海量存储，而且存储的对象数量无限制
- 分布式文件系统对外提供的是伪 Posix 文件接口，开发较复杂，而且非云原生，搭建维护较麻烦，对于视频，图片等相关的生态，接入略复杂，而对象存储提供了 Restful HTTP 接口，开发简单，云原生，可以按需申请使用，视频等相关生态也非常丰富，已经提供好了
- 两者都是使用普通 x86 服务器，但对象存储具备冷热数据分级存储能力，成本更低。如冷数据就放到较为便宜的硬件上，灵活调整
简单认识对象存储
对象存储云端中的概念有 Bucket，Object。Bucket 类似于一个云上的 Map，可以往里面存储对象。Object 即对象，包含 Key (对象的名字)，Data (对象的内容，如视频/图片)，Metadata (元信息，如对象大小，Content-Type，自定义元信息等)三部分。通过 HTTP 协议接口进行访问，如 Get 下载对象，HEAD 查看对象元信息，PUT 上传对象，DELETE 删除对象等
适用场景
适合的数据为静态，immutable的数据，如视频，图片，文本，安装包，备份，js文件等等
不适用的数据为结构化，mutable的数据，如关系型数据，对象存储系统是不会明白数据中的关系的；缓存，对象存储主打的是大数据存储，静态存储，没有像适用于缓存的数据库如 Redis 那样的高性能读写的特性，不适合做缓存；随机写，多个人在线编辑共享文档，静态存储不适合这种场景；更新频繁的东西
对象存储怎么用
基本步骤
申请 Bucket -> 业务逻辑开发，即讲业务接口如视频上传，视频下载等与对象存储结合 -> 上线测试
MultiUpload 接口
实际开发中可能会遇到这种问题：上传数 GB 的大视频时，由于网络不好，上传到 99% 就卡住失败了
对于这种弱网，大对象的上传的优化，即 MultiUpload 接口
接口中有三个操作：initUpload，UploadPart，CompleteUpload
initUpload 会为整个大对象分配一个 UploadId，UploadPart 会将大对象分为几个较小的 Part，然后分别上传各个 Part，上传到对象存储服务端后就可以根据 UploadId 将各个 Part 又整合为原来的大对象，由 CompleteUpload 来完成这些收尾步骤。整个方案使用的是分而治之的思想
ListPrefix 接口
一个分页列举对象的接口
内部实践
可扩展性解法之 Partition
将对象打散到各个 Partition 上
持久度解法之 Replication
将数据复制多份，即多个副本，不同副本放到不同的地方存储 (副本怎么拷贝生成？如何解决一致性?多副本也带来拷贝跟存储的问题......)
成本解法之 EC
Erasure Coding，冗余编码，降低副本数据的冗余度，以编码来拷贝数据
成本解法之 温冷转换
冷数据转移到性能更差但更廉价的存储介质
高可用解法之拆分集群降低爆炸半径
将一个集群拆分多个部分，降低爆炸半径
高可用解法之镜像灾备
设置一个主 Bucket和一个 备 Bucket，一般使用主 Bucket 进行读写，同时将数据增量地同步到备 Bucket 中，当主 Bucket 故障时，就使用备 Bucket 进行读写，同时这段期间备 Bucket 的数据也增量地同步到主 Bucket 中，主备 Bucket 的同步称为增量双向同步
