AWS Lambda Python多线程：最优并行线程数设置咨询

一、多线程数怎么设才合理？ #

API调用是典型的I/O密集型任务，Python多线程完全够用（GIL在I/O阻塞时会自动释放，不会卡住线程），反而多进程在Lambda里会额外消耗启动时间和内存，完全没必要。设置线程数可以参考这几点：

• Lambda内存配置：Lambda的CPU和内存绑定，比如1792MB对应1vCPU，这种情况下线程数设10-20都没问题；如果是3008MB的高配，可提到20-30，但别盲目堆数，得结合后续限制调整。
• 目标API的限流规则：先查你要调用的API的Rate Limit，比如对方限制每秒最多100次请求，那线程数绝对不能超过这个阈值，轻则被限流，重则直接封号。
• Lambda的并发配额：AWS默认账户级Lambda并发是1000，单个函数如果没调过，并发也受这个限制，别让线程数导致函数并发超限。
• 实操经验：I/O密集任务的线程数一般是CPU核心数的5-10倍。Lambda的核心数随内存变化，比如512MB对应0.5vCPU，那线程数设5-10就行；也可以从10开始测试，慢慢调整，找到请求最快、成功率最高、资源不浪费的数值。

二、遗留代码里的9个进程到底为啥？ #

首先明确：I/O密集任务用多进程本身就不合理——多进程是给CPU密集型任务准备的，I/O密集场景下多线程效率高得多。至于这个数字9，大概率是这几种情况：

• 老Lambda配置的遗留：早期Lambda内存普遍偏低，比如512MB对应0.5vCPU，有人可能按老经验“CPU核心数×18”计算，0.5×18=9，就这么定了，但完全没考虑I/O密集的场景特性。
• 旧API的并发限制：可能当时目标API只允许同时9个请求，所以就设了9个进程，后来API放宽限制了，代码没同步更新。
• 拍脑袋的经验值：之前的开发者测了几个数值，发现9个进程在当时的环境下没出问题，就直接保留了，根本没多想多线程更合适。
• 纯随机的数字：也有可能就是随便挑了个接近10的整数，没有任何实际依据。

三、转多线程的实用建议 #

• 用concurrent.futures.ThreadPoolExecutor比手动管理线程省心多了，举个简单示例：

  from concurrent.futures import ThreadPoolExecutor
  import requests
  
  def fetch_api_data(url):
      try:
          resp = requests.get(url, timeout=10)
          resp.raise_for_status()
          return resp.json()
      except Exception as e:
          return {"error": str(e)}
  
  def lambda_handler(event, context):
      # 生成待调用的API列表
      api_urls = [f"https://your-target-api.com/item/{i}" for i in range(1000)]
      # 根据实际情况调整max_workers
      with ThreadPoolExecutor(max_workers=15) as executor:
          results = list(executor.map(fetch_api_data, api_urls))
      return {"total": len(results), "success": sum(1 for r in results if "error" not in r)}
  

• 一定要加异常捕获，不然单个请求失败可能搞崩整个线程池。
• 上线后查看Lambda的日志和CloudWatch指标（比如执行时长、并发数），根据实际运行情况调整线程数，别死磕某个固定数值。

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