SNS到Lambda vs SNS到SQS到Lambda

Question

如果有人可以帮忙解释,我正试图了解我的工作流程中是否需要SQS.在我的应用程序中,当采取行动时,它会向SNS主题提交信息,该主题调用LAMBDA进行一些处理.这很好用.

当我在网上进行研究时,似乎人们在这个堆栈中使用SQS,而SNS会在SQS上放置信息,然后SQS会调用LAMBDA.

我想我想要了解的是需要SQS.添加什么值,或者换句话说,通过直接从SNS调用我的LAMBDA,我失去了什么？

Answer 1

在SNS和Lambda之间使用SQS的唯一优势是重新处理.假设Lambda由于某种原因(例如超时或内存占用不足)无法处理某些事件,您可以增加超时(最多5分钟)或内存(最大1.5GB)并重新启动轮询,您可以重新处理较老的事件.

对于Lambda的SNS,这是不可能的,其中如果Lambda失败,则事件丢失.即使你配置了DLQ,你仍然需要单独阅读并处理消息

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

说过SQS不能像SNS那样触发lambda.您必须经常轮询SQS

编辑:

AWS宣布SQS在2018年8月28日触发Lambda支持.因此不再需要频繁轮询队列.SQS的新项目可以触发Lambda

我认为您忘记了将 lambda 与 SQS 而不是 SNS 一起使用的一大好处。您可以获得更好的扩展性和更低的成本，因为它允许您批量处理消息，因此可以对 10 条消息执行一个 lambda，而每条 SNS 消息都会触发 lambda，并且它会失败或限制超过 1000msg/s。您将支付一次 lambda 执行和一次 SQS 请求，而不是 10 个 SNS 请求。您可以更新您的答案。 (6认同)
我不同意这篇文章没有回答这个问题，因为假设您已经配置了 DLQ，而不是直接采用 SQS，那么对于所有失败，您都必须转到 DLQ。如果由于某种原因失败只是超时或由于内存占用不足，那么我将不得不单独进行规定来读取 DLQ 并处理消息，而如果在两者之间使用 SQS，那么我只需重新配置 lambda如果自动处理，则具有更大的内存占用和休息 (2认同)

Answer 2

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

Answer 3

我认为 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 具有以下好处：

您可以选择使用 SNS：

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

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

2020 年，SNS FIFO 的出现再次改变了情况 - 提供严格的消息排序和重复数据删除的消息传递：https://aws.amazon.com/blogs/aws/introducing-amazon-sns-fifo-first-in-first-out-pub-子消息/ (2认同)

Answer 4

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

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

这完全取决于您的 Lambda 函数正在做什么。如果它插入到有连接限制的关系数据库中，或者访问有速率限制的第三方 API，那么您将会遇到问题。如果只是更新 S3 中的文件或其他内容，那么您可能不会遇到问题。您可能需要申请增加您的 AWS 账户中允许的并发 Lambda 函数的数量，但仅此而已。 (2认同)

Answer 5

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