我有一个场景，我想使用SQS触发Lambda函数来索引Elasticsearch中的文档。我遇到的问题是，根据应用程序的活动，排队的消息数量从0到数十万不等。
为了避免压倒性的Elasticsearch，我需要限制并发运行的Lambda函数的数量。虽然我可以设置一个保留的并发性，但是当大量消息排队并且SQS轮询器的数量增加时，这将导致大量的限制。
我考虑过的选择：
1.* * 捕获阻塞消息（DLQ）并重新排队进行处理**。这看起来非常低效，并且消息可能被重新排队多次。
1.* * 设置随机消息定时器，人为节流**。同样，效率很低，因为即使它是队列中唯一的消息，也会引入人为的等待时间。一种变体是仅在重新排队被限制的消息时设置等待计时器。
1.* * 单个消息组id的FIFO队列**。当大量消息排队时，可能会超过FIFO队列的最大吞吐量。
1.* * 放弃'push'方法，使用CloudWatch Events调度Lambdas轮询队列**。需要实现更长的轮询时间（例如1分钟），因此可能需要更长的时间来处理消息。
1.* * 放弃push方式，使用传统worker示例**。它经过了测试和测试，可以控制并发/定时，但感觉我应该能够避免IaaS？!
我读了很多文章，但似乎没有任何干净的解决方案，这个问题，令人惊讶的是，因为我相信这是一个非常普遍的问题。如果我们可以设置SQS poller并发来匹配Lambda并发，那就太好了：）
谢谢，约翰