这是我的
serverless.yml
上 lambda 的配置:
sendXXX:
handler: functions/sendXXX/index.handler
timeout: 55
provisionedConcurrency: 1
events:
- schedule: rate(1 minute)
以下是相关的 Cloudwatch 日志:
2024-06-25T11:50:32.134Z START RequestId: c2cfe6d6-10d3-4520-8ef1-c82730103331 Version: 170
2024-06-25T11:50:35.698Z START RequestId: 3e331a19-31d9-4342-af21-fe0e7e023c6e Version: 170
2024-06-25T11:50:37.443Z END RequestId: c2cfe6d6-10d3-4520-8ef1-c82730103331
2024-06-25T11:50:37.443Z REPORT RequestId: c2cfe6d6-10d3-4520-8ef1-c82730103331 Duration: 5309.22 ms Billed Duration: 5310 ms Memory Size: 512 MB Max Memory Used: 328 MB
2024-06-25T11:50:38.330Z END RequestId: 3e331a19-31d9-4342-af21-fe0e7e023c6e
如您所见,请求
c2cfe6d6-10d3-4520-8ef1-c82730103331
于 11:50:32.134Z
开始。我预计下一个请求将在 11:51:32
左右开始,但仅在 3 秒后开始(在 11:50:35.698Z
)。我想知道为什么它会这样工作。
我尝试完全删除
provisionedConcurrency
设置并将 rate(1 minute)
时间表更改为 cron(* * * * ? *)
,但没有成功。我到底做错了什么?
是因为 lambda 有时会并发执行吗?如果是这样,有办法阻止吗?
如果我正确理解您的情况,您的 Lambda 函数正在由 EventBridge 计划(cron)调用。
据我所知,EventBridge 可以多次调用同一目标:https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-troubleshooting.html#eb-rule-triggered-more -比一次
我在 Amazon SQS 和 S3 事件中也经历过同样的行为。本质上,这些服务是分布式的,以保证至少一次交付。这意味着他们可能(并且将会)多次传递相同的消息或事件,从而会调用您的 lambda 函数两次甚至更多。
一般经验法则是确保您的代码可以处理重复的消息/事件。本博客解释了多种可能解决方案中的一种解决方案:https://aws.amazon.com/blogs/storage/manage-event-ordering-and-duplicate-events-with-amazon-s3-event-notifications/