本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 對 Lambda 中的事件來源映射問題進行疑難排解
Lambda 中與[事件來源映射](invocation-eventsourcemapping.md)相關的問題可能較為複雜，因為涉及在多個服務中進行除錯。此外，事件來源行為可能會因所使用的具體事件來源而有所不同。本節列出了涉及事件來源映射的常見問題，也提供了如何識別並進行疑難排解的指導。
**注意**
本節使用 Amazon SQS 事件來源作為說明，但其原則同樣適用於其他為 Lambda 函式佇列訊息的事件來源映射。
## 識別和管理限流
在 Lambda 中，當達到函式或帳戶的並行限制時，就會發生限流。建議參考下列範例，其中有從 Amazon SQS 佇列讀取訊息的 Lambda 函式。該 Lambda 函式模擬 30 秒的調用時間，且批次大小為 1。這表示函式每 30 秒僅能處理 1 則訊息：
```
const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))
exports.handler = async (event) => {
await doWork(30000)
}
```
由於調用時間過長，訊息進入佇列的速度會超過處理速度。如果帳戶的未預留並行為 100，Lambda 會向上擴展至 100 個並行執行，隨後便會發生限流。您可以在函數的 CloudWatch 指標中看到此模式：
![\[除錯操作圖 10\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-10.png)
函式的 CloudWatch 指標顯示沒有錯誤，但**並行執行**圖表顯示已達到 100 的並行上限。因此，**限流**圖表顯示限流已生效。
您可以透過 CloudWatch 警示來偵測限流狀況，在函式的限流指標大於 0 時即觸發警示。在您確認限流問題後，有以下幾種解決方案可供選擇：
+ 請求此區域的 AWS Support 團隊增加並行。
+ 識別函數中的效能問題，以提高處理速度，從而改善輸送量。
+ 增加函式的批次大小，以便每次調用能處理更多訊息。
## 處理函數中的錯誤
如果處理函式擲出錯誤，Lambda 會將訊息傳回 SQS 佇列。Lambda 可防止函式擴展，避免出現大規模錯誤。CloudWatch 中的下列 SQS 指標表示佇列處理出現問題：
![\[除錯操作圖 11\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-11.png)
特別是，最舊訊息的存留期和可見訊息的數量都在增加，但沒有訊息被刪除。佇列會繼續成長，但訊息未處理。處理 Lambda 函數的 CloudWatch 指標也表示存在問題：
![\[除錯操作圖 12\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-12.png)
**錯誤計數**指標不為零且不斷增加，同時**並行執行**已減少且限流已停止。這表示 Lambda 已因錯誤而停止向上擴展函式。函式的 CloudWatch 日誌提供錯誤類型的詳細資訊。
您可以透過先識別導致錯誤的函數，然後尋找並消除錯誤來解決此問題。修正錯誤並部署新版函式程式碼後，CloudWatch 指標會顯示處理復原：
![\[除錯操作圖 13\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-13.png)
在這裡，**錯誤計數**指標會降至零，**成功率**指標會恢復至 100%。Lambda 會再次開始向上擴展函式，如**並行執行**圖表中所示。
## 識別和處理背壓
如果事件生產者為 SQS 佇列產生訊息的速度持續快於 Lambda 函式的處理速度，就會產生背壓。在這種情況下，SQS 監控會顯示最舊訊息的存留期以線性方式增長，同時顯示可見訊息的大致數量。可以使用 CloudWatch 警示來偵測佇列中的背壓。
消除背壓的步驟取決於您的工作負載。如果主要目標是提高 Lambda 函式的處理能力與輸送量，有以下選項可用選擇：
+ 請求特定區域的 AWS Support 團隊增加並行。
+ 增加函式的批次大小，以便每次調用能處理更多訊息。