Heroku出现H13错误：如何优化外部图片请求适配应用扩容？

问题根源 #

当前同步处理流程是触发H13错误的核心原因：用户提交请求后，服务器需等待图片下载、裁剪、AWS存储全流程完成才能响应，这类IO密集型操作极易超出Heroku的请求连接保持限制，高峰时段资源竞争加剧时，连接会被提前关闭，引发“connection closed without response”错误。

标准解决方案：异步任务队列架构 #

这是适配IO密集型请求扩容的通用优化方案，具体拆解为以下步骤：

1. 改造请求响应逻辑 #

• 服务器接收用户提交的页面信息后，立即将基础数据（标题、原网页URL、图片URL）存入Mongo，标记文档状态为processing，立刻返回202 Accepted响应给客户端，告知提交成功、图片正在处理。
• 彻底断开用户请求与耗时操作的绑定，避免客户端等待。

2. 引入消息队列缓冲任务 #

• 使用轻量型消息队列（比如Redis Queue），将图片处理参数（Mongo文档ID、图片URL、裁剪规格等）推入队列。Heroku可直接通过Redis add-on快速搭建队列服务。
• 队列负责平峰填谷，避免高峰时段请求直接压垮应用进程。

3. 用独立Worker进程处理异步任务 #

• 通过Heroku的Procfile配置独立Worker进程，专门监听消息队列：
  1. 取出任务后，根据图片URL发起GET请求下载图片（需加重试机制，应对目标站点临时不可用）
  2. 执行图片裁剪逻辑
  3. 将裁剪后的图片上传至AWS，获取存储链接
  4. 更新Mongo对应文档的状态为completed，填入最终图片链接
• Worker进程与Web服务进程隔离，不会占用Web请求线程资源，即便任务耗时久也不影响用户请求的响应速度。

4. 客户端同步处理结果 #

• 客户端收到202响应后，可通过轮询（定时请求查询文档状态）或WebSocket推送（任务完成后主动通知）获取最终图片链接。
• 简单场景下轮询即可满足需求，复杂场景用WebSocket可提升用户体验。

额外优化建议 #

• 给图片下载步骤设置超时（比如3秒）和重试次数（比如2次），避免单个慢请求卡住Worker进程。
• 根据应用规模调整Worker进程的并发数，防止Heroku资源过载。
• 配置死信队列，将处理失败的任务（如图片URL无效、AWS上传失败）转移至死信队列，方便后续排查和手动重试，避免阻塞正常任务。

内容的提问来源于stack exchange，提问作者Dashiell Rose Bark-Huss