SNS - 具有 lambda 处理的 SQS 扇出

Question

对于某个应用程序，我正在考虑使用 SNS - SQS 扇出并将 lambdas 订阅到 SQS 队列的设置。在 SNS 和 lambda 之间使用 SQS 队列是否过大，或者我应该将 lambda 订阅到我的 SNS 主题？我不想丢失在处理过程中失败的消息，但也许我可以通过绑定到 lambda 的 DLQ 来解决这个问题？在两者之间使用 SQS 是否有特定的优势/区别？

Answer 1

一般来说，有人想要使用扇出方法的原因是，如果需要从同一个事件同时处理多个操作。

例如，在预订流程中，新预订可能会发布到 SNS 主题，该主题具有用于通知仓库的队列、用于向客户发送确认电子邮件的队列以及用于根据订单更新某些忠诚度积分的队列。

存在这种架构是因为单个队列将有一个消费者进程，并在完成后从队列中删除该项目。

如果您只有一个项目，您只需使用 SQS。 SQS 支持 Lambda 的 DLQ，因此您可以在任何项目未成功处理的情况下使用它进行调试。

SQS 优于 SNS 的一个优势是，使用 SQS，您可以将多条记录分组以一次分发（最多 10 条），而使用 SNS，它只会包含一条消息。默认情况下，您最多可以支持 1000 个同时调用。如果您遇到的超过此项目可能会积压（如果您的吞吐量足够）。

Answer 2

简单地说，SQS 主要用作一种解耦机制，以最大限度地减少来自生产者 (SNS) 的尖峰和下降，因此消费者可以以统一的速率消费消息/事件。

你需要先问这些问题：

1. 消费者 lambda 是否能够根据发送到 SNS 的消息数量进行扩展？
2. 您是否为消费者 lambda 预留了足够的并发？ （如果未设置 lambda 可以扩展到 1000（区域并发限制）。虽然这可以通过向 AWS 支持提出服务限制请求来增加）
3. 帐户/区域中的所有 lambdas 是否都有足够的并发性？ （lambda 具有帐户级别区域级别的限制）

如果以上所有问题的答案都是肯定的，那么你在 betwwen 中不需要 sqs。附加到 lambda 的 dl 队列应该没问题。