缩略图/视频转码、发邮件/推送、生成报表、调用慢的第三方 API、批量数据处理——这些不需要在当前请求里同步返回结果，放后台既能秒返、又能独立扩容。
数据与服务 · 运行与可靠性
后台任务Worker
把耗时工作放进可追踪队列，由 worker 在请求路径之外领取、处理并汇报进度与恢复状态。
试一遍：上传、领取、推进、失败与死信
点「上传图片」只入队、立即返回 202 + jobId，worker 还没动手；再点「worker 处理一帧」让后台逐帧推进，缩略图长在任务卡上。注入失败看退避重试，3 次后进死信——慢工作不阻塞请求，状态全程可查。
点「上传图片」→ 请求立即返回 202 + jobId，worker 还没动手；再点「worker 处理一帧」让后台领取并推进。注入失败看退避重试，3 次后进死信。
POST /upload主请求 · 不等处理尚未上传worker · 任务板
- 0queued
- 0running
- 0done
- 0failed
- 0dead
队列空：worker 空闲等待。点「上传图片」入队第一个缩略图任务。
队列空。点「上传图片」入一个缩略图任务——请求会立即返回 202 + jobId，不等处理。原因：worker 把慢工作移出请求路径；下一步：再点「worker 处理一帧」让后台领取。
worker 要盯住的几件事
面板里已经见过，这里只命名：入队返回、领取处理、进度可查、退避重试、幂等、死信。
- 入队即返回 202
主请求只创建 JOB、写队列、返回 jobId（面板里「上传图片」瞬间出现 202 + jobId）；慢工作由 worker 在请求路径之外做——请求快、后台慢。
- worker 拉取并逐帧处理
worker 从队列拉取 JOB、按帧推进进度（面板里点「worker 处理一帧」0→25→…→100%）；它是事件/队列触发，没有 JOB 就空闲，与按时间触发的 cron 不同。
- 状态全程可查
JOB 有明确状态 queued/running/done/failed 和进度（面板任务卡上的徽章与进度条）；客户端能轮询 jobId 或收事件拿结果，不用瞎等。
- 失败退避重试 + 死信
处理失败标记 failed、按指数退避重新入队（面板「退避后重试」）；超过最大次数进死信停止自动重试，等人工或告警，不静默丢也不无限重试。
- 重试必须幂等
worker 可能崩溃后重投同一 JOB，所以处理逻辑要幂等——同一 jobId 处理多次只生成一张缩略图，靠业务键或 jobId 去重。
什么时候用 worker
从用户信号开始：有耗时且不需同步返回结果的工作。
需要立即同步返回结果（用同步 RPC）、按时间触发而非事件触发（用 cron）、流量削峰但不需要后台处理逻辑（用 queue 即可，worker 消费 queue）。
怎么用才不出错
从入队到死信的最短路径，每一步都要可观测、可恢复。
- 请求校验后创建幂等 jobId、入队，立即返回 202 + jobId，绝不等待处理完成。
- worker 从队列拉取 JOB，更新状态 queued → running，逐帧推进进度并上报。
- 给单任务设资源上限（CPU/内存/最长执行时间）；超限的 JOB 视同失败，避免一个任务拖垮 worker。
- 处理失败按指数退避重试，重试逻辑幂等；超过最大次数进死信并告警，人工处理而非无限重试。
- worker 可独立于 web 服务器扩容：队列积压深就加 worker 实例；监控队列长度、处理耗时、失败率与死信积压。
同一目标的两条路
正例把缩略图移出请求、后台逐帧做；反例同步塞进请求，大图把接口拖到超时。
上传接口校验文件后只把缩略图 JOB 入队、立即返回 jobId；worker 在后台限制 CPU/内存逐帧生成，客户端轮询或收事件拿进度与成品 URL。大图再多也不拖垮接口，worker 还能独立扩容。
差异：以「请求只入队、后台慢做、进度可查」为目标。上传请求里直接同步调用图片库处理大图，等处理完才返回。一张大图就把请求拖到 30s 超时，用户看到 5xx；并发几张就把整个 web 进程的线程占满，其它请求也跟着挂。
差异：慢工作塞进请求，超时拖垮接口，无法独立扩容。快速自测
缩略图 worker 任务连续失败达到 3 次后，最该进入什么状态？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。