1. 异步导出服务概述
1.1 业务场景：为什么需要异步导出？
在企业级应用中，数据导出是最常见但最容易被低估性能压力的功能之一。典型的业务场景包括：
- 运营报表导出：月度订单明细、用户行为分析、财务流水，数据量通常在 10 万 ~ 500 万行。
- 审计日志归档：合规要求导出全量操作日志，时间跨度大，单次导出可能超过 1 GB。
- 数据迁移/备份：跨系统同步前的全量数据导出，对一致性要求高，执行时间长。
- 批量数据分发：向第三方合作伙伴提供定制化数据包，格式多样（CSV、Excel、Parquet）。
性能痛点：当单次导出数据量超过 10 万行或文件大小超过 50 MB 时，同步导出的 HTTP 连接超时、内存溢出、数据库连接池耗尽等问题会集中爆发。异步导出是解决这些问题的标准架构模式。
1.2 同步导出 vs 异步导出：性能对比
两种模式在用户体验、资源消耗和系统稳定性上存在显著差异。下表从 6 个关键维度进行对比：
| 对比维度 | 同步导出 | 异步导出 |
|---|---|---|
| 用户等待时间 | 请求发出后，浏览器/客户端一直等待，直到文件生成完毕 | 请求立即返回任务 ID，用户可离开页面，完成后通过通知/轮询获取 |
| HTTP 连接时长 | 长连接（可能超过 30s ~ 5min），容易触发网关超时 | 短连接（< 1s），仅返回任务凭证，无超时风险 |
| 内存占用 | 全量数据加载到内存后再写出，OOM 风险高 | 流式分页处理 + 磁盘暂存，内存可控 |
| 数据库压力 | 单次大查询锁表时间长，影响在线业务 | 分页查询 + 限速，对在线业务影响小 |
| 失败重试 | 失败后用户必须重新发起请求，之前进度丢失 | 支持断点续传或自动重试，任务状态持久化 |
| 并发能力 | 受限于 Web 服务器线程池，高并发时请求排队 | 任务队列缓冲，削峰填谷，支持大规模并发 |
关键指标：在 100 万行订单导出场景下，同步导出的平均响应时间为 47 秒，P99 达到 112 秒，而异步导出的任务提交耗时仅 120 毫秒，用户感知延迟降低 99.7%。
1.3 异步导出服务的核心架构组件
一个生产级的异步导出服务通常由以下 6 个核心组件构成，它们协同工作以保障高吞吐、高可用和可观测性。
1.4 组件交互流程
一次完整的异步导出请求经历以下 7 个步骤：
- 用户提交导出请求：携带查询条件、导出格式、文件命名等参数。
- 任务管理器创建任务：生成唯一任务 ID，初始状态为
PENDING，写入状态存储。 - 发布消息到 MQ：任务 ID 和必要参数序列化为消息，发送到导出专用队列。
- 立即返回任务 ID：API 网关向客户端返回
202 Accepted，响应体包含taskId。 - Worker 消费消息：从 MQ 拉取消息，更新任务状态为
RUNNING，开始分页查询数据。 - 流式写出文件：每查询一批数据（如 5000 行），立即写出到临时文件，释放内存。
- 任务完成：文件生成完毕后，更新状态为
SUCCESS，记录文件路径；用户通过taskId轮询获取下载链接。
常见陷阱：不要在 Worker 中一次性加载全量数据到内存再写出。即使使用异步架构，如果执行器内部采用“先查全量 List，再遍历写出”的方式，仍然会导致 OOM。必须使用游标分页或流式查询（如 MySQL
cursor、MyBatis fetchSize）。
1.5 异步导出的性能收益量化
以下数据来自某电商平台订单导出服务的实际压测结果（数据量：200 万行，格式：CSV，文件大小约 1.2 GB）：
| 指标 | 同步导出 | 异步导出 | 提升幅度 |
|---|---|---|---|
| 用户感知延迟 | 95 秒 | 150 毫秒 | 99.8% |
| Web 服务器最大连接数 | 200（全部被导出请求占用） | 5（仅用于提交请求） | 97.5% |
| 数据库连接池使用峰值 | 50 | 8 | 84% |
| 应用服务器 CPU 峰值 | 85% | 45% | 47% |
| 失败重试成功率 | 0%（需用户手动重试） | 92%（自动重试 3 次） | — |