大文件上传#

背景#

文件上传是一个老生常谈的话题了，在文件相对比较小的情况下，可以直接把文件转化为字节流上传到服务器，但在文件比较大的情况下，用普通的方式进行上传，这可不是一个好的办法。

目前我们平台后管存在许多界面数据超过十几万条数据，常规的导出功能在面对如此大数据量的数据容易造成 OOM 等问题，因此需要一种新的上传方式来解决这个问题。

目前我们的导出都是通过后端使用 EasyExcel 生成文件上传到 OSS 并返回 OSS 地址的模式，想要解决大数据量的情况必须在生成文件和上传 OSS 的时候做出优化。

方案#

1
title: 对象存储 OSS 文档
2
desc: 点击跳转查看详细内容
3
logo: /icon/ali-logo.svg
4
link: https://www.alibabacloud.com/help/zh/oss/developer-reference/overview-13/?spm=a2c63.p38356.help-menu-31815.d_19_2_0_1_0.71dc7dceTpA6TC&scm=20140722.H_32013._.OR_help-T_intl~zh-V_1
5
color: rgba(173, 216, 590, 0.15)

秒传#

通俗的说，你把要上传的东西上传，服务器会先做 MD5 校验，如果服务器上有一样的东西，它就直接给你个新地址，其实你下载的都是服务器上的同一个文件。想要不秒传，其实只要让MD5改变，就是对文件本身做一下修改（改名字不行），例如一个文本文件，你多加几个字，MD5就变了，就不会秒传了。

具体实现#

利用redis的set方法存放文件上传状态，其中key为文件上传的md5，value为是否上传完成的标志位，
当标志位true为上传已经完成，此时如果有相同文件上传，则进入秒传逻辑。如果标志位为false，则说明还没上传完成，此时需要在调用set的方法，保存块号文件记录的路径，其中key为上传文件md5加一个固定前缀，value为块号文件记录路径

分片上传#

分片上传，就是将所要上传的文件，按照一定的大小，将整个文件分隔成多个数据块（我们称之为Part）来进行分别上传，上传完之后再由服务端对所有上传的文件进行汇总整合成原始的文件。

断点续传#

断点续传是在下载或上传时，将下载或上传任务（一个文件或一个压缩包）人为的划分为几个部分，每一个部分采用一个线程进行上传或下载，如果碰到网络故障，可以从已经上传或下载的部分开始继续上传或者下载未完成的部分，而没有必要从头开始上传或者下载。本文的断点续传主要是针对断点上传场景。

断点续传可以看成是分片上传的一个衍生，因此可以使用分片上传的场景，都可以使用断点续传。

为了避免客户端在上传之后的进度数据被删除而导致重新开始从头上传的问题，服务端也可以提供相应的接口便于客户端对已经上传的分片数据进行查询，从而使客户端知道已经上传的分片数据，从而从下一个分片数据开始继续上传。

思路技巧#

在选择导出方案的时候可以根据数据量来决定采用直接上传还是异步处理。如果数据量不大于万级，可以采用直接上传的方式。如果数据量大于万级，可以采用异步处理的方式来减少内存消耗。
可以在请求下载和处理上传的地方排队加锁，防止大量请求打满服务器。
如果数据量确实很大导致数据处理时间很长或者吃内存，可以定时在夜晚业务量少的时间进行。