MinIO | 高性能，对Kubernetes友好的对象存储

一 分布式文件系统应用场景

1. fastDFS
   1. 缺点：
      1. 部署麻烦。
      2. 因为文件名是自动生成的，所以如果要处理文件的话，还要经过额外的编码。
2. Minio介绍
   1. 应用场景
      1. 互联网海量非结构化数据的存储需求，如
                     电商网站：海量商品图片
                     视频网站：海量视频文件
                     网盘 : 海量文件
                     社交网站：海量图片
      2. 对于中小型企业，如果不选择存储上云，那么 Minio 是个不错的选择，麻雀虽小，五脏俱全。当然 Minio 除了直接作为对象存储使用，还可以作为云上对象存储服务的网关层，无缝对接到 Amazon S3、 MicroSoft Azure。
      3. 非结构化数据与结构化数据
         1. 非结构化数据：文件、音频、视频、图片
         2. 结构化数据：如常见的关系型数据库（mysql、oracle、sqlserver）用表存储某个网站的会员信息。
   2. minio是什么？
      1. MinIO 是一个基于Apache License v2.0开源协议的对象存储服务。
         1. 对象存储服务（Object Storage Service，OSS）是一种海量、安全、低成本、高可靠的云存储服 务，适合存放任意类型的文件。容量和处理能力弹性扩展，多种存储类型供选择，全面优化存储成 本。
      2. Minio是使用go语言编写的，天然支持跨平台。
   3. minio的优点
      1. 部署简单: 一个single二进制文件即是一切，还可支持各种平台。
      2. minio支持海量存储，可按zone扩展(原zone不受任何影响)，支持单个对象最大5TB;
      3. 兼容Amazon S3接口，充分考虑开发人员的需求和体验;
      4. 低冗余且磁盘损坏高容忍，标准且最高的数据冗余系数为2(即存储一个1M的数据对象，实际占用 磁盘空间为2M)。但在任意n/2块disk损坏的情况下依然可以读出数据(n为一个纠删码集合(Erasure Coding Set)中的disk数量)。并且这种损坏恢复是基于单个对象的，而不是基于整个存储卷的。
      5. 读写性能优异
3. MinIO的基础概念
   1. Object：一个文件 / 视频 / 音频 / 字节流 / Anything......
   2. Bucket：翻译过来是桶，可理解为一个顶层的目录（文件夹）。Bucket是用来装Object的。
   3. Drive：即存储数据的磁盘。
   4. Set ：分布式集群场景或多磁盘场景下。一组Drive的集合。
   5. 备注：
      1. 当MinIO集群服务启动以后，表明已经把Drive配置好了（当然，我们需要去指定Drive的位置、存储目录）。
      2. Object和Bucket是我们真正去操作、控制的2个东西，比如想把文件存储到哪个Bucket下面，我们要上传哪些Object。
4. 纠删码EC（Erasure Code）： 备份与恢复
   1. 作用：
      1. EC机制是用来保证MinIO高可靠性。
         1. 第一步：EC机制是用来校验数据是否损坏（如本身磁盘（硬件）就损坏了，如单单数据的损坏）。
            1. 校验原理（Bit Rot Protection）：直接对MinIO中的文件进行一个hash。因为hash码是唯一的，所以如果hash码不变说明文件没有损坏，反之说明文件已经损坏了。
         2. 第二步：EC机制是用来做数据冗余和恢复的
            1. 如果数据损坏，可以校验是否是源文件数据损坏了，并且可以使用EC机制highwayhash来处理数据损坏（Bit Rot Protection）。
            2. minIO纠删码还原，是依赖于EC盘的数量去做处理的。
               1. 条件1：所有的盘都是可读的。
               2. 条件2：如果是坏死盘，MinIO是不允许我们再上传新的文件到坏死盘上面去的。
               3. 条件3：大于等于N/2+1的可读的正常状态下的盘的情况下，才能保证有EC盘数据的存在，也才能有可能通过EC机制来恢复数据。
   2. 案例1：EC机制下的数据冗余与恢复
      1. 有6块盘（因为EC机制生效最少需要4块盘）。
      2. 其中4块盘用于存储用户的数据，比如1.jpg。
      3. 其中2块盘用于存储对它EC机制编号后生成的1.jpg。
      4. 如果丢失1份数据，可以是4块盘中之一的1.jpg，也可以是2块盘之一EC后的1.jpg。那么，根据一定的算法可以恢复和还原。
      5. 如果丢失2份数据，而且是2块盘EC后的1.jpg都丢失了，那么不是还有4个盘的1.jpg嘛。
      6. 如果丢失3份数据，4块盘中之一和2块盘EC后的1.jpg都丢失了，那么就无法去恢复和还原了。
   3. 案例2：为了保证数据的冗余和恢复MinIO推荐使用方式
      1. MinIO推荐平均去分配
         1. 8个盘。
         2. 4个盘存源数据，4个盘存EC数据。
         3. 意味着，不管在什么情况下，如果丢失的数据<=4个盘，数据仍可以恢复。
5. 存储形式
   1. 开启EC模式下的存储形式： 
6. 存储方案
   1. MinIO集群的存储方案：
      1. 第一步：搭建MinIO集群
      2. 第二步：MinIO集群提供操作的API接口，默认端口9000，可以读写集群中的文件。
      3. 第三步：MinIO集群提供的控制台，端口随便定义，比如50000