SNS-具有Lambda处理的SQS扇出

问题描述

对于某些应用程序,我正在考虑使用SNS进行设置-SQS扇出并将Lambda订阅到SQS队列中。在SNS和Lambda之间使用SQS队列是否矫kill过正,还是我应该将Lambda订阅我的SNS主题?我不想丢失在处理期间失败的消息,但是也许我可以通过绑定到lambda的DLQ来解决此问题?在两者之间使用SQS是否有特定的优势/差异?

解决方法

通常,有人希望使用扇出方法是因为需要从同一事件中同时处理多个动作。

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

之所以存在此架构,是因为单个队列将具有使用者进程,并在完成后从队列中删除该项目。

如果只有一个项目,则只需使用SQS。 SQS为Lambda支持DLQ,因此,如果未成功处理任何项目,您将可以使用它进行调试。

与SNS相比,SQS的一个优点是,使用SQS,您可以将多个记录组成一组,一次分发(最多10个),而使用SNS,它将仅包含一条消息。默认情况下,您最多可以支持1000个同时调用。如果您遇到的情况不止如此,则这些项目可能会积压(如果吞吐量足够)。

,

简单地说,SQS被广泛用作一种去耦机制,以最大程度地减少生产者(SNS)产生的尖峰和跌落,因此消费者可以以统一的速率消费消息/事件。

您需要先问这些问题:

  1. 使用者lambda是否能够扩展到发送给SNS的消息数量?
  2. 您是否为使用者lambda预留了足够的并发? (如果未设置,lambda可以扩展为1000(区域并发限制)。尽管可以通过向AWS支持人员提出服务限制请求来增加此限制)
  3. 帐户/区域中的所有lambda是否具有足够的并发性? (lambda具有帐户级别的区域级别限制)

如果以上所有问题的答案都是肯定的,则您不需要在两方之间加一平方。附加到lambda的dl队列应该没问题。