SNS 到 Lambda vs SNS 到 SQS 到 Lambda

我试图理解我是否需要 SQS 在我的工作流程中，如果有人可以帮助解释。在我的应用程序中，当采取行动时，它向 SNS 主题提交信息，该主题调用 Lambda 进行一些处理。现在这样效果就很好。

当我在网上做研究时，似乎人们在这个栈中也使用了 SQS，SNS 将把信息放在 SQS 上，然后 SQS 将调用 Lambda。

我想我试图理解的是 SQS 在这方面的需要。这会增加什么价值？换句话说，直接从 SNS 调用我的 Lambda 会损失什么呢？

28609 次浏览
小开

SQS 不调用 Lambda。SQS 不能调用任何东西。使用带有 SQS 的 Lambda 的人在事件计时器上运行 Lambda，比如每分钟一次，每次运行该函数都会轮询 SQS，以查看是否有要处理的消息。

如果您不需要将事情排队并防止太多 Lambda 函数并发运行，那么您就不需要 SQS 这样的队列系统。

小开
最佳答案

在 SNS 和 Lambda 之间有一个 SQS 的主要优点是再处理。 假设 Lambda 由于某些原因无法处理某些事件(例如超时或内存占用不足) ，你可以增加超时(最大5分钟)或内存(最大1.5 GB)并重新启动轮询，你可以重新处理旧的事件。

这是不可能的情况下 SNS 到 Lambda，其中如果 Lambda 失败的事件是丢失。即使您配置了 DLQ，您仍然必须为分别读取和处理消息做好准备

因此，如果你的事件是至关重要的，你不想错过他们，然后去 SNS-SQS-Lambda

使用 SQS 的另一个好处是节省了 Lambda 调用的成本(谢谢@codesinthedark 提出这一点)。您可以有更好的扩展性和更低的成本，因为它允许您批处理消息。因此，可以对一批10条消息执行一个 lambda，而在直接 SNS 的情况下，每条消息将触发一个 lambda 调用。

小开

现在可以使用 SQS 作为 en 事件源

AWS Lambda 向支持的事件源添加 Amazon 简单队列服务

小开

阿拉法特 · 纳尔坎德的回答是，SQS 的 lambda 几乎没有什么好处

  1. 在 SQS 中，我们可以放置一个 推迟，以便消息在一段时间后得到处理，这在数据需要时间才能获得的场景中可能是有用的。

  2. SQS 可以作为应急存储，假设下游服务不可用，消息可以在 SQS 中保留15天。

小开

我认为2019年发生了一些变化，SQS 可以通过@alex 提到的事件源映射触发 lambda。 相关博客文章: < a href = “ https://aws.amazon.com/about-aws/whats-new/2018/04/aws-lambda-now-support-amazon-sqs-as-event-source/”rel = “ norefrer”> https://aws.amazon.com/about-aws/whats-new/2018/04/aws-lambda-now-supports-amazon-sqs-as-event-source/

总而言之，使用 SQS To lambda 有以下好处:

  • 在失败的情况下重新处理事件，并配置在放弃之前应该重试消息多少次(接收计数)
  • 保留期更长
  • 通常选择在有一个长时间运行的作业并且 lambda 从作业队列逐个轮询的场景中。

你可以选择使用 SNS:

  • 如果您需要将单个消息扇出到多个目的地，比如说 X 消息应该由 Y 和 Z 应用程序处理。我觉得这是最大的优势，如果你想在这方面的可靠性，你可以耦合 SNS 和 SQS 在一起。
  • 您不关心丢失的消息。请记住，在使用 SNS 时仍然有重试策略(线性、几何、指数等)
  • 通常用于可以更快地摄取/处理消息的情况。这有时也会成为一个问题; 想象一下这样一个场景: 您的业务收到的每封电子邮件都有一个 SNS 通知，但您没有足够的 lambda 并发性来处理所有这些邮件。您可以通过按照自己的节奏使用 SQS 来解决这个问题。

在这两种情况下，都可能存在重复消息(在重试的情况下) ，而且不能保证顺序。如果你需要的话，可以考虑 Kinesis 流。


提交答案