为后台工作进程提供有界预算

定义一单位有用工作

对于内部 CSV 导出，请求会创建一个导出记录；工作进程读取有界数据集，写入输出对象并将记录标记为完成。定义最大有用范围、时间限制和取消行为。使用隔离的队列、测试数据库和无法通知真实客户的目标位置。

将计算时间与数据库和存储等待分开。单一作业持续时间数字掩盖了这些区别。在内存中构建整个文件与流式处理有界批次具有不同的扩展特性。保持队列消息足够小，以描述工作而不嵌入客户数据或凭据。

通过设计使重复投递安全

使用持久导出标识符将多次尝试关联到一个逻辑结果。在持久状态中强制唯一性以及原子性的所有权/完成转换。先检查导出是否存在，然后在单独的无保护步骤中插入，会让并发尝试产生竞态。发布对象和确认队列消息也构成一个故障边界。

# Illustrative contract, not queue implementation
job_type: export-account-report
logical_result: EXPORT_RECORD_ID
input_scope: AUTHORIZED_ACCOUNT_AND_DATE_RANGE
attempt_limit: REVIEWED_FINITE_LIMIT
completion: ONE_PUBLISHED_RESULT_FOR_THIS_EXPORT
retry: CLASSIFIED_TRANSIENT_FAILURES_ONLY
failed_result: INSPECTABLE_WITHOUT_CUSTOMER_SECRETS

Celery 将延迟确认与幂等任务联系起来，并记录了子进程终止后仍会发生确认的情况。队列选项不会创造恰好一次执行。请审查系统的重投递语义，并将应用结果设计为能够容忍重试。

技术参考： Celery 任务行为.

在增加进程之前设定预算

对于假设每个活动导出使用 300 MiB 的工作进程，四个同时导出在运行时开销之前就已意味着约 1,200 MiB。这些是规划输入，而非基准。还要加上数据库连接、查询内存、临时磁盘和输出带宽；进程数量只是其中一个限制。

用一个活动导出和真实积压进行预演。在重复相同 API 流量的同时增加到两个。比较完成的有用导出数、最旧作业年龄、延迟、失败和主机压力。如果吞吐量几乎没有改善而数据库等待增加，请停止增加并发度。额外的 CPU 可能无法消除该瓶颈。

阻止故障产生更多负载

在重试之前对错误进行分类。临时存储中断可能是暂时性的；未授权账户或不支持的导出格式需要终止性错误或人工干预。使用有限的尝试预算，并在支持的情况下使用带退避和抖动的延迟重试。保持失败作业可供检查，并移除敏感字段。

对外部调用应用超时机制，并设置整体任务预算。放弃一次尝试并不证明其远程副作用没有发生。超时退出的发布可能已经写入了输出。应通过导出 ID 进行对账，而不是盲目再发布另一个结果。

将工作进程纳入部署和恢复

使用旧工作线程文档化的关闭行为，停止在其上启动新工作。让进行中的工作完成，或在已知截止时间内安全地中断它。测试在输出已写入但完成状态尚未记录后发生的崩溃；替换尝试应找到一致的结果而非重复它。

保持跨重叠发布的消息格式兼容。新 API 可能入队旧工作线程无法读取的负载。为契约设定版本或编排发布顺序，确保新消息出现前已有受支持的消费者。将这些数据库写入方纳入 模式兼容性审查.

选择下一个要更改的约束

留下并发设置、重试策略、任务契约和可度量的停止规则。如果昂贵的导出拖慢了小任务，在提高全局限制前，考虑使用具有独立预算的分离队列。如果在任何现实的导出负载下 API 延迟受损，分离工作线程可能比扩大一个共享主机更有用。

在变更后重复相同的工作负载并保留对比。 escenario de API y workers 解释了 App 2 和额外内存在选择中的介入点。这些流程并不意味着托管队列、无限任务或自动扩展。