大文件上传
问题:
- 内存消耗:
- 大文件上传时,服务器可能会将整个文件读入内存,尤其是在处理阶段。如果文件非常大,这可能导致内存溢出或显著降低服务器性能。
- 带宽和上传时间:
- 大文件上传会占用较多的网络带宽,可能导致上传速度慢,特别是对于网络条件不佳的用户。上传时间长也会增加用户体验的延迟。
- 服务器资源:
- 处理大文件上传需要服务器投入更多的CPU和I/O资源,可能导致服务器负载上升,影响其他服务的性能。
- 连接超时:
- 默认的HTTP连接超时时间可能不足以处理大文件上传,这可能导致上传过程中断。
- 并发上传限制:
- 服务器可能需要处理多个大文件的并发上传,这会进一步加剧资源消耗和可能的性能瓶颈。
- 安全性:
- 大文件上传可能成为攻击向量,如上传恶意文件或进行DoS攻击。因此,需要实施严格的文件类型和大小限制,以及病毒扫描和内容审查。
- 持久化和存储:
- 服务器需要有足够大的磁盘空间来存储上传的文件。同时,文件系统和存储解决方案的性能(如读写速度和IOPS)也会影响上传速度和整体性能。
- 用户界面和体验:
- 用户在上传大文件时可能会遇到进度指示不准确、上传状态不确定等问题,影响用户体验。
- 数据一致性:
- 在上传过程中,如果发生网络中断或服务器故障,可能需要机制来确保数据的一致性和完整性,如断点续传和校验上传的文件。
- 备份和恢复:
- 对于重要文件,需要有备份和恢复策略,以应对可能的数据丢失风险。
引发的解决方案
- 分块上传
前端需要将文件切分为多个分块的小文件,并把分块总数,当前分块序号,当前分块文件大小(多少字节),分块文件等信息给到后端接口
后端:主要利用RandomAccessFile对象根据当前分块序号,当前分块文件大小计算出当前分块的文件偏移量后去在文件里写字节。同时还需要记录当前分块的上传成功标致
- 断点续传
前端在上传前先判断有哪些分块是上传成功的,有那些分块是未上传的,将未上传的分块继续上传即可
- 秒传
- 前端在上传前先判断当前文件之前是否上传过,如果上传过的话,直接返回文件地址。
示例代码地址:humingliu/springboot-filesystem: springboot实现超大文件上传方案(支持断点续传、秒传功能) (github.com)