限制从 AWS SQS 触发的 AWS Lambda 的并发调用(忽略保留并发)?

Ade*_*ost 5 amazon-web-services aws-lambda

对我来说,当我开始时,这似乎是一个简单的用例,但结果比我预期的要困难得多。

问题

我有一个 AWS SQS 作为触发工作线程 AWS Lambda 的作业队列。然而,由于工作 lambdas 共享不可扩展的资源,因此将并发运行的 lambdas 的数量限制为(例如)不超过 5 个同时运行的 lambdas 是很重要的。

根据Lambda 函数的并发管理,足够简单

预留并发也限制了函数的最大并发,适用于整个函数

但是,将Reserved concurrency-property设置为 5 似乎完全被 SQS 忽略,Messages in Flight在我的例子中, queue -property 根据放入队列的消息数量显示接近 20-30 个并发执行。

我最接近的解决方案是使用 SQS FIFO 队列并将MessageGroupId设置为随机选择或在 1-5 之间交替的值。但是,由于工作负载不均匀,这不是最佳选择,因为最好按实际工作负载而不是偶然分配并发。

我还尝试使用 AWS Step Functions,因为Map-state有一个 MaxConcurrency 参数,它似乎在小型作业队列上运行良好,但由于每个状态的输入/输出限制为 32kb,这在我的使用中不可行-案件。

有没有人找到更好的或替代的解决方案?还有其他方法Reserved concurrency应该使用吗?

相似的

以下是我发现的一些类似问题,但我认为我的问题不同,因为我对限制调用总数不感兴趣,并且(虽然我自己没有尝试过)我不明白为什么从 S3 或 Kinesis Steam 触发会表现得与 SQS 不同。

Moo*_*ose 1

根据AWS文档,AWS SQS不考虑保留并发性。如果要处理的批次数量大于保留并发数,您的消息可能最终会出现在死信队列中:

如果您的函数返回错误,或者由于达到最大并发而无法调用,则通过额外尝试处理可能会成功。为了让消息在发送到死信队列之前有更好的处理机会,请将源队列的重新驱动策略上的 maxReceiveCount 设置为至少 5。 https://docs.aws.amazon.com/lambda/latest/dg /with-sqs.html

您可以查看这篇文章了解详细信息:https://zaccharles.medium.com/lambda-concurrency-limits-and-sqs-triggers-dont-mix-well-sometimes-eb23d90122e0