web请求的本质设计目标
Web请求模型假设
发起 → 立刻完成 → 返回结果
核心点:
- HTTP是短连接/请求响应模型
- 面向交互而非计算任务
- 默认假设: 毫秒~秒级完成
如果耗时太长
- 浏览器默认超时
- 反向代理超时
- 负载均衡超时
- 网关超时
长任务的本质
发起 → 排队 → 执行 → 多阶段推进 → 完成
灾难性体验
如果使用web请求直接来做会发什么什么？
服务端:
如果一个任务要跑2分钟
- 长任务 = worker 被锁死
- 一个请求占一个 worker
用户端:
当页面一直都在加载，用户会怀疑是网卡了
很有可能继续刷新页面的操作，导致请求中断，浪费后端计算资源，前端的体验也不好
架构层面:
- 不能横向扩展
- 不能拆步骤
- 不能并行
- 不能调度优先级
如果一天 10 万个长任务怎么办？
怎么解决?（任务系统）
（任务系统）Task System
使用任务系统的好处
| 维度 | Web 同步 | 任务系统 |
|---|---|---|
| 超时 | 必然 | 无 |
| 并发 | 低 | 高 |
| 容错 | 无 | 强 |
| 可恢复 | 否 | 是 |
| 进度 | 无 | 有 |
| 扩展 | 困难 | 天生支持 |
任务角度
Task 是一种有状态的工作实体
请求是无状态的：
- 一断就没了
- 不关心过程
任务是有生命周期的:
CREATED
QUEUED
RUNNING
STEP_1_DONE
STEP_2_DONE
SUCCESS / FAILED / RETRYING
好处
- 排队(削峰)
高峰请求不压垮系统
- 解耦
触发者 ≠ 执行者
- 调度
- 并发限制
- 优先级
- 延迟执行
- 生命周期管理
状态 + 进度 + 审计
- 容错
- 自动重试
- 断点恢复
- 死信
- 拓展
机器随便加
架构设计
小例子
- chat-gpt 生成图片
前端隔一段时间向后端询问图片是否创建完毕，如果查询到结果就展示