解决SQS Lambda突发时的过度轮询

我有一个场景，我想使用 SQS 触发 Lambda 函数来索引 Elasticsearch 中的文档。我遇到的问题是，排队的消息数量范围从 0 到数十万，具体取决于应用程序活动。

为了避免 Elasticsearch 不堪重负，我需要限制并发运行的 Lambda 函数数量。虽然我可以设置保留并发，但当大量消息排队且 SQS 轮询器数量增加时，这将导致大量限制。

我考虑过的选项：

捕获受限消息 (DLQ) 并重新排队进行处理。这看起来效率极低，消息可能会被重新排队很多次。
设置随机消息计时器来人为节流。同样，效率非常低，因为即使它是队列中唯一的消息，它也会引入人为的等待时间。一种变体是仅在重新排队受限制的消息时设置等待计时器。
具有单个消息组 ID 的 FIFO 队列。当大量消息排队时，可能会超出 FIFO 队列的最大吞吐量。
放弃“推送”方法并安排 Lambda 使用 CloudWatch Events 轮询队列。需要实现更长的轮询时间（例如 1 分钟），因此可能需要更长的时间来处理消息。
放弃‘push’方式，使用传统的worker实例。它已经过尝试和测试，并且可以控制并发/时序，但感觉我应该能够避免 IaaS？！

我读过很多文章，但令人惊讶的是，似乎没有任何干净的解决方案来解决这个问题，因为我确信这是一个非常常见的问题。如果我们可以将 SQS 轮询器并发设置为与 Lambda 并发相匹配，那就太好了:)

谢谢，约翰

0
投票

AWS 发布了一项新功能，允许设置 MaxConcurrency，这将限制 SQS 触发的并发 Lambda 数量：

0
投票

我没有足够的 Karma 来评论上面的答案，只是想说要注意 Lambda 并发限制（每个帐户），因为 MaxConcurrency 不会自动调整到实际可用并发带宽。您可能有足够的空间，在这种情况下 MaxConcurrency 就可以了。