格式转换流水线

上传一张图要等 12 秒

有损压缩和无损压缩的策略都搞定了。我把代码合并到上传流程里，满怀期待地测试了一下。

结果：用户上传一张 8.7MB 的图片后，要等 12 秒才能看到”上传成功”。

上传耗时分解：
  1. 客户端直传 OSS：                    2s
  2. 回调通知服务器：                    0.1s
  3. 服务器下载 OSS 原图到本地：          1.5s
  4. 智能分析内容类型：                   0.3s
  5. 生成 3 种尺寸 × 2 种格式 = 6 个文件： 6s
  6. 上传 6 个文件到 OSS：               2s
  总计：                                  12s

用户上传图片时盯着一个 loading 动画等 12 秒？不可接受。

问题出在哪？第 3~6 步都是同步执行的，阻塞了上传接口的返回。

解法很明确：上传归上传，处理归处理。异步化。

异步处理架构

核心思路：

之前（同步）：
  用户上传 → OSS → 回调 → 下载 → 压缩 × 6 → 上传 OSS → 返回（12秒）

之后（异步）：
  用户上传 → OSS → 回调 → 丢消息队列 → 立即返回（0.5秒）
                                      ↓
                               Worker 消费 → 下载 → 压缩 × 6 → 上传 OSS → 通知完成

修改上传回调接口，把处理任务丢到队列后立即返回：

效果：上传回调接口从 12 秒降到了 0.3 秒。

Worker：并行生成多格式多尺寸

Worker 从队列中消费任务，并行处理：

前端进度通知

用户上传后立即返回”处理中”，前端通过轮询或 WebSocket 获取处理进度：

后端轮询接口：

处理进度优化：分阶段通知

一张图要生成 6~10 个衍生图，每完成一个都可以通知前端：

前端展示更细粒度的进度：

错误处理和重试

异步处理带来了新的挑战——Worker 可能崩溃、任务可能失败。需要健壮的重试机制：

处理性能优化

一张图生成 6~10 个衍生图，如何更快？