SNS 到 Lambda 与 SNS 到 SQS 到 Lambda

Question

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

当我在线研究时，似乎人们也在这个堆栈中使用 SQS，其中 SNS 会将信息放在 SQS 上，然后 SQS 会调用 Lambda。

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

Answer 1

在 SNS 和 Lambda 之间使用 SQS 的主要优势是重新处理。 假设 Lambda 由于某种原因（例如超时或内存占用不足）无法处理某些事件，您可以增加超时（最多 15 分钟）或内存（最多 1.5GB）并重新启动轮询，然后您可以重新处理较旧的事件。

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

因此，如果您的活动很重要并且您不想错过它们，那么请选择 SNS - SQS - Lambda

拥有 SQS 的另一个优点是节省 Lambda 调用的成本（感谢 @codesinthedark 提出这一点）。您可以获得更好的扩展性和更低的成本，因为它允许您批量处理消息。因此，一个 lambda 可以针对一批 10 条消息执行，而在直接 SNS 的情况下，每条消息都会触发 lambda 调用。

Answer 2

我认为 2019 年发生了一些变化，SQS 可以通过 @alexs 提到的事件源映射来触发 lambda。 相关博客文章：https://aws.amazon.com/about-aws/whats-new/2018/04/aws-lambda-now-supports-amazon-sqs-as-event-source/

总而言之，您可以使用 SQS 进行 lambda，具有以下优点：

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

您可以选择使用SNS：

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

在这两种情况下，都可能存在重复消息（在重试的情况下）并且不能保证顺序。如果您需要，请考虑 Kinesis 流。

Answer 3

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

AWS Lambda 将 Amazon Simple Queue Service 添加到支持的事件源

Answer 4

在 @Arafat Nalkhande 的答案中添加 SQS lambda 的一些好处

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

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

Answer 5

SQS 不调用 Lambda。 SQS 无法调用任何东西。将 Lambda 与 SQS 结合使用的人们在事件计时器上运行 Lambda，例如每分钟一次，并且每次该函数运行时都会轮询 SQS 以查看是否有消息需要处理。

如果您不需要对事物进行排队并防止太多 Lambda 函数同时运行，那么您不需要像 SQS 这样的队列系统。

Answer 6

取决于您想要如何处理重试、错误处理。每个 AWS 资源都有一种重试失败事件的方法，因此您需要了解 SNS 如何处理失败事件、它是否可以处理，如果不能处理，您可以使用 SQS。但您始终可以将失败的事件从 lambda 推送回 SNS，以便您可以再次处理它们。但也要考虑一下，如果您真的想要 SQS，您真的想要队列服务而不仅仅是重试，因为您始终可以使用其他方法来处理此类问题。