异步调用队列与SNS>SQS>Lambda

Question

该Archhit猜想完全依赖于lambda的异步调用机制，如下所述：

https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html

我有一个收集器函数，它每分钟调用一次，并获取一批大小变化很大的数据（几十KB到可能的1-3MB)。数据包含一个包含一对多记录的JSON数组。collector函数分离这些记录，并将它们单独发布到SNS主题。

一个解析器函数是SNS主题的次要函数，它的并发限制为3。SNS异步调用每条记录的解析器函数，这意味着当解析器的实例在3时最多时，内置的AWS托管的Lambda asyncronous队列开始填充。当发生节流时，Lambda排队机制在增量备份时启动重试，直到解析器函数可以处理调用请求。

在这个过程中，记录不会丢失是至关重要的，因为它们无法复活。我将在需要的地方使用死信队列，以确保它们最终在错误的情况下出现在某个地方。

测试此方法不会导致调用丢失。一切都按预期进行。Lambda报告了数百个throttle响应，但我依赖于此来启动异步调用的Lambda重试行为。我的理解是，如果我想重试使用来自SQS的消息，这种行为实际上与我必须自己开发和启动的行为相同。

即使函数没有返回错误，它也可能多次从Lambda接收相同的事件，因为队列本身最终是一致的。如果函数不能跟上传入的事件，事件也可能从队列中删除，而不发送到函数。确保您的函数代码能够优雅地处理重复事件，并且有足够的并发性来处理所有调用。

这意味着传入的调用可能只是凭空删除。同样，在我的实现中，我依赖于函数节流时的重试行为。

2.当消息在队列中时，超过消息超时会发生什么？

我找不到一个间接的答案，但我希望消息最终会在配置的死信队列中。

3.当SQS出现其他问题时，为什么要在Lambda队列上使用SQS？

有关SQS的参数，请参见下面的文章。过拉（在第二个链接中描述）特别令人担忧：

Answer 1

很有趣的问题。有一个演示文稿详细介绍了队列。我一时找不到。前提与此队列是漏桶相同

如果我增加更多的漏水桶又怎么样。我们会让你推迟泄漏，但它现在泄漏到另一个桶里。你解决了问题还是拖延了？

如果我用不同的频率振动水桶呢？

null