不止限流：构建一个健壮的异步任务准入系统
不止限流：构建一个健壮的异步任务准入系统
在现代后端应用中，处理耗时或资源密集型的操作（如文件转换、数据分析、AI 推理等）时，异步任务是保证系统响应能力和用户体验的关键。但随之而来的问题是：如何保护我们的后端系统，防止它被海量的任务请求所淹没？
很多人首先想到的可能是速率限流（Rate Limiting），比如“每分钟最多 100 个请求”。这在很多场景下行之有效，但对于异步任务，它可能不是最优解。想象一下，如果这 100 个任务每个都需要执行 10 分钟，我们的系统很快就会因资源耗尽而崩溃。
今天，我们将深入探讨一个更精细化的解决方案——并发准入控制（Concurrency Admission Control）。它关注的不是请求到来的“速率”，而是系统当前正在处理的“并发量”。本文将详细拆解一套结合了并发准入、请求去重和原子性锁的完整设计方案。
核心理念：三种保护机制，各司其职
在深入代码之前，我们必须清晰地辨别三个容易混淆的概念：
速率限流 (Rate Limiting)
- 做什么：限制在单位时间内可以通过的请求数量（QPS / RPM）。
- 好比是：一个旋转门，每秒只允许一个人通过。
- 适用场景：防止暴力破解、爬虫，或保护计算成本低的 API。
- 我们的现状：在核心的异步任务创建路径上，我们没有使用这种机制，因为它不关心任务的实际执行成本。
并发准入 (Concurrency Admission)
- 做什么：限制系统里“正在排队”和“正在执行”的任务总数。
- 好比是：一家餐厅只有 50 个座位。无论门口排队多快，只要满座，新来的客人就必须等待或被告知稍后再来。
- 适用场景：保护计算、I/O 或内存密集型的长任务，防止系统过载。
- 我们的现状：这是我们系统的核心机制，通过检查数据库中任务的状态来实现。
请求去重 (Request Deduplication)
- 做什么：对于内容完全相同的重复请求，在短时间内要么复用已有结果，要么阻止重复创建。
- 好比是：餐厅服务员看到你已经点了一份牛排正在做，就会告诉你“您的餐点已在准备，请勿重复下单”。
- 适用场景：防止用户因网络抖动或前端 Bug 而重复提交同一个任务。
- 我们的现状：通过对请求内容生成“指纹”并利用 Redis 实现。
一次请求的旅程：从 HTTP 到任务入队
为了理解这套系统是如何工作的，让我们跟随一个异步任务创建请求（例如POST /api/v1/conversions/pdf/tasks/），走完它的完整生命周期。
第 1 步：视图层的“快速预检”
当请求到达视图（View）层时，在执行任何耗时操作（如读取上传文件、写入临时存储）之前，我们会进行第一次容量检查：check_capacity()。
目的：尽早失败 (Fail Fast)。如果系统此刻已经饱和，我们应该立即返回HTTP 503 Service Unavailable，而不是浪费 CPU 和 I/O 去处理一个注定要被拒绝的请求。
第 2 步：独一无二的“请求指纹”
如果预检通过，请求会进入TaskService。在这里，我们首先要为它生成一个唯一的身份标识——请求指纹 (Request Fingerprint)。这个指纹是通过序列化请求的以下内容并计算哈希得到的：
- API 名称、路径、方法
- 请求参数和 Body
- 每个上传文件的字段名、类型、大小和 SHA256 哈希
这意味着，只要请求的内容有任何不同，指纹就会不同。
第 3 步：Redis 原子锁与防重复提交
生成指纹后，我们进入了整个流程中最关键的一步，它利用 Redis 的原子操作SETNX（在我们的代码中是cache.add）来防止竞态条件和重复创建。
- 尝试占位：我们以请求指纹为
key，尝试在 Redis 中写入一个临时的锁值。cache.add是原子性的，只有一个请求能成功。 - 占位成功：恭喜！你是第一个携带此指纹到达的请求。你获得了创建任务的“许可”，可以继续下一步。
- 占位失败：这意味着在几乎同一时间，另一个一模一样的请求已经抢先拿到了锁。此时，我们会再次检查数据库，看是否已经有一个可以复用的、最终成功的任务。如果没有，就直接向客户端抛出错误：“相同任务正在创建中，请稍后重试”。
这个机制优雅地解决了两个问题：
- 创建互斥：保证了对于完全相同的请求，只有一个能进入任务创建流程。
- 短期去重：在 TTL（比如 300 秒）内，后续的相同请求会被挡住或被引导去复用结果。
第 4 步：锁内的“最终检查”与事务性创建
成功拿到 Redis 锁之后，在真正向数据库写入数据之前，我们再次调用check_capacity()。
为什么需要二次检查？
这是一个经典的“检查-执行（Check-then-Act）”竞态问题。从“预检”通过到“获取锁”成功之间可能经过了几十到几百毫秒，这段时间里，系统的容量可能已经发生了变化。锁内的这次检查，才是真正权威的、决定性的准入判断。
如果最终检查也通过了：
- 在数据库事务中创建
AsyncTask记录。 - 将任务推入后台队列（如 Django-Q）。
- 更新 Redis 中的
key，将临时的“锁”值替换为最终的task_id，以便后续请求复用。 - 如果在任何一步失败，
catch异常并释放 Redis 锁，允许后续重试。
深入check_capacity：三层防御体系
我们的容量检查并非一个简单的全局计数，而是一个分层的、可配置的防御体系。检查会串行进行，任何一层失败都会立即中断并拒绝请求。
第一层：全局容量（按任务类型）
这是最基础的防线，我们为不同业务类型的任务设置了不同的容量池。
- 摘要任务池：统计所有
ai-summary类型的pending和running任务。 - 转换任务池：统计所有非
ai-summary的任务。
它们各自拥有独立的上限配置，例如：
ASYNC_TASK_MAX_RUNNING=4(最多 4 个转换任务在执行)ASYNC_TASK_MAX_PENDING=20(最多 20 个转换任务在排队)
第二层：API 维度（可选）
我们可以为特定的api_name（如pdf_service或ai_summary_service）设置更精细的并发上限。这在同一个系统承载多种不同重要性或资源消耗的业务时非常有用。该维度默认关闭，只有当ASYNC_TASK_MAX_PENDING_PER_API > 0时才会启用。
第三层：用户 IP 维度（可选）
为了防止单一用户滥用系统，我们还可以选择性地开启基于client_ip的并发限制。这会将来自同一个 IP 的所有异步任务（无论转换还是摘要）计算在内，施加一个总的并发上限。
结论：为稳定而设计
通过这套精心设计的准入系统，我们实现了远比传统速率限流更智能、更贴合业务实际的目标：
- 保护核心资源：我们的关注点从入口的请求速率转移到了系统内部实际的并发处理能力，这是保护数据库和计算资源的关键。
- 避免竞态条件：通过“预检 + Redis 原子锁 + 锁内再检”的模式，我们确保了准入决策的准确性和数据一致性。
- 提升用户体验：通过快速失败和明确的错误提示（如“系统繁忙”或“任务正在创建中”），我们为前端和客户端提供了清晰的指引，便于它们实现更智能的重试或状态轮询。
- 高度可配置：分层的检查机制和基于环境变量的配置，让我们能够灵活应对不同部署环境和业务发展阶段的容量需求。
最终，这套系统成为了我们异步任务处理链路前一道坚固而可靠的“防洪坝”，确保了整个系统的稳定运行。