實作部分批次回應的最佳實務 - AWS 規定指引

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

實作部分批次回應的最佳實務

以下是設定 Amazon SQS 事件來源的部分批次回應的最佳實務:

  • 設定無效字母佇列以避免在無伺服器應用程式架構中建立 snowball 反模式。如需詳細資訊,請參閱本指南的避免 snowball 反模式一節。

  • 設定 Lambda 函數事件來源映射以僅顯示失敗訊息。若要這麼做,您必須ReportBatchItemFailures在設定事件來源對應時將值包含在FunctionResponseTypes清單中。如需詳細資訊,請參閱《AWS Lambda 開發人員指南》中的報告批次項目失敗

  • 定義您希望訊息移至無效字母佇列之前交付至來源佇列的次數。透過識別最可能的故障原因及其預估復原時間,確保您定義的值適合您應用程式的使用案例。若要定義重試次數,您必須在來源佇列上配置maxReceiveCount值。RedrivePolicy如需詳細資訊,請參閱 Amazon SQS API 參考資料SetQueueAttributes中的。另請參閱 AWS 部落格上的引入 Amazon Simple Queue Service 無效字母佇列可重新驅動至來源佇列

  • 確保您的 Lambda 函數程式碼是等冪性且能夠多次處理訊息。這會準備函數的程式碼來支援 Amazon SQS 訊息批次內的個別作業。一個很好的起點是ReportBatchItemFailures在您的事件源映射配置中加入。如需詳細資訊,請參閱《AWS Lambda 開發人員指南》中的報告批次項目失敗。另請參閱如何防止 Amazon SQS 訊息多次呼叫我的 Lambda 函數?

  • 考慮使用工具,如aws-embedded-metrics動力工具 AWS Lambda (Python)。這些工具可協助您將業務指標整合在函數程式碼中,以追蹤失敗的作業及有關這些作業的詳細資訊。

  • 如果您將此功能與先進先出 (FIFO) 佇列一起使用,您的函數應在第一次失敗後停止處理訊息,並傳回 batchItemFailures 中所有失敗與尚未處理的訊息。這有助於保留佇列中訊息的順序。

注意

需要程式碼層級效能追蹤來追蹤使用部分批次處理的應用程式的整體效能。設定部分批次處理後,無論批次處理的結果是什麼,Lambda 函數調用幾乎永遠成功。

避免 snowball 反模式

Lambda 和 Amazon SQS 無法控制上游微服務寫入 Amazon SQS 佇列的訊息。如果存在無法處理的訊息,Lambda 會將這些未處理的訊息傳回來源 Amazon SQS 佇列,除非設定了單獨的無效字母佇列。然後,Lambda 函數會在後續每個 Amazon SQS 訊息批次中重試這些未處理的訊息,失敗後會回到佇列進行重試。如果不存在無效字母佇列,則傳回 Amazon SQS 佇列的未處理訊息數量最終會超過佇列中的有效訊息數量。

這種類型的 snowball 反模式 (每次連續的 Lambda 函數調用都會使問題變得更糟) 可能會導致下列問題:

  • 使用者體驗不佳,因為作業的處理時間比平常更長,或根本不處理

  • 成本增加與 Amazon SQS 佇列中的訊息數量和訊息重試次數呈指數級增長成比例

  • 如果函數對其調用請求沒有限制,則會降低應用程式或整個 AWS 帳戶的 Lambda 運算能力

為了避免在 Amazon SQS 中設定部分批次回應時建立 snowball 反模式,最佳實務是同時建立無效字母佇列。此單獨的佇列可以儲存未成功處理的訊息,並協助您更好地管理應用程式未處理訊息的生命週期。

如需指示,請參閱《Amazon SQS 開發人員指南》中的設定無效字母佇列 (主控台)