本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
實作部分批次回應的最佳實務
以下是為 Amazon SQS 事件來源設定部分批次回應的
-
設定無效字母佇列以避免在無伺服器應用程式架構中建立 snowball 反模式。如需詳細資訊,請參閱本指南的避免 snowball 反模式一節。
-
設定 Lambda 函數事件來源映射以僅顯示失敗訊息。若要這麼做,您必須ReportBatchItemFailures在設定事件來源對應時將值包含在FunctionResponseTypes清單中。如需詳細資訊,請參閱AWS Lambda 開發人員指南中的實作部分批次回應。
-
定義您希望訊息移至無效字母佇列之前交付至來源佇列的次數。透過識別最可能的故障原因及其預估復原時間,確保您定義的值適合您應用程式的使用案例。若要定義重試次數,您必須在來源佇列上配置maxReceiveCount值。RedrivePolicy如需詳細資訊,請參閱 Amazon 參SQSAPI考資料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,最佳做法也是建立無效字母佇列。此單獨的佇列可以儲存未成功處理的訊息,並協助您更好地管理應用程式未處理訊息的生命週期。
如需指示,請參閱 Amazon SQS 開發人員指南中的設定無效字母佇列 (主控台)。