https://github.com/minio/minio-go

https://docs.min.io/cn/

MinIO 是一个基于Apache License v2.0开源协议的对象存储服务。它兼容亚马逊S3云存储服务接口，非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，而一个对象文件可以是任意大小，从几kb到最大5T不等。

http://docs.minio.org.cn/docs/master/minio-monitoring-guide

Minio是GlusterFS创始人之一Anand Babu Periasamy发布新的开源项目。Minio兼容Amason的S3分布式对象存储项目，采用Golang实现，客户端支持Java,Python,Javacript, Golang语言。

Minio可以做为云存储的解决方案用来保存海量的图片，视频，文档。由于采用Golang实现，服务端可以工作在Windows,Linux, OS X和FreeBSD上。配置简单，基本是复制可执行程序，单行命令可以运行起来。

MinIO + thumbor完美解决图片存储与裁剪问题

https://zhuanlan.zhihu.com/p/148053565

https://blog.csdn.net/shijinghan1126/article/details/107041001

，整个集群是由多个角色完全相同的节点所组成的。因为没有特殊的节点，所以任何节点宕机都不会影响整个集群节点之间的通信。
通过 rest 跟 RPC 去通信的，主要是实现分布式的锁跟文件的一些操作。

右边这张图是单个节点的示意图，每个节点都单独对外提供兼容 S3 的服务。

2、MinIO概念介绍：Drive和Set
Drive：可以理解为一块磁盘
Set：一组Drive的集合
一个对象存储在一个Set上
一个集群划分为多个Set
一个Set包含的Drive数量是固定的
默认由系统根据集群规模自动计算得出
MINIO_ERASURE_SET_DRIVE_COUNT
一个SET中的Drive尽可能分布在不同的节点上

3、MinIO核心流程
3.1、数据编码
Erasure Code：冗余编码

将一个对象编码成若干个数据块和校验块
Reed-Solomon算法
低冗余、高可靠
MinIO的编码方式，我们简称为Erasure Code码，是通过算法还原数据的方法。MinIO使用Reed-Solomon算法，该算法把对象编码成若干个数据块和校验块。
为了表述方便，把数据库和校验块统称为编码块，之后我们可以通过编码块的一部分就能还原出整个对象

如我们所知，一个对象存储在一个Set上面，这个Set包含16个Drive，其中灰色的一半是数据库，橙色的一半是校验块，这种方式最多能忍受一半的编码丢失或损坏。所有编码块的大小是原对象的2倍，跟传统多副本存储方案相比，他只冗余存了一份，但可靠性更高。

3.3、上传和下载流程
1、上传流程：
1）先根据对象名去做一个Hash，计算出对应的Set，然后来创建临时目录。创建临时目录的目的是为了确保数据强一致性，所以中间数据都会被写入到这个临时目录里（直到所有数据写完后，再统一把目录写入到最终的路径上）
2）接下来读数据编码，每次最多读10M的数据处理，然后做编码，再被写入到磁盘上，循环的过程就是把数据保存下来。
3）数据保存完后，再写meta信息。
4）然后挪到最终的位置上，删除临时目录。

2、读取流程：
1）先根据对象名做Hash，找到对象对应的Set
2）然后去读取meta信息，通过meta信息来获得编码的方式，然后去解码。它是以10M数据做EC编码，读的时候也是逐个part解析，每个part给他做解码，然后写入到一个io write里面。
备注：我们刚刚说了，做EC码时，只要一半的编码块就能还原整个对象，所以读meta时读了N份，但是读数据时只要读N/2就可以了

MinIO的局限
局限1、搭建集群后，不允许扩容
MinIO一旦集群搭建成功后，就不可以更改集群节点数。因为存在在MinIO的对象到底存储在哪个Set，是通过名字做Hash去找的，一旦节点数变了落点就错乱了。

局限2、大集群最大节点数为32
MinIO实现了一个峰值锁叫DSync。它在节点数量少时，性能非常高；但节点数量过多时，性能就下降了。功能实现的最大节点就是32，所以导致MinIO单个集群的最大节点数也是32。

官方回复是，他们十年做GlusterFS的经验看，一个超大的集群是难以维护的，尤其是宕机之后的恢复时间也特别长，所以他们在做MinIO的时候一个核心设计理念就是简单，易于维护。

扩容方案
1、可同时向多个集群写入
2、当集群容量达到阈值，从写集群中剔除，变成只读
3、读取的时候，根据编码到文件名上的集群信息，从而路由到正确的集群。

MinIO本身提供一个叫联合模式的方式来组建集群，但是要额外引入其他依赖。可以考虑在LB层根据其请求里面的一些header信息做流量转发。

当配置多个集群的时候，可以先从配置中获取可用的集群，再从LB上根据请求的header信息，可控制向哪个集群写。当某个集群的容量达到阈值时，可以从配置中剔除该集群，把他变成只读集群。读取的时候把集群ID或信息码编码到文件名上去，这样可以通过解析文件名就能获取到对应的集群。

六、关于IO
IO有Buffered IO 和 Direct IO：

buffered IO：在读写的时候回经过一个page Cache
Direct IO：是绕过page Cache，直接对磁盘操作，所以性能会差些。
再回顾下MinIO的写入流程：MinIO数据最终的形式是写入文件系统的文件，也就是随机写的。随机写的性能肯定不如顺序写。
其次，EC编码在低冗余情况下是高可靠的，但同时也让他写入数量变多了，基本上一个对象写入需要做2N次操作，其实N次是数据的操作，N是meta的操作。基于上述原理，可总结出下述优化方案：

优化方案1、小文件合并成大文件
小文件合并成大文件，只需要把底层文件的部分稍微改一下，把原来随机写的小文件改成顺序写的大文件，这样就可以利用page cache来提供磁盘的能力。

具体实现：预先打开一个文件，分配一个固定的空间，目的是保证文件在磁盘上真是存储的数据是连续的。当写文件的时候，就给加锁，保证数据写入，因为这些原因，小文件的索引需要保存下来，所以我们引入了一个levelDB像大文件的ID和size的一些东西，之所以采用level DB是因为他的性能非常好。

接下来看MinIO的读流程：它主要发生在IO的地方有两个：一个是meta信息，然后再读data的时候，至少从N/2个节点上读取。每一次读取meta或者data的时候包括两部分：第一个从levelDB中读取索引，从大文件中读取对应的数据。

然后我们针对这个做了一个优化方案，我们把meta信息，因为meta信息没多少，我们把他压缩到level DB里，直接读就行了，不用读索引了。

再回顾下MinIO的读流程：
1、从N个节点上读取meta信息
2、至少从N/2个几点上读取data
3、每一次读取的时间包括两部分：

• 从level DB读取索引


• 从大文件中读取对应的数据
  4、并发读的最终时间取决于最长的一个

优化方案总结
1、将meta信息压缩后，直接存入level DB，减少一组IO
2、将level DB存在性能更高的SSD
3、降低单个Set的Drive数量
https://baijiahao.baidu.com/s?id=1641833930087588093&wfr=spider&for=pc

https://www.jianshu.com/p/c2b43ff67df0