AWS Lambda并发限制内长请求阻塞短请求的原因及解决方法咨询

原因分析 #

1. Node.js单线程事件循环阻塞 #

你的Node.js Lambda基于单线程事件循环模型运行，如果webscraping代码是同步阻塞操作（比如用了非异步爬虫库、没正确用async/await处理异步请求），会完全占用该Lambda实例的唯一执行线程。同一实例内的所有后续请求（包括那个10秒的快捷端点）都会被卡在事件循环队列里，必须等长请求执行完毕才能处理。

2. Lambda实例调度逻辑 #

Lambda会优先复用已有空闲实例处理新请求，当30个长请求占用一批实例后，新的快捷请求可能被调度到已经被长请求阻塞的实例上，而非立即启动新实例。虽然你的并发上限是1000，但Lambda的调度是按负载逐步扩容的，只有当现有实例无法处理新请求时才会启动新实例，这个过程存在延迟，最终导致快捷请求排队等待。

解决方案 #

1. 修复webscraping的异步代码 #

确保所有爬虫操作都使用异步IO，完全释放Node.js事件循环：

• 用async/await包装所有异步调用（比如axios.get()、puppeteer的page.goto()等）
• 杜绝使用任何阻塞线程的同步API（比如fs.readFileSync、同步版爬虫工具）
  调整后同一Lambda实例可同时处理多个请求，快捷请求不会被长请求卡住。

2. 拆分Lambda函数（最彻底方案） #

把长耗时的webscraping端点和快捷端点拆成两个独立的Lambda函数：

• 两者拥有独立的并发资源和实例池，长请求的实例不会占用快捷请求的资源
• 可分别配置不同的内存、超时时间等参数，更贴合各自业务需求

3. 强制实例隔离（可选） #

如果不想拆分函数，可通过以下方式让Lambda尽可能为新请求启动新实例：

• 配置provisioned concurrency（预配置并发），提前启动足够多的实例应对长请求
• 为函数设置reserved concurrency，预留一部分实例专门处理快捷请求（需精准估算所需数量）

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