来自SQS的AWSLambda轮询：实时消息计数

我在SQS队列中有20K消息。我也有一个lambda将处理SQS消息，并将数据放入ElasticSearch服务器。

我已将SQS配置为lambda的触发器，并将Lambda的SQS批处理大小限制为10。我还限制了lambda的一个实例只能在给定时间运行。

但是，有时我in-flight messages从AWS控制台看到超过1万。最多可发送10条机上消息吗？

因此，lambda仅能正确处理9K的SQS消息。

下面的屏幕截图显示了我已将lambda限制为在给定时间仅运行1个实例。

我一直在进行一些测试，并同时联系AWS技术支持。

我目前相信的是：

Amazon Simple Queue Service支持5个并发函数调用的初始突发，并且每分钟增加60个并发调用的并发性。文件

1 /进行合并的东西是一个单独的实体。最有可能是lambda函数，它将使SQS长时间处于池中，然后调用我们的lambda函数。

2 / Pool-Lambda根本不考虑我们的任何Receiver-Lambda。不在乎该功能是否以最大容量运行，或者Receiver-Lambda有多少最大并发可用

3 /由于这种结合。这种行为不是我们从Lambda-SQS集成中所期望的。更糟糕的是，如果突然，队列中爆发了数百万条消息。Receiver-Lambda并发永远无法赶上pooling-Lambda发送的消息量，从而导致工作丢失

考试：

创建一个需要30秒才能返回true的Lambda函数；

将该函数的并发设置为50；

将300条消息推送到队列中（可见性超时：10分钟，批消息计数：1，不重新驱动）

结果：

可用消息量逐渐增加

最初，Receiver-Lambda处理的消息很少

半分钟后，可用消息超出了Receiver-Lambda的处理能力

这些消息将被丢弃到死队列中。由于Pool-Lambda无法调用Receiver-Lambda

得到AWS支持人员的确认后，我将立即更新此答案

支持答案。截至2019年第一季度，TL; DR版本

1 /假设是正确的，有一个“投票者”

2 / Poller在其算法中并未考虑保留并发

3 /轮询者的硬限制为1000

2019年第二季度：

以上信息需要更新。支持人员说，轮询器正确考虑了保留的并发性，但应至少为5。SQS-Lambda集成仍在更新中，并且此答案不会。因此，如果您遇到一些奇怪的问题，请咨询AWS