JSP大文件分块上传与断点续传实现详解

1. 为什么需要大文件分块上传与断点续传

在Web开发中，文件上传是一个常见需求。当文件体积较小时（比如几MB），传统的表单上传方式可以很好地工作。但当面对几百MB甚至GB级别的大文件时，传统上传方式就会暴露出诸多问题：

• 内存压力：服务器需要一次性接收整个文件，容易导致内存溢出
• 网络不稳定：长时间传输中网络中断会导致整个上传失败
• 用户体验差：用户需要重新上传整个文件，耗时耗力
• 服务器负载：大文件上传占用服务器资源时间长，影响其他请求处理

分块上传技术将大文件分割成多个小块（chunk），每次只上传一个小块。这样做的优势显而易见：

1. 降低单次请求的内存占用
2. 可以并行上传多个块提高速度
3. 某个块上传失败只需重传该块
4. 服务器可以边接收边存储，减轻内存压力

断点续传则是分块上传的延伸能力，它允许在上传中断后，从中断点继续上传而非重新开始。要实现这一点，系统需要：

• 记录已成功上传的块
• 验证每个块的完整性
• 在恢复上传时跳过已完成的块

2. JSP环境下分块上传的核心实现

2.1 前端分块处理

前端主要负责文件的分割和块管理。以下是关键实现步骤：

javascript复制// 获取文件对象
const file = document.getElementById('fileInput').files[0];
const chunkSize = 5 * 1024 * 1024; // 5MB每块
const totalChunks = Math.ceil(file.size / chunkSize);

// 文件分块
for (let chunkNumber = 0; chunkNumber < totalChunks; chunkNumber++) {
    const start = chunkNumber * chunkSize;
    const end = Math.min(start + chunkSize, file.size);
    const chunk = file.slice(start, end);
    
    // 为每个块创建FormData
    const formData = new FormData();
    formData.append('file', chunk);
    formData.append('chunkNumber', chunkNumber);
    formData.append('totalChunks', totalChunks);
    formData.append('fileId', generateFileId()); // 生成唯一文件标识
    
    // 发送分块
    uploadChunk(formData);
}

关键点：每个块需要包含足够的信息让服务器能正确重组文件，包括块序号、总块数和唯一文件ID。

2.2 后端接收与存储

JSP后端需要处理分块上传的请求，典型的Servlet实现如下：

java复制@WebServlet("/upload")
public class UploadServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) {
        Part filePart = request.getPart("file");
        int chunkNumber = Integer.parseInt(request.getParameter("chunkNumber"));
        int totalChunks = Integer.parseInt(request.getParameter("totalChunks"));
        String fileId = request.getParameter("fileId");
        
        // 创建临时目录存储分块
        String tempDir = getServletContext().getRealPath("/temp") + File.separator + fileId;
        new File(tempDir).mkdirs();
        
        // 保存分块
        String chunkFileName = tempDir + File.separator + chunkNumber;
        filePart.write(chunkFileName);
        
        // 检查是否所有分块都已上传
        if (isUploadComplete(tempDir, totalChunks)) {
            mergeFiles(tempDir, fileId, getOriginalFileName(request));
        }
    }
}

2.3 文件合并

当所有块上传完成后，需要将它们合并为完整文件：

java复制private void mergeFiles(String tempDir, String fileId, String originalFileName) throws IOException {
    File outputFile = new File(getServletContext().getRealPath("/uploads"), originalFileName);
    try (FileOutputStream fos = new FileOutputStream(outputFile)) {
        for (int i = 0; i < getTotalChunks(tempDir); i++) {
            File chunkFile = new File(tempDir, String.valueOf(i));
            Files.copy(chunkFile.toPath(), fos);
            chunkFile.delete(); // 合并后删除分块
        }
    }
    // 删除临时目录
    new File(tempDir).delete();
}

3. 断点续传的实现机制

3.1 上传状态记录

要实现断点续传，系统需要记录每个文件的上传进度。常见做法包括：

1. 数据库记录：为每个上传任务创建记录，存储已完成的块号
2. 文件系统标记：为每个块创建.ok文件标记完成
3. 内存缓存：适用于单机部署，使用Map存储进度

数据库方案示例：

sql复制CREATE TABLE upload_progress (
    file_id VARCHAR(64) PRIMARY KEY,
    file_name VARCHAR(255),
    total_chunks INT,
    uploaded_chunks TEXT, -- 存储已上传的块号，如"1,3,5"
    create_time DATETIME
);

3.2 续传流程

续传时前端需要先查询上传进度：

javascript复制function checkProgress(fileId) {
    return fetch(`/progress?fileId=${fileId}`)
        .then(response => response.json())
        .then(data => {
            return data.uploadedChunks; // 返回已上传的块号数组
        });
}

// 上传前检查
const uploadedChunks = await checkProgress(fileId);
for (let chunkNumber = 0; chunkNumber < totalChunks; chunkNumber++) {
    if (!uploadedChunks.includes(chunkNumber)) {
        // 只上传未完成的块
        uploadChunk(chunkNumber);
    }
}

后端查询接口实现：

java复制@WebServlet("/progress")
public class ProgressServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) {
        String fileId = request.getParameter("fileId");
        // 查询数据库获取已上传块
        List<Integer> uploadedChunks = queryUploadedChunks(fileId);
        
        response.setContentType("application/json");
        response.getWriter().write(
            new Gson().toJson(uploadedChunks));
    }
}

3.3 块完整性验证

为防止网络传输导致的块损坏，需要对每个块进行校验：

java复制// 前端计算块的MD5
function calculateChunkHash(chunk) {
    return new Promise(resolve => {
        const reader = new FileReader();
        reader.onload = e => {
            const hash = CryptoJS.MD5(CryptoJS.lib.WordArray.create(e.target.result));
            resolve(hash.toString());
        };
        reader.readAsArrayBuffer(chunk);
    });
}

// 发送时带上hash
formData.append('chunkHash', await calculateChunkHash(chunk));

// 后端验证
String clientHash = request.getParameter("chunkHash");
String serverHash = calculateMD5(chunkFile);
if (!serverHash.equals(clientHash)) {
    throw new RuntimeException("Chunk verification failed");
}

4. 性能优化与实际问题解决

4.1 并发上传控制

虽然并行上传能提高速度，但过多并发会导致浏览器和服务器压力过大。建议：

javascript复制// 控制并发数为3
const MAX_CONCURRENT = 3;
let currentUploading = 0;
const uploadQueue = [];

function processQueue() {
    while (currentUploading < MAX_CONCURRENT && uploadQueue.length) {
        currentUploading++;
        const task = uploadQueue.shift();
        task().finally(() => {
            currentUploading--;
            processQueue();
        });
    }
}

function enqueueUpload(chunkNumber) {
    uploadQueue.push(() => uploadChunk(chunkNumber));
    processQueue();
}

4.2 服务器端优化

1. 异步处理：合并大文件时使用后台线程，避免阻塞请求处理
2. 内存管理：使用流式处理而非全量读取文件
3. 临时文件清理：设置定时任务清理过期的未完成上传

java复制// 使用线程池处理文件合并
private ExecutorService mergeExecutor = Executors.newFixedThreadPool(2);

// 在doPost中
if (isUploadComplete(tempDir, totalChunks)) {
    mergeExecutor.submit(() -> {
        mergeFiles(tempDir, fileId, getOriginalFileName(request));
    });
}

4.3 常见问题与解决

1. 块顺序错乱：

   • 解决方案：服务器按块号排序后合并
   • 预防：前端按顺序发送，后端验证块号连续性

2. 临时文件堆积：

   • 解决方案：记录上传时间，定期清理超过24小时未完成的
   • 预防：客户端增加超时提醒

3. 文件名冲突：

   • 解决方案：使用UUID而非原始文件名存储
   • 预防：上传前检查文件是否存在

4. 网络抖动导致失败：

   • 解决方案：自动重试机制（最多3次）
   • 预防：减小块大小（如从5MB降到2MB）

5. 安全考虑与最佳实践

5.1 安全防护措施

1. 文件类型验证：

   java复制String fileName = getOriginalFileName(request);
   String extension = fileName.substring(fileName.lastIndexOf("."));
   if (!Arrays.asList(".jpg", ".png", ".pdf").contains(extension.toLowerCase())) {
       throw new SecurityException("Unsupported file type");
   }
   

2. 大小限制：

   xml复制<!-- web.xml中配置 -->
   <multipart-config>
       <max-file-size>1073741824</max-file-size> <!-- 1GB -->
       <max-request-size>1073741824</max-request-size>
   </multipart-config>
   

3. 权限控制：

   • 检查用户会话
   • 记录操作日志
   • 设置IP访问频率限制

5.2 生产环境建议

1. 使用专业存储：

   • 对于海量文件，考虑FastDFS、HDFS等分布式存储
   • 云服务如AWS S3、阿里云OSS提供成熟的分块上传API

2. 监控与报警：

   • 监控上传失败率
   • 设置磁盘空间预警
   • 记录慢上传请求

3. 客户端优化：

   • 显示详细进度条
   • 允许暂停/继续
   • 支持速度限制

6. 完整工作流程示例

6.1 正常上传流程

1. 用户选择文件（2.5GB视频）
2. 系统生成唯一fileId（如"vid_20230501_abc123"）
3. 前端将文件分割为500个5MB块
4. 开始并发上传（每次3个块）
5. 每上传成功一个块，服务器记录进度
6. 所有块上传完成后，服务器合并文件
7. 返回成功响应，提供文件访问URL

6.2 断点续传场景

1. 用户上传到第120块时网络中断
2. 重新连接后，前端查询上传进度
3. 服务器返回已上传的0-119块
4. 前端从第120块继续上传
5. 最终完成所有块上传
6. 服务器验证完整性后合并文件

6.3 异常处理流程

1. 第80块上传失败（3次重试后仍失败）
2. 系统暂停其他块上传
3. 提示用户网络状况不佳
4. 用户切换网络后继续上传
5. 系统跳过已成功的0-79块
6. 从第80块开始继续上传

在实际项目中实现JSP大文件分块上传和断点续传时，有几个经验值得特别注意：

1. 块大小选择：不是越小越好。太小的块会增加请求数量，太大的块会失去分块的意义。经过测试，2-5MB在大多数场景下表现最佳。

2. 临时存储策略：不要将临时文件和应用服务器放在同一磁盘，避免磁盘IO竞争影响应用性能。

3. 进度存储时效：上传进度记录应设置合理的过期时间（如7天），避免长期占用存储空间。

4. 客户端兼容性：某些老旧浏览器对File API支持不完整，需要做好降级方案，比如改用Flash或直接提示升级浏览器。