1. 项目背景与核心挑战

最近在金融数据报表项目中遇到一个棘手问题：需要从千万级数据库记录生成Excel报表供业务部门下载。初期采用传统POI方案，在数据量超过50万行时频繁出现内存溢出（OOM），导出时间超过30分钟，用户体验极差。更糟的是同步导出会阻塞主线程，导致系统响应延迟飙升。

经过多次压力测试和方案对比，最终落地了一套基于"异步任务+EasyExcel+MinIO"的高性能导出架构。实测单机环境下可稳定处理300万行数据（约1.2GB Excel文件），平均耗时控制在8分钟以内，且系统资源占用率下降70%。下面分享具体实现细节和踩坑经验。

2. 技术选型与架构设计

2.1 核心组件对比

2.2 系统架构流程图

[用户请求] -> [API网关] -> [异步任务服务] -> [DB分页查询] -> [EasyExcel写入] -> [MinIO存储] -> [WebSocket通知] -> [用户下载]

关键设计原则：

1. 读写分离：导出过程与业务系统完全解耦
2. 分治策略：采用分页查询避免大结果集内存溢出
3. 事件驱动：各模块通过事件机制松散耦合

3. 核心实现细节

3.1 EasyExcel优化配置

// 百万级数据导出模板 ExcelWriterBuilder writerBuilder = EasyExcel.write(outputStream) .registerWriteHandler(new LongestMatchColumnWidthStyleStrategy()) // 自动列宽 .registerWriteHandler(new CustomCellWriteHandler()) // 自定义样式 .compressionLevel(Deflater.BEST_SPEED) // 压缩加速 .useDefaultStyle(false) // 禁用默认样式提升性能 .autoCloseStream(false); // 保持流开启 // 分页写入数据 for (int page = 0; page < totalPage; page++) { List<DataDTO> batch = queryBatch(page, PAGE_SIZE); writerBuilder.sheet().doWrite(batch); }

重要提示：必须设置.autoCloseStream(false)，否则MinIO上传时会报流已关闭错误

3.2 分页查询技巧

-- 优化后的分页查询（避免深分页） SELECT * FROM report_data WHERE id > #{lastId} ORDER BY id ASC LIMIT #{pageSize}

实测对比：

• 传统LIMIT分页：100万数据导出耗时22分钟
• 游标分页：相同数据量耗时降至9分钟

3.3 MinIO集成要点

# 生产级配置参数 minio: endpoint: http://cluster.minio:9000 access-key: ${ENV_MINIO_KEY} secret-key: ${ENV_MINIO_SECRET} bucket: excel-export expiration: 86400 # 文件保留24小时 part-size: 5242880 # 分片上传大小(5MB)

上传优化技巧：

// 使用分片上传大文件 InputStream excelStream = ...; minioClient.putObject( PutObjectArgs.builder() .bucket("excel-export") .object(fileName) .stream(excelStream, -1, 5 * 1024 * 1024) // -1表示未知大小 .contentType("application/vnd.ms-excel") .build());

4. 性能压测数据

测试环境：

• 4核CPU/8GB内存
• MySQL 8.0
• MinIO集群（3节点）

5. 典型问题排查实录

5.1 内存泄漏问题

现象：导出10次后老年代内存持续增长不释放
定位：MAT分析发现ThreadLocal未清理
解决：

// 在finally块中显式清理 try { excelWriter = EasyExcel.write(...).build(); // ... } finally { if (excelWriter != null) { excelWriter.finish(); // 必须调用！ } }

5.2 文件上传中断

现象：300MB以上文件上传失败
原因：MinIO默认分片大小不适配
优化：

minioClient.putObject( PutObjectArgs.builder() .stream(inputStream, fileSize, 15 * 1024 * 1024) // 调整分片大小 // ... .build());

5.3 数据库连接耗尽

现象：高并发时出现ConnectionTimeout
方案：

1. 采用HikariCP连接池
2. 设置合理隔离级别

spring.datasource.hikari.maximum-pool-size=20 spring.datasource.hikari.isolation-level=READ_COMMITTED

6. 生产环境增强建议

1. 熔断保护：当队列积压超过阈值时，拒绝新请求

@Bean public ThreadPoolTaskExecutor exportExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setQueueCapacity(100); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy()); return executor; }

2. 安全控制：

• 添加IP白名单限制
• 文件下载URL设置时效签名

String url = minioClient.getPresignedObjectUrl( GetPresignedObjectUrlArgs.builder() .expiry(30, TimeUnit.MINUTES) // 30分钟有效 .method(Method.GET) // ... .build());

3. 监控看板：

• Prometheus监控指标：
  • export_task_active_count
  • export_time_seconds
  • export_file_size_bytes

这套方案已在生产环境稳定运行9个月，日均处理导出请求300+次。关键收获是：对于大数据量操作，一定要遵循"分而治之"原则，同时合理利用现代中间件的特性。最近正在尝试结合ClickHouse进一步提升查询性能，有兴趣可以一起探讨。