minio api 在对于大于5m的文件，自动采用了分片上传。
但它的分片上传我们无法得知上传的分片后的序号，也就是说，每上传一个分片，我们都需要自己去记录已上传分片的序号。
这将导致一个文件分片5个，那么同样还需要调用5次后端接口去记录这5个分片的信息。这无疑大大浪费了性能，且无法做到并发上传。
基于minio java api，我们可以用另外一种方案去替代。且上传流程不需要经过后端程序，直接让前端与minio服务打交道。
初步流程： 选择上传文件 -> 提取md5 -> 请求后端校验此md5的文件是否已经上传过 -> 如果有上传就返回信息告诉前端上传完成(秒传) -> 如果没有则根据此md5获取已上传的分片有哪些，未上传的分片有多少个就返回多少个上传url
如何获取已上传的分片有哪些呢？ minio api有一个生成上传url的api，这个api可以指定接下来要上传文件的文件名，也就是说，在上传步骤，我们只要保证上传的分片文件是有规则的，那么我们就可以很轻松的获取到
举个例子：上传文件的大小为10m，分片2个，md5为 abc123，则我们生成2个上传url,每个url指定的文件名为 md5/分片序号.part（分片文件要不要文件后缀都可以） 的格式，也就是 abc123/1.part;abc123/2.part
所有分片文件上传完成后，通过 listObjects 获取到 abc123 前缀开头的所有文件，即是所有分片文件的path，最后合并文件即可
为什么不所有步骤都采用前端直连Minio?毕竟官方的sdk也提供了前端的示例 这样做会直接暴露有关于minio的敏感信息，并且不管怎样，始终也需要后端去记录最终文件上传完成后的信息，所以一些敏感的操作，还是由后端程序来协助
这个流程的好处：
省掉每个分片的md5计算省掉每上传一个分片文件就请求后端记录一次分片信息省掉每个分片的数据库存储，合并文件后只需要删除分片文件，不需要再删除数据库数据可以并发上传文件上传直连于minio服务，不经过后端程序分片文件更方便管理，比如分片文件上传到一个B桶里，合并的文件合并到A桶去不暴露敏感信息后端程序在整个流程里，仅仅充当了md5校验、生成url、通知minio合并文件的角色
本方案测试结果：
前后端Demo：https://download.csdn.net/download/anxyh_name/12821913
