如何在Lambda函数执行间添加延迟？适配电竞数据轮询场景

一、为什么Lambda末尾加time.sleep(2)不可行 #

Lambda中使用time.sleep(2)会导致两个核心问题：

• 并发触发的多赛事轮询请求会同时等待2秒，之后再次同步发起下一轮请求，完全无法解决请求互相干扰的问题；
• sleep期间Lambda实例处于运行状态但无实际业务处理，纯浪费计算资源和费用。

二、SQS+延迟队列的可行方案（推荐） #

利用SQS的延迟队列特性精准控制请求间隔，无需依赖time.sleep()：

• 将每场赛事的轮询任务封装为独立消息，首次发送到SQS标准队列时，设置DelaySeconds为1-2秒的随机值（避免集中请求）；
• 用Lambda作为SQS消费者，处理完当前轮询后，若赛事仍在进行，生成下一轮轮询消息，同样设置随机DelaySeconds后发回队列；
• 给每个赛事的消息添加唯一标识（如赛事ID），通过SQS的消息去重功能或DynamoDB状态记录，避免同一赛事的重复待处理消息，防止重复请求。
  这种方式下，SQS会独立控制每个请求的执行时间，不会出现并发请求同时触发的情况，且Lambda仅在处理请求时运行，无资源浪费。

三、AWS Step Functions是否大材小用？ #

并非大材小用，反而适配复杂轮询场景：

• 如果你的轮询逻辑需要失败重试、根据赛事状态动态调整间隔、多步骤数据处理等复杂流程，Step Functions的可视化编排和内置Wait状态能高效实现；
• 可通过Wait状态设置1-2秒的随机延迟，再用并行分支处理多场赛事，给每个分支的等待时间添加随机偏移即可避免同时请求；
• 对比SQS，Step Functions更适合需要多步骤任务编排的场景，SQS则更适配简单独立的轮询任务，可根据你的业务复杂度选择。

四、额外优化建议 #

• 延迟时间使用1-2秒的随机值，而非固定值，彻底规避多请求同时发起的可能；
• 用DynamoDB维护各赛事的最后请求时间，发起新请求前校验间隔，作为限流的额外防护层；
• 监听Leaguepedia API的限流响应，若触发限流则自动延长下一轮延迟时间或增加重试间隔。

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