一二三应用开发平台文件处理设计与实现系列之5—

本文主要是介绍一二三应用开发平台文件处理设计与实现系列之5——MinIO技术预研，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

背景

上篇介绍了文件读写框架设计与实现，同时顺便说明了本地磁盘存储模式的实现模式。
今天来说下基于文件读写框架，如何集成对象存储组件minio，集成之前，需要对minio进行必要的了解，本篇是minio的技术预研。

minio简介

minio是一套小而美的开源的对象存储系统（Object Storage System，简称OSS），优点如下：

支持存储海量非结构化数据（单个文件从几十kb到最大5T不等）
性能高，在标准硬件上，读/写速度高达183GB/秒和171GB/秒
完全兼容Amazon S3接口
增配存储资源易于实现，原有存储不变

基本概念

Object：对象，实际就是非结构化的文件，如office文档、图片、音频、视频等。
Bucket：桶，是一个用来管理对象的逻辑空间，称之为对象仓库更合适。其作用相当于磁盘上的一个顶级文件夹，并且桶与桶之间的数据是相互隔离的。桶的意义在于可以更好地分门别类管理存储的对象，避免把整个系统所有的文件一股脑都存放在一个仓库里，可以从租户、业务模块、年度等维度进一步细分。
Drive：磁盘，实际就是底层存储了，对应着磁盘或磁盘上的目录。
Set：阵列，磁盘的集合，这地方我认为很多网上的资料实际都是错的或描述不完整不准确，完整的说法应该是纠删阵列，即在部分磁盘块不可用的情况下通过冗余和算法实现数据恢复，从而能正常读写数据而划分的磁盘阵列。

纠删码机制

minio在可靠性方面做了一个优秀的设计，实现了低冗余与高容错，该方案是通过纠删码（Erasure Code）来实现的，详见官方文档https://min.io/docs/minio/linux/operations/concepts/availability-and-resiliency.html#minio-availability-resiliency。

这部分比较难理解，以下是个人阅读思考后整理处理的，供参考。
大概的原理就是对于一个存储对象，将其分成K块数据碎片，同时增加M块奇偶校验碎片，所有的碎片块所在的磁盘组成一个纠删磁盘阵列。
N (ERASURE SET SIZE) = K (DATA) + M (PARITY)
其中M值默认设置为4，可以调整设置，最小为0，最大为n/2。
M值越小，则用于存储的空间越大，当其为0时，意味着没有附加的奇偶校验碎片，虽然可用于存储的容量最大，但丧失了数据容错，任何一块数据碎片损坏，整个文件不再可读取。
M值越大，则用于存储的空间越小，当其为最大值为n/2时，意味着一个1M的文件实际使用2M的存储空间，其中1M用于数据本身，另外1M用于奇偶校验块，实现容错的目的。
从上面可以推论出来，minio存储文件，最大占用空间是其原始体积的两倍。
若N取16，M取默认值4，则数据块K为12，即12M的文件，实际占用存储空间是16M，多使用了约33%的存储空间，而不是极限情况下多占用100%空间。

关于容错性，对于读数据，在ERASURE SET中，只要无效块总量小于等于M，则都可以恢复数据并读取；对于写数据，分两种情况，如M值小于N/2，则规则同读取，只要无效块总量小于等于M即可以写；若M值刚好为N/2,则要求有效块要大于等于n/2+1。
若N取16，M取默认值4，则数据块K为12，无效块小于等于4，仍然可正常读取和写入数据。
若N取16，M取默认值8，则数据块K为8，无效块小于等于8，仍然可正常读取数据，但有效块至少为9，才能写入数据。

官方给了一张图，说明在1个Set中挂载了16块磁盘的情况下，M取值分别为4、6、8情况下，可用于存储数据的块，存储比率以及多少块处于有效时才可进行读操作和写操作。

注：存储比率指的是数据占用空间与总占用空间（数据+奇偶校验）的比例，比如8数据块8奇偶校验块，只有50%是用来存储数据的，余下50%用于冗余和恢复的。

minio集群会根据节点和磁盘数自动计算N（ERASURE SET SIZE）的取值，N最大值为16，即最常见的4个minio server节点，每个节点挂载4块磁盘的情况下，刚好组成1个阵列，并且M取值是4。因此一个规模较大的集群中，会存在多个相互独立的阵列。

部署模式

minio的部署模式分为两大类，单节点部署和分布式部署。

其中单节点部署模式下，minio会根据挂载的磁盘的数量，自动决定是否启用纠删码模式。

单节点单磁盘

最简单的情况就是单节点，挂载单个磁盘，此时不会启用纠删码模式，也不存在高可用，磁盘文件损坏无法恢复，官方建议用于开发和测试，不可用于生产环境。个人认为，对于中小型系统，这种部署架构用于生产也是可接受的，简单，实用。一方面从业务角度而言，文件通常是用户上传的附件，重要程度较低，损坏或丢失影响有限；另一方面，磁盘的可靠性相当高，磁盘产生坏道的故障率低到可以忽略。
执行如下命令，创建容器

docker run -p 9000:9000  --name minio -d --restart=always -e "MINIO_ACCESS_KEY=admin" -e "MINIO_SECRET_KEY=12345678" -v E:\dockerVolume\minio\data:/data  minio/minio:RELEASE.2021-04-22T15-44-28Z server /data

使用控制台上传文件，磁盘上存放的实际就是文件本身。

单节点多磁盘

如想提升文件的可靠性和容错，则仍可以部署单节点，然后挂载多个磁盘，该情况下自动启用纠删码模式。
执行如下命令，只挂两块磁盘

docker run -p 9000:9000  --name minio -d --restart=always -e "MINIO_ACCESS_KEY=admin" -e "MINIO_SECRET_KEY=12345678" -v E:\dockerVolume\minio\data1:/data1 -v E:\dockerVolume\minio\data2:/data2 minio/minio:RELEASE.2021-04-22T15-44-28Z server /data1 /data2

容器启动时报错

从报错可以看出，磁盘要求至少为4块，更改下命令，挂载4块磁盘，如下：

docker run -p 9000:9000  --name minio -d --restart=always -e "MINIO_ACCESS_KEY=admin" -e "MINIO_SECRET_KEY=12345678" -v E:\dockerVolume\minio\data1:/data1 -v E:\dockerVolume\minio\data2:/data2 -v E:\dockerVolume\minio\data3:/data3 -v E:\dockerVolume\minio\data4:/data4 minio/minio:RELEASE.2021-04-22T15-44-28Z server /data1 /data2 /data3 /data4

容器顺利启动，并显示4块磁盘在线

同时显示初始化了1个服务池，1个磁盘阵列，每个磁盘阵列中有4块磁盘。
通过控制台上传1张图片，查看文件情况

每个磁盘下都多了一个以文件名命名的目录，下挂一个xl.meta文件，实际是文件碎片或奇偶校验块，占用空间约为实际文件的一半，进而推断出这四块磁盘，是两块做数据，两块做奇偶校验。

进行破坏性试验，依次删除data2、data3下的xl.meta文件，来模拟磁盘失效，控制台依旧能正常显示和下载文件，继续删除data4下的文件，则控制台中该文件不再显示，与minio的容错机制一致。

多节点多磁盘

分布式部署通常用于中大型系统，是最复杂的一种部署方式。通常至少部署4个minio节点，每个节点挂载4块磁盘，这样组成了一个16块磁盘的启用了纠删码功能的阵列。上文说过，默认设置的奇偶校验块数量是4，即这16块磁盘中有12块用于数据存储，4块用于容错。在分布式部署的场景下，minio是去中心化的，所有节点是对等的，没有主从的概念。而很多集群部署的中间件，是有主从概念的，基于选举算法来产生主节点。因此，minio集群需要通过NGINX来实现负载均衡。

扩展集群

对于分布式部署，如发现原存储资源不够了，增加新的存储资源，很多同类组件往往需要重新均衡各存储节点上数据。均衡意味着要做数据迁移，不仅复杂，而且耗时较长。对于该问题，minio的处理方案则是另辟蹊径，保持原服务池不变，增加新服务池，只有一点要求，新增的服务池需要跟之前规划的磁盘数量一致，这里的一致并不是相等，而是可以是倍数关系。
比如原来得服务池是这样的
minio server http://host{1…8}/export{1…8}
可以通过以下方式扩展
minio server http://host{1…8}/export{1…8} http://host{9…16}/export{1…8}
原来的服务池保持不变，数据不需要重新均衡，新上传的文件会自动找寻负载低的服务池。
minio将复杂的增配资源问题转换成了一个部署问题，非常巧妙。

安装部署

基于虚拟机的部署比较简单，无非是获取安装包，然后运行，这里就不多说了。
接下来说下基于docker的安装部署。
直接通过docker 拉取镜像 docker pull minio/minio:RELEASE.2021-04-22T15-44-28Z

创建容器

docker run -p 9000:9000  --name minio -d --restart=always -e "MINIO_ACCESS_KEY=admin" -e "MINIO_SECRET_KEY=12345678" -v E:\dockerVolume\minio\data:/data -v E:\dockerVolume\minio\cofig:/root/.minio minio/minio:RELEASE.2021-04-22T15-44-28Z server /data

启动成功后，访问9000端口

登录后，界面如下：

就是一个很简单的页面，新建桶和上传文件都通过右下角按钮实现，相比当前的最新版本的UI和功能，相当的简陋。

新版本的登录页面

新版本的功能菜单

集成验证

基于java，验证常用API的使用。

引入依赖

<dependency><groupId>io.minio</groupId><artifactId>minio</artifactId><version>8.5.7</version>
</dependency>

新建控制器

新建一个控制器用于测试，路径设置为file，为了测试方便，直接在控制器里调用API，不再转调service了。

package miniodemo.controller;import io.minio.BucketExistsArgs;
import io.minio.MakeBucketArgs;
import io.minio.MinioClient;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;/*** @author wqliu* @date 2023-11-17*/
@RestController
@RequestMapping("/file/")
@Slf4j
public class FileController {}

构建客户端

所有API调用的前提，是构建minioClient客户端，调用MinioClient的建造器方法，传入服务地址和身份认证即可。

/*** 获取客户端* @return*/
private MinioClient getClient(){// 创建客户端MinioClient minioClient =MinioClient.builder()// 服务地址.endpoint("http://127.0.0.1:9000")// 身份认证.credentials("admin", "12345678").build();return minioClient;
}

创建桶

新加方法，通过参数传入桶名，内部简单判断是否存在，不存在则新建。同样为了测试方便，未使用post而是用了get方法。

/*** 新建桶* @param bucketName 桶名*/
@GetMapping("/addBucket")
public void addBucket(String bucketName) {try {MinioClient client = getClient();// 创建桶BucketExistsArgs bucketExistsArgs = BucketExistsArgs.builder().bucket(bucketName).build();boolean exists =client.bucketExists(bucketExistsArgs);if (!exists) {// 不存在，创建MakeBucketArgs makeBucketArgs = MakeBucketArgs.builder().bucket(bucketName).build();client.makeBucket(makeBucketArgs);}}catch (Exception ex){log.error(ex.getMessage());}}

浏览器中输入地址http://localhost:8080/file/addBucket?bucketName=abc
使用minio自带控制台，可以看到已经成功创建了桶。

上传文件

实现如下控制器方法

/*** 上传文件*/
@GetMapping("/upload")
public void upload() {try {MinioClient client = getClient();UploadObjectArgs uploadObjectArgs = UploadObjectArgs.builder().bucket("abc").object("1.png").filename("e:/1.png").build();client.uploadObject(uploadObjectArgs);}catch (Exception ex){log.error(ex.getMessage());}}

执行http://localhost:8080/file/upload
查看minio控制台，文件已上传

查看docker挂载的磁盘，在单节点单磁盘情况下，实际就是把桶映射成文件夹，把文件放到文件夹下

下载文件

实现如下控制器方法

/***  下载文件*/
@GetMapping("/download")
public void download() {try {MinioClient client = getClient();DownloadObjectArgs downloadObjectArgs = DownloadObjectArgs.builder().bucket("abc").object("1.png").filename("e:/2.png").build();client.downloadObject(downloadObjectArgs);}catch (Exception ex){log.error(ex.getMessage());}}

浏览器中访问http://localhost:8080/file/download，查看本地磁盘，文件被下载。

获取文件流

上面方法是把文件固定下载到磁盘某个目录下，实际系统使用的时候是问minio要文件流，实现如下控制器方法

/***  获取文件流*/
@GetMapping("/getFileStream")
public InputStream getFileStream() {try {MinioClient client = getClient();GetObjectArgs args = GetObjectArgs.builder().bucket("abc").object("1.png").build();GetObjectResponse response = client.getObject(args);return response;}catch (Exception ex){log.error(ex.getMessage());return null;}
}

浏览器中访问http://localhost:8080/file/getFileStream，通过调试模式，可以看到拿到了文件流。
注意API返回的类型GetObjectResponse，实际是InputStream的子类，因此可以用InputStream来接收。

总结

上文构建了基于java和springboot实现的API测试，完成了创建桶、上传文件、下载文件和获取文件流等常用操作，像删除桶、删除文件等操作也高度类似，未再一一列出。
从测试代码可以看出，minio的api做了高度统一的封装，每个方法对应着一个参数对象，并且该参数对象内置了建造器模式。处理过程也高度类似，先构建一个minio的客户端，然后使用该客户端调用API方法。

坑点：开源协议的变动

MinIO比较特别，初早期版本的开源协议是Apache 2.0，这是一种相对友好的协议，可以商用。后来变更成了AGPL V3.0，虽然仍然可以商用且无需付费，但该协议要求使用该组件的系统必须开源，这就有点……
所以，选用minio时，需要慎重选择版本，如自己本身就是开源软件，那么使用minio的新版本更适合，否则，请选用老版本的minio来规避版权问题。
通过Git库查看修改日志，最后一个基于apache 2.0协议的版本是2021-04-22T15-44-28Z，源码下载地址
https://github.com/minio/minio/tree/RELEASE.2021-04-22T15-44-28Z
因为是源码，不能直接使用，需要编译，而minio是使用go语言开发的，需要go编译环境。

多说一句，MinIO的版本号命名也独具特色（惨不忍睹），没有按照大多数的三段数字如3.1.2，或者用某系列英文来区分（如Spring Cloud），而是大多以发布时间命名的版本，不信你看……