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

Question

背景

此架构仅依赖于 Lambda 的异步调用机制，如下所述：

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

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

解析器函数是 SNS 主题的子类，并发限制为 3。SNS 异步调用每条记录的解析器函数，这意味着随着解析器实例的最大值，内置 AWS 托管 Lambda 异步队列开始填满在 3 点结束。当发生限制时，Lambda 排队机制会在增量备份时启动重试，直到解析器函数可以处理调用请求。

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

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

问题

1.内置的 AWS 托管的 Lambda 异步队列可靠吗？

解析器可能会在很长一段时间内承受每分钟 200 多次调用的一致负载，因此我想了解 Lambda 队列是否可以像 SQS 服务一样明智地处理这个问题。我关心的主要部分是这样的声明：

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

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

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

我找不到明确的答案，但我希望消息最终会出现在配置的死信队列中。

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

有关反对 SQS 的论据，请参阅以下文章。过度拉动（在第二个链接中描述）特别值得关注：

https://lumigo.io/blog/sqs-and-lambda-the-missing-guide-on-failure-modes/

https://medium.com/@zaccharles/lambda-concurrency-limits-and-sqs-triggers-dont-mix-well-sometimes-eb23d90122e0

我找不到任何关于 Lambda 队列如何执行的文章或讨论。

感谢阅读！

Answer 1

我认为使用您自己的队列的最大优势在于您作为用户可以了解您的背压状态。

使用 Lambda 异步调用方法，您有可能获得受限制的异常，并保证 lambda 将在一段时间内重试。如果改用 SQS 源队列，则您可以随时了解消息处理的状态，没有任何歧义。

其次是关于过度拉动。理论上这是一个问题，但实际上它从未发生在我身上。我已经运行了每秒需要数千个事务的应用程序，并且从未遇到过 SQS -> Lambda 的问题。显然，适当地设置您的重试策略并使用 DLQ，因为可能会发生暂时/不可预测的错误。

Answer 2

非常有趣的问题。有一个演示文稿详细介绍了队列。我暂时找不到。前提和这个queues are leaky buckets一样

那么，如果我添加更多漏桶会怎样。我们会延迟泄漏，但它现在正在泄漏到另一个存储桶中。您解决了问题还是推迟了问题？

如果我在不同的frequencies 振动桶会怎样？

进一步阅读：

• operate lambda
• message expiry
• message timeout
• DDIA / DDIA Online
• SQS Performance
• sqs failure modes
• 此问题中缺少mvce，因此我无法解决您遇到的确切问题。
• 关于选择 SQS 和 Lambda 队列的意见，我将指向 Meta on this
• sqs faq 提到 Kinesis 流
• sqs sns kinesis comparison

TL;DR;

视情况而定