1.1 异步任务概述
什么是异步任务
异步任务是一种非阻塞的执行模型：调用方发出任务请求后，不必等待任务完成即可继续执行后续逻辑，任务的实际处理由后台线程、进程或独立服务完成。在数据库（DB）场景中，异步任务通常用于将耗时的数据写入、批量计算、远程调用等操作从主请求链路中剥离，从而降低响应延迟、提升系统吞吐。
核心特征：调用方与执行方在时间上解耦，任务结果通过回调、轮询或消息通知获取。
同步 vs 异步：核心对比
| 对比维度 | 同步（Synchronous） | 异步（Asynchronous） |
|---|---|---|
| 调用方行为 | 发起调用后阻塞等待结果 | 发起调用后立即返回，不等待结果 |
| 资源占用 | 线程/连接在等待期间被占用 | 线程/连接可立即释放，用于处理其他请求 |
| 响应延迟 | 包含任务全部处理时间 | 仅包含任务入队时间，通常为毫秒级 |
| 系统吞吐 | 受限于线程池/连接池大小 | 可大幅提升并发处理能力 |
| 错误处理 | 调用方直接捕获异常 | 需通过回调、重试队列或死信处理 |
| 典型场景 | 简单 CRUD、实时查询 | 批量导入、报表生成、消息推送 |
实践建议：对于响应时间要求 < 50ms 的核心接口，优先使用同步；对于耗时 > 200ms 且允许最终一致性的操作，应设计为异步任务。
异步任务在 DB 场景中的价值
数据库是后端系统的核心状态存储，但直接在主请求路径中执行复杂 DB 操作会带来三个突出问题：
- 连接池耗尽：长事务或慢查询会长时间占用数据库连接，导致其他请求排队等待。
- 锁竞争加剧：大量并发写入同一张表或同一行，容易引发行锁、间隙锁甚至死锁。
- 响应时间膨胀：用户请求必须等待 DB 操作完成，体验随数据量增长急剧下降。
引入异步任务后，DB 场景获得以下关键收益：
- 削峰填谷：将突发写入压力平摊到更长的时间窗口，保护 DB 不被击穿。
- 资源隔离：异步任务使用独立的连接池和线程池，不影响实时查询的稳定性。
- 最终一致性：允许短暂的数据不一致，通过异步补偿机制保证最终正确。
- 可重试与容错：失败的任务可以自动重试或进入死信队列，避免数据丢失。
典型异步任务场景举例
| 场景 | 同步方案痛点 | 异步方案优势 |
|---|---|---|
| 批量数据导入 | 单次导入 10 万行，HTTP 超时 | 拆分批次异步写入，实时返回“已接收” |
| 报表/统计计算 | 聚合查询耗时 30s，阻塞用户 | 后台计算完成后推送通知 |
| 跨系统数据同步 | 依赖外部接口，响应不稳定 | 异步重试 + 幂等保证最终一致 |
| 日志/审计写入 | 每次请求都写日志，DB 压力大 | 批量刷盘，降低写入频率 |
注意：异步任务并非银弹。对于需要强一致性读、实时事务回滚的场景，盲目异步化会引入补偿复杂度。设计时需明确区分“可异步”与“必须同步”的边界。