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

问：

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

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

我考虑过的选项：

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

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

谢谢 John