![Lambda 调度陷入困境](https://linux22.com/image/729058/Lambda%20%E8%B0%83%E5%BA%A6%E9%99%B7%E5%85%A5%E5%9B%B0%E5%A2%83.png)
我有一个
- 批次大小为 1 的 SQS 队列
- 保留并发数为 1 的 Lambda 函数
- Lambda 配置为监听队列并在消息到达时执行一些工作。上述工作通常需要大约 8-12 秒,最多不超过 15 秒。
- 强调“倾听”,所以我不使用 Lambda 进行轮询,而是由 SQS 队列自动触发 Lambda。
我将 10 条消息放入队列,并期望 lambda 能够在合理(线性)时间内逐一处理这些消息,因为保留的并发数正好是 1,总共最多 150 秒。
实际情况是,前几条消息在合理的时间内得到处理,然后速度变得非常慢(15 分钟内没有明显进展)。SQS 队列声称所有 10 条消息都在“飞行中”,基本上将责任归咎于 Lambda 或其内部运行的代码。
有人经历过类似的行为吗?如果有,他们知道原因吗?
编辑 不同的测试也会出现同样的问题。例如,当保留并发数为 70 时,700 条消息被泵入队列(一次性,例如以机器速度),第 698 条消息需要大约 10-15 分钟才能让 Lambda 处理它。我通过日志验证了 Lambda 内部代码的执行确实不是需要 10-15 分钟(仅通常的 8-12 秒),所以一切似乎都指向 Lambda 函数没有得到应有的分配,但我目前无法证明/反驳这一点。
答案1
你的 Lambda 是由 SQS 触发或者 Lambda 一直在运行,并且民意调查 SQS?
触发通常更好 - 只要有消息到达队列,您的 Lambda 就会被调用
event
。每条消息调用一次 Lambda。如果你使用轮询你必须确保 Lambda 在退出时重新调度。你怎么做呢?15 分钟不活动和日程安排有关吗?