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

# Lambda 如何處理來自串流和佇列式事件來源的記錄
<a name="invocation-eventsourcemapping"></a>

*事件來源映射*是 Lambda 資源，可從串流和佇列式服務讀取項目，並使用成批的記錄來調用函數。在事件來源映射中，名為*事件輪詢器*的資源會主動輪詢新訊息並調用函數。依預設，Lambda 會自動擴展事件輪詢器，但對於某些事件來源類型，可以使用[佈建模式](#invocation-eventsourcemapping-provisioned-mode)來控制專用於事件來源映射的事件輪詢器數量下限和上限。

下列服務使用事件來源映射調用 Lambda 函數：
+ [Amazon DocumentDB (with MongoDB compatibility) (Amazon DocumentDB)](with-documentdb.md)
+ [Amazon DynamoDB](with-ddb.md)
+ [Amazon Kinesis](with-kinesis.md)
+ [Amazon MQ](with-mq.md)
+ [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](with-msk.md)
+ [自我管理的 Apache Kafka](with-kafka.md)
+ [Amazon Simple Queue Service (Amazon SQS)](with-sqs.md)

**警告**  
Lambda 事件來源映射至少會處理每個事件一次，而且可能會重複處理記錄。為避免與重複事件相關的潛在問題，強烈建議您讓函數程式碼具有等冪性。若要進一步了解，請參閱 AWS 知識中心中的[如何使 Lambda 函數成為等](https://repost.aws/knowledge-center/lambda-function-idempotent)冪。

## 事件來源映射與直接觸發條件有何不同
<a name="eventsourcemapping-trigger-difference"></a>

有些 AWS 服務 可以使用*觸發*直接叫用 Lambda 函數。這些服務會將事件推送至 Lambda，並在發生指定事件時立即調用函數。觸發條件適用於離散事件和即時處理。當您[使用 Lambda 主控台建立觸發](lambda-services.md#lambda-invocation-trigger)時，主控台會與對應的 AWS 服務互動，以在該服務上設定事件通知。觸發條件實際上由產生事件的服務 (而非 Lambda) 儲存和管理。以下是一些使用觸發條件調用 Lambda 函數的服務範例：
+ **Amazon Simple Storage Service (Amazon S3)：**在儲存貯體中建立、刪除或修改物件時調用函數。如需詳細資訊，請參閱[教學課程：使用 Amazon S3 觸發條件調用 Lambda 函數](with-s3-example.md)。
+ **Amazon Simple Notification Service (Amazon SNS)：**當有訊息發布至 SNS 主題時調用函數。如需詳細資訊，請參閱[教學課程： AWS Lambda 搭配 Amazon Simple Notification Service 使用](with-sns-example.md)。
+ **Amazon API Gateway：**在對特定端點提出 API 請求時調用函數。如需詳細資訊，請參閱[使用 Amazon API Gateway 端點調用 Lambda 函數](services-apigateway.md)。

事件來源映射是在 Lambda 服務內建立和管理的 Lambda 資源。事件來源映射旨在處理來自佇列的大量串流資料或訊息。批次處理來自串流或佇列的記錄比個別處理記錄更有效率。

## 批次處理行為
<a name="invocation-eventsourcemapping-batching"></a>

根據預設，事件來源映射會將記錄批次處理到 Lambda 傳送給函數的單個承載中。若要微調批次處理行為，可以設定一個批次間隔 ([MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds)) 和批次大小 ([BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BatchSize))。批次間隔是將記錄收集到單一承載的最長時間。批次大小是單一批次中記錄的最大數目。當下列三個條件之一成立時，Lambda 會調用您的函數：
+ **批次間隔達到其最大值。**預設批次間隔行為會有所不同，這取決於特定的事件來源。
  + **對於 Kinesis、DynamoDB 和 Amazon SQS 事件來源：**預設批次間隔為 0 秒。這表示 Lambda 會在記錄可用時立即調用函數。若要設定批次處理間隔，請設定 `MaximumBatchingWindowInSeconds`。可以將此參數設定為從 0 秒到 300 秒之間的任意值，增量為 1 秒。如果設定批次處理間隔，則在上一個函數調用完成時開始下一個批次處理間隔。
  + **如果事件來源是 Amazon MSK、自主管理 Apache Kafka 、Amazon MQ 以及 Amazon DocumentDB：**預設批次處理時段為 500 毫秒。您可以將 `MaximumBatchingWindowInSeconds` 設定為從 0 秒到 300 秒之間的任意值，增量為秒。在 Kafka 事件來源映射的佈建模式下，如果設定了批次處理時段，則下一個時段會在上一個批次完成後立即開始。在 Kafka 事件來源映射的非佈建模式下，如果設定了批次處理時段，則下一個時段會在上一個函式調用完成後立即開始。若要最大限度降低在佈建模式下使用 Kafka 事件來源映射時的延遲，請將 `MaximumBatchingWindowInSeconds` 設定為 0。此設定可確保 Lambda 在完成目前的函式調用後立即開始處理下一個批次。如需有關低延遲處理的更多資訊，請參閱[低延遲 Apache Kafka](with-kafka-low-latency.md)。
  + **對於 Amazon MQ 和 Amazon DocumentDB 事件來源：**預設批次處理時段為 500 毫秒。您可以將 `MaximumBatchingWindowInSeconds` 設定為從 0 秒到 300 秒之間的任意值，增量為秒。一旦第一條記錄到達，批次間隔就會開始。
**注意**  
因為您只能以秒為增量變更 `MaximumBatchingWindowInSeconds`，所以在變更之後無法恢復到 500 毫秒的預設批次處理間隔。要恢復預設批次間隔，必須建立新的事件來源映射。
+ **已滿足批次大小。**批次大小下限為 1。預設和最大批次大小取決於事件來源。如需這些值的詳細資訊，請參閱 `CreateEventSourceMapping` API 操作的 [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize) 規格。
+ **承載大小達到 [6 MB](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)。**您無法修改此限制。

下圖說明了這三種情況。假設批次間隔從第 `t = 7` 秒開始。在第一種情況下，批次間隔在累積 5 條記錄後在第 `t = 47` 秒達到其最大值 40 秒。在第二種情況下，批次大小在批次間隔到期之前達到 10，因此批次間隔提前結束。在第三種情況下，承載大小在批次間隔到期之前達到最大值，因此批次間隔提前結束。

![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/batching-window.png)


建議使用不同的批次與記錄大小測試，讓每個事件來源的輪詢頻率調整為函數可以多快完成作業。[CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) `BatchSize` 參數會控制每次調用時可傳送至函數的記錄數目上限。更大的批次大小通常會更有效吸收更大集合的記錄的呼叫成本，增加您的傳輸量。

Lambda 在傳送下一批進行處理前不會等待任何已設定的[擴充](lambda-extensions.md)完成。換句話說，當 Lambda 處理下一批記錄時，您的擴充功能可能會繼續執行。如果您違反任何帳戶的 [並行](lambda-concurrency.md) 設定或限制，便可能會產生限流的問題。若要偵測此是否為潛在問題，請監控您的函數，並確認您看到的 [並行指標](monitoring-concurrency.md#general-concurrency-metrics) 是否高於事件來源映射的預期值。由於兩次調用之間的時間很短，Lambda 可能會短暫報告比碎片數目更高的並行用量。即使對於沒有延伸項目的 Lambda 函數也可能如此。

根據預設，如果您的函數傳回錯誤，則事件來源映射會重新處理整個批次，直到函數成功，或批次中的項目過期為止。若要確保依序處理，事件來源映射會暫停處理受影響的碎片，直到錯誤解決為止。針對串流來源 (DynamoDB 和 Kinesis)，您可以設定函數傳回錯誤時 Lambda 重試的次數上限。導致批次未抵達函數的服務錯誤或限流不會計入重試嘗試次數。您也可以設定事件來源映射，在捨棄事件批次時將調用記錄傳送至[目的地](invocation-async-retain-records.md#invocation-async-destinations)。

## 佈建模式
<a name="invocation-eventsourcemapping-provisioned-mode"></a>

Lambda 事件來源映射使用事件輪詢器來輪詢您的事件來源，以取得新訊息。根據預設，Lambda 會根據訊息磁碟區管理這些輪詢器的自動擴展。當訊息流量增加時，Lambda 會自動增加事件輪詢器的數量以處理負載，並在流量減少時減少輪詢器。

在佈建模式中，您可以透過定義專用輪詢資源的最小和最大限制來微調事件來源映射的輸送量，這些資源仍然準備好處理預期的流量模式。這些資源的自動擴展速度快 3 倍，可處理事件流量突然峰值，並提供 16 倍的容量來處理數百萬個事件。這可協助您建置具有嚴格效能要求的高度回應事件驅動型工作負載。

在 Lambda 中，事件輪詢器是一種運算單位，具有因事件來源類型而異的輸送量功能。對於 Amazon MSK 和自我管理的 Apache Kafka，每個事件輪詢器最多可以處理 5 MB/秒的輸送量或最多 5 個並行調用。例如，如果您的事件來源產生平均承載 1 MB，且函數的平均持續時間為 1 秒，則單一 Kafka 事件輪詢器可以支援 5 MB/秒輸送量和 5 個並行 Lambda 調用 （假設沒有承載轉換）。對於 Amazon SQS，每個事件輪詢器最多可以處理每秒 1 MB 的輸送量或最多 10 個並行調用。使用佈建模式會根據您的事件輪詢器用量產生額外費用。如需定價詳細資訊，請參閱 [AWS Lambda 定價](https://aws.amazon.com/lambda/pricing/)。

佈建模式適用於 Amazon MSK、自我管理 Apache Kafka 和 Amazon SQS 事件來源。雖然並行設定可讓您控制函數的擴展，但佈建的模式可讓您控制事件來源映射的輸送量。若要確保最大效能，您可能需要獨立調整這兩個設定。

佈建模式非常適合需要一致事件處理延遲的即時應用程式，例如處理市場資料饋送的金融服務公司、提供即時個人化建議的電子商務平台，以及管理即時玩家互動的遊戲公司。

每個事件輪詢器都支援不同的輸送量容量：
+ 對於 Amazon MSK 和自我管理的 Apache Kafka：高達 5 MB/秒的輸送量或高達 5 個並行調用
+ 對於 Amazon SQS：高達 1 MB/秒的輸送量或高達 10 個並行調用或每秒高達 10 個 SQS 輪詢 API 調用。

對於 Amazon SQS 事件來源映射，您可以將輪詢器數目下限設定為 2 到 200，預設值為 2，上限為 2 到 2，000，預設值為 200。Lambda 會在設定的最小值和最大值之間擴展事件輪詢器的數量，每分鐘快速增加最多 1，000 個並行，以提供事件的一致、低延遲處理。

對於 Kafka 事件來源映射，您可以將輪詢器的最小數量設定為 1 到 200，預設值為 1，最大值為 1 到 2，000，預設值為 200。Lambda 會根據主題中的事件待處理項目，在設定的最小值和最大值之間擴展事件輪詢器的數量，以提供事件的低延遲處理。

請注意，對於 Amazon SQS 事件來源，最大並行設定不能與佈建模式搭配使用。使用佈建模式時，您可以透過最大事件輪詢器設定來控制並行。

如需設定佈建模式的詳細資訊，請參閱下列章節：
+ [設定 Amazon MSK 事件來源映射的佈建模式](kafka-scaling-modes.md)
+ [為自我管理的 Apache Kafka 事件來源映射設定佈建模式](kafka-scaling-modes.md#kafka-provisioned-mode)
+ [搭配 Amazon SQS 事件來源映射使用佈建模式](with-sqs.md#sqs-provisioned-mode)

若要將佈建模式中的延遲降至最低，請將 `MaximumBatchingWindowInSeconds`設為 0。此設定可確保 Lambda 在完成目前的函式調用後立即開始處理下一個批次。如需有關低延遲處理的更多資訊，請參閱[低延遲 Apache Kafka](with-kafka-low-latency.md)。

設定佈建模式後，可以透過監控 `ProvisionedPollers` 指標來觀察工作負載的事件輪詢器使用情況。如需詳細資訊，請參閱[事件來源映射指標](monitoring-metrics-types.md#event-source-mapping-metrics)。

## 事件來源映射 API
<a name="event-source-mapping-api"></a>

若要透過 [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 或 [AWS SDK](https://aws.amazon.com/getting-started/tools-sdks/) 來管理事件來源，可以使用下列 API 操作：
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)