我们注意到，建立一个AWS拉姆达时，从很多次触发发生分钟SQS触发，有时长达一个小时的延迟触发。我知道AWS拉姆达确实轮询内部，当队列为空，它可能会做一些指数退避。
但是，我们有运行，每30分钟将数据推入队列调度。然而，拉姆达引发很多很多后来的消息的百分比。我们的业务需求，它触发分钟内。
有没有办法迫使拉姆达始终如一地检查队列？另一种是采用步进功能，但这是不可能的，因为在这个线程另一个答案 - > How do you run functions in parallel?
我也想将数据推到S3和具有拉姆达触发从S3异步VS轮询，但S3没有一批API时，我们要推了很多的记录，以便出去了。
它被证明是错误的使用异步的使用AWS SDK时/等待。他们只支持.promise（）。那是不是所有的消息在SQS结束了的原因。
希望它可以帮助别人。 AWS正在研究一种新的SDK将支持异步/等待。这里是链接他们https://github.com/aws/aws-sdk-js-v3/issues/153#issuecomment-457769969
我会检查，以确保SQS要么拉长或短的拉动。
“在几乎所有情况下，亚马逊SQS长轮询是最好短轮询。长轮询请求让您的队列消费者，尽快为他们到达您的队列中，同时减少返回的空ReceiveMessageResponse实例的数量接收消息。
亚马逊SQS长轮询导致更高的性能在大多数情况下，使用成本降低。但是，如果你的应用程序需要从ReceiveMessage呼叫立即作出反应，你可能不能够利用长轮询的没有一些应用程序进行修改。
例如，如果您的应用程序使用一个线程来轮询多个队列，从短轮询切换到长轮询可能会无法正常工作，因为单个线程将等待任何空队列长查询超时，延缓任何队列的处理可能包含的信息。
在这种应用中，它是使用单个线程来处理只有一个队列，允许应用程序，以充分利用亚马逊SQS长轮询所带来的好处一个很好的做法。”
另外，如果你正在寻找火了你的lambda表达式，你能建立一个SNS通知系统的SQS？沿着SQS SNS LAMBDA线的东西。这应该让你分分钟你不经常拉队列中的消息。你只是做一个SNS。