FastAPI如何实现按客户端自定义超时规则处理请求及异步任务查询

优势 #

• 逻辑简单易落地，初期开发成本低，任务状态天然持久化，故障场景下不容易丢失任务数据
• API入口层和任务执行层完全解耦，两侧可独立扩容，执行器并发数可按需调整，不会因为任务堆积影响前端接口可用性
• 客户端适配规则统一，无论客户允许的超时时长是多少，都遵循「超时返回请求ID+轮询查状态」的规范，对接成本低

劣势 #

• 数据库压力过载风险极高：3000万日请求对应的日均任务新增量就有3000万条，再叠加API层轮询的查询量、执行器更新状态的写请求量，普通关系型数据库很容易出现慢查询、写瓶颈，直接拖垮全链路
• 响应效率差：API层定时轮询数据库的逻辑无法精准匹配任务完成时间，轮询间隔设置过短会进一步放大数据库压力，设置过长则会导致已经完成的任务无法及时返回，额外增加用户感知耗时
• 调度延迟高：执行器从数据库拉取任务的模式天然存在至少数百毫秒的调度延迟，对于允许超时仅为毫秒级的客户，很可能调度流程还没走完就已经触发超时，根本无法拿到实时返回结果
• 缺少会话绑定逻辑：原生方案没有关联用户身份和任务的规则，状态查询接口需要额外做权限校验，否则会出现用户越权查询他人任务的问题

你可以在原始方案的基础上做组件替换和逻辑优化，既满足超时控制、会话保持的需求，也能扛住3000万级的日请求量：

1. 身份校验与会话保持实现 #

• 提前把所有客户的身份凭证、允许的超时时长、会话信息存在Redis中，在FastAPI的依赖层统一做身份校验，校验通过后直接取出对应客户的超时阈值、用户ID作为上下文参数贯穿全链路
• 生成请求ID时直接关联对应用户ID，任务状态存储时也带上用户ID字段，用户调用查询接口时自动匹配任务所属的用户ID，没有权限直接返回错误，天然实现会话隔离

2. 任务调度层优化 #

• 把「数据库存任务+执行器拉取」的逻辑替换为内存消息队列+Redis存热状态的架构：用Redis Stream或者RabbitMQ做任务队列，调度延迟可压到毫秒级，完全满足短超时客户的调度需求
• 任务状态优先存在Redis中，key为请求ID，过期时间设置为任务保留最长周期（比如24小时），执行器执行完任务后直接把结果、状态（pending/done/error）更新到Redis对应key中，冷数据再异步归档到后端数据库，避免核心链路过载

3. 超时控制逻辑优化 #

• 替换API层轮询数据库的逻辑：API层把任务推送到队列后，直接按当前客户的超时阈值做异步等待，期间如果监听到Redis中对应任务的状态更新为终态，立刻把结果返回给用户；如果到了超时时间任务还未完成，直接返回请求ID即可，不需要额外轮询
• 可以针对客户的超时等级做队列优先级划分，毫秒级超时的客户任务进入高优先级队列，执行器优先消费，尽可能提升短超时任务的实时返回率

4. 状态查询接口优化 #

• /v5/check_request接口优先查Redis中的热状态，响应耗时可以压到1ms以内，只有当Redis中查不到对应的任务数据时，再去归档的冷数据库查询，完全扛住高并发查询请求
• 针对超时时长较长的客户，还可以额外支持Webhook回调能力，任务执行完成后主动推结果到客户预留的回调地址，省去用户轮询的成本

内容的提问来源于stack exchange，提问作者Ciganeshima