小明:可以实现的,不过要限定下文件大小。
最好别超过 30MB,太大了上传比较慢,做事器压力也大。

产品经理:沟通下来,视频时一定要的。
就限定 50MB 以下吧。

小明:可以。

fileuploadclassphp晋升文件上传机能的 4 种方法你会吗 GraphQL

A FEW DAYS LATER

测试同学:这文件上传也太慢了吧,我试了一个 50mb 的文件,花了一分钟。

小明:whats up,这么慢。

产品经理:弗成,你这太慢了, 想办法优化下。

优化之路问题定位

整体的文件上传调用链路如下图:

调用链路

小明创造前端开始上传,到要求到后端就花费了近 30 秒,该当是浏览器解析文件导致的慢。

后端做事要求文件做事也比较慢。

办理方案

小明:文件做事有异步接口吗?

文件做事:暂时没有。

小明:这个上传确实很慢,有优化建议吗?

文件做事:没有,看了下便是这么慢。

小明:……

末了小明还是决定把后真个同步返回,调度为异步返回,降落用户的等待韶光。

把后真个实现调度了一番适应业务,前端调用后获取异步返回标识,后端根据标识查询文件做事同步返回的结果。

缺陷也很明显,异步上传失落败,用户是不知道的。

不过碍于韶光缘故原由,也便是能权衡利弊,暂时上线了。

最近小明有些韶光,于是就想着自己实现一个文件做事。

文件做事

碍于文件做事的功能非常原始,小明就想着自己实现一个,从以下几个方面优化:

(1)压缩

(2)异步

(3)秒传

(4)并发

(5)直连

压缩

日常开拓中,尽可能和产品沟通清楚,让用户上传/下载压缩包文件。

由于网络传输是非常耗时的。

压缩文件还有一个好处便是节约存储空间,当然,一样平常我们不用考虑这个本钱。

优点:实现大略,效果拔群。

缺陷:须要结合业务,并且说服产品。
如果产品希望图片预览,视频播放,压缩就不太适用。

异步

对付比较耗时的操作,我们会自然的想到异步实行,降落用户同步等待的韶光。

做事端吸收到文件内容后,返回一个要求标识,异步实行处理逻辑。

那如何获取实行结果呢?

一样平常有 2 种常见方案:

(1)供应结果查询接口

相对大略,但是可能会有无效查询。

(2)供应异步结果回调功能

实现比较麻烦,可以第一韶光获取实行结果。

秒传

小伙伴们该当都用过云盘,云盘有时候上传文件,非常大的文件,却可以瞬间上传完成。

这是如何实现的呢?

每一个文件内容,都对应唯一的文件哈希值。

我们可以在上传之前,查询该哈希值是否存在,如果已经存在,则直接增加一个引用即可,跳过了文件传输的环节。

当然,这个只在你的用户文件数据量很大,且有一定重复率的时候上风才能表示出来。

伪代码如下:

public FileUploadResponse uploadByHash(final String fileName, final String fileBase64) { FileUploadResponse response = new FileUploadResponse(); //判断文件是否存在 String fileHash = Md5Util.md5(fileBase64); FileInfoExistsResponse fileInfoExistsResponse = fileInfoExists(fileHash); if (!RespCodeConst.SUCCESS.equals(fileInfoExistsResponse.getRespCode())) { response.setRespCode(fileInfoExistsResponse.getRespCode()); response.setRespMessage(fileInfoExistsResponse.getRespMessage()); return response; } Boolean exists = fileInfoExistsResponse.getExists(); FileUploadByHashRequest request = new FileUploadByHashRequest(); request.setFileName(fileName); request.setFileHash(fileHash); request.setAsyncFlag(asyncFlag); // 文件不存在再上传内容 if (!Boolean.TRUE.equals(exists)) { request.setFileBase64(fileBase64); } // 调用做事端 return fillAndCallServer(request, "api/file/uploadByHash", FileUploadResponse.class);}并发

另一种办法便是对一个比较大的文件进行切分。

比如 100MB 的文件,切成 10 个子文件,然后并发上传。
一个文件对应唯一的批次号。

下载的时候,根据批次号,并发下载文件,拼接成一个完全的文件。

伪代码如下:

public FileUploadResponse concurrentUpload(final String fileName, final String fileBase64) { // 首先进行分段 int limitSize = fileBase64.length() / 10; final List<String> segments = StringUtil.splitByLength(fileBase64, limitSize); // 并发上传 int size = segments.size(); final ConcurrentHashMap<Integer, String> map = new ConcurrentHashMap<>(); final CountDownLatch lock = new CountDownLatch(size); for(int i = 0; i < segments.size(); i++) { final int index = i; Thread t = new Thread() { public void run() { // 并发上传 // countDown lock.countDown(); } }; t.start(); } // 等待完成 lock.await(); // 针对上传后的信息处理}直连

当然,还有一种策略便是客户端直接访问做事端,跳过后端做事。

文件直连

当然,这个条件纲求文件做事必须供应 HTTP 文件上传接口。

还须要考虑安全问题,最好是前端调用后端,获取授权 token,然后携带 token 进行文件上传。

小结

文件上传是非常常见的业务需求,上传的性能问题是肯定要考虑和优化的一个问题。

上面的几种方法可以灵巧的组合利用,结合自己的业务进行更好的实践。

希望本文对你有所帮助,如果喜好,欢迎点赞收藏转发一波。

我是老马,期待与你的下次相逢。