SNS 到 Lambda 與 SNS 到 SQS 到 Lambda

Question

如果有人可以幫助解釋，我正在嘗試了解我的工作流程中是否需要 SQS。 在我的應用程序中，當采取行動時，它會將信息提交到 SNS 主題，該主題調用 Lambda 進行一些處理。 這很好用。

當我在網上做研究時，似乎人們也在這個堆棧中使用 SQS，SNS 會將信息放在 SQS 上，然后 SQS 會調用 Lambda。

我想我想了解的是在這方面對 SQS 的需求。 這增加了什么價值？ 換句話說，直接從 SNS 調用我的 Lambda 會失去什么？

Answer 1

在 SNS 和 Lambda 之間使用 SQS 的主要優勢是重新處理。 假設 Lambda 由於某種原因（例如超時或內存不足）無法處理某些事件，您可以增加超時（最多 5 分鍾）或內存（最多 1.5GB）並重新啟動輪詢，您可以重新處理較舊的事件。

這在 SNS 到 Lambda 的情況下是不可能的，其中如果 Lambda 失敗，事件就會丟失。 即使您配置了 DLQ，您仍然必須為單獨讀取和處理消息做好准備

因此，如果您的活動很重要並且您不想錯過它們，那么請選擇 SNS - SQS - Lambda

使用 SQS 的另一個優勢是節省 Lambda 調用的成本（感謝 @codesinthedark 提出這一點）。 您可以獲得更好的擴展性和更低的成本，因為它允許您批量處理消息。 因此，可以為一批 10 條消息執行一個 lambda，而在直接 SNS 的情況下，每條消息都會觸發 lambda 調用。

Answer 2

您現在可以使用 SQS 作為事件源

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

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 具有以下好處：

• 在失敗的情況下重新處理事件並配置在您放棄之前應該重試消息的次數（接收計數）
• 更長的保留期
• 通常在有長時間運行的作業並且 lambda 從作業隊列中一項一項輪詢的場景中選擇。

您可以選擇使用 SNS：

• 如果您需要將一條消息扇出到多個目的地，假設 X 消息應該由 Y 和 Z 應用程序處理。 我覺得這是最大的優勢，如果你想要這方面的可靠性，你可以將 SNS 和 SQS 結合在一起。
• 您不在乎丟失的消息。 請記住，使用 SNS 時仍然有重試策略（線性、幾何、指數等）
• 通常用於可以更快地攝取/處理消息的情況。 這有時也是一個問題； 想象一個場景，您的企業收到的每封電子郵件都有一個 SNS 通知，而您沒有足夠的 lambda 並發來處理所有這些電子郵件。 您可以通過按自己的節奏放置 SQS 來解決此問題。

在這兩種情況下，都可能有重復的消息（在重試的情況下）並且無法保證順序。 如果您需要，請考慮 Kinesis 流。

Answer 4

SQS 不調用 Lambda。 SQS 不能調用任何東西。 使用帶有 SQS 的 Lambda 的人在事件計時器上運行 Lambda，例如每分鍾一次，並且每次運行該函數時，它都會輪詢 SQS 以查看是否有消息要處理。

如果您不需要排隊並防止過多的 Lambda 函數同時運行，那么您不需要像 SQS 這樣的隊列系統。

Answer 5

在這里添加@Arafat Nalkhande 的回答是 SQS 的 lambda 的一些好處

1. 在 SQS 中，我們可以放置一個delay ，以便在一段時間后處理消息，這在數據需要時間可用的情況下可能很有用。

2. SQS 可以作為應急存儲，假設下游服務不可用，消息可以在 sqs 中保留 15 天。

Answer 6

取決於您要如何處理重試、錯誤處理。 每個 AWS 資源都有一種重試失敗事件的方法，因此您可能想了解 SNS 如何處理失敗事件，它是否可以處理，如果不能，您可以使用 SQS。 但是您始終可以將失敗的事件從 lambda 推送回 SNS，以便您可以再次處理它們。 但也要考慮你是否真的需要 SQS，你真的需要隊列服務而不僅僅是重試，因為你總是可以使用其他方法來處理此類問題。