為什麼非同步事件來源需要很長時間才能觸發我的 Lambda 函數？

1 分的閱讀內容

非同步事件來源觸發我的 AWS Lambda 函數時會有延遲。

簡短描述

將非同步調用與 Lambda 函數搭配使用時，您可能會注意到觸發事件所花費的時間超過預期。或者，您的事件可能會傳送至無效字母佇列 (DLQ)，而不會被 Lambda 服務接收以進一步處理。

有幾種不同的 AWS 服務可以非同步調用 Lambda 函數：

一般而言，由於處理要求的非同步方法，您可能會看到延遲。

當您提出要求時，它會傳送至內部非同步佇列。Lambda 會從內部非同步佇列提取請求，然後將請求傳送至 Lambda 函數以進行進一步處理。](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)如果您的 Lambda 函數發生錯誤，您可能會在功能的[ Amazon CloudWatch Logs 中看到延遲。如果請求在函數層級限制，也可能會發生延遲。
如果函數層級沒有錯誤或限制資料點，請檢查區域層級量度是否有錯誤和限制。如果非同步調用其他函數，然後遇到錯誤，那麼這些函數會顯著延遲。因此，即使您的函數沒有錯誤或限制資料點，對該函數進行的調用或請求仍可能會延遲。
如果與 Lambda 函數位於相同區域中的其他函數以非同步方式調用多次，則內部佇列會變得擁塞。若要解決此問題，請提高區域層級並行性。
若要檢查內部佇列積壓，請在 Lambda 函數上開啟 AWS X-Ray。當 AWS X-Ray 開啟時，您可以使用停留時間屬性。此屬性顯示 Lambda 服務將請求傳送至 Lambda 函數進行處理之前，在內部佇列中花費的總時間。
設定每個函數並行或保留並行，以保護函數不受佇列待處理的影響。

Lambda 是一種分散式服務，可確保至少調用一次您的函數。但是，如果多次調用該函數，則可能會發生重複。檢查 CloudWatch 日誌中是否有這些重複的呼叫。

確保您的函數可以處理重複請求是最佳做法。如需詳細資訊，請參閱如何使 Lambda 函數具有冪等性？
檢閱 Lambda 的 CloudWatch 日誌，並檢查函數的請求識別碼。從日誌中，您可以檢查重複事件是否具有相同或不同的請求 ID。在 Lambda 的非同步調用生命週期中，請求 ID 會保持不變。如果請求 ID 相同，請檢查函數是否具有導致調用重試和複製的任何錯誤資料點。
如果請求 ID 不同，則在客戶端發生重複的調用。

檢閱 CloudWatch 日誌以區分遺失和延遲的呼叫。如需延遲呼叫，請依照本文「延遲呼叫」一節中先前詳述的步驟執行。

當沒有足夠的並行來服務請求時，會發生缺少調用。如果該函數已保留並行，並且函數遇到錯誤，則請求在非同步佇列中花費很長時間。然後，Lambda 會在不處理的情況下刪除該請求。複查AsyncEventsDropped測量結果，檢查在不執行函數的情況下刪除的事件數目。

如果您已設定 DLQ，請檢查 DLQ 或故障時的要求目的地。如果事件在六個小時後在內部佇列中過期，則可以將請求傳送至 DLQ，而不會由 Lambda 處理。

如需檢閱其他非同步調用指標的詳細資訊，請參閱介紹 AWS Lambda 的新非同步調用指標。