Wie Lambda Datensätze aus Stream- und warteschlangenbasierten Ereignisquellen verarbeitet - AWS Lambda
Zuordnungen und Auslöser von EreignisquellenBatching-VerhaltenAPI für die Ereignisquellenzuordnung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wie Lambda Datensätze aus Stream- und warteschlangenbasierten Ereignisquellen verarbeitet

Eine Ereignisquellenzuordnung ist eine Lambda-Ressource, die Elemente aus stream- und warteschlangenbasierten Diensten liest und eine Funktion mit Datensatzstapeln aufruft. Die folgenden Dienste verwenden Ereignisquellenzuordnungen, um Lambda-Funktionen aufzurufen:

Warnung

Lambda-Ereignisquellenzuordnungen verarbeiten jedes Ereignis mindestens einmal, und es kann zu einer doppelten Verarbeitung von Datensätzen kommen. Um mögliche Probleme im Zusammenhang mit doppelten Ereignissen zu vermeiden, empfehlen wir Ihnen dringend, Ihren Funktionscode idempotent zu machen. Weitere Informationen finden Sie im Knowledge Center unter Wie mache ich meine Lambda-Funktion idempotent?. AWS

Wie unterscheiden sich Zuordnungen von Ereignisquellen von direkten Triggern

Einige AWS Dienste können Lambda-Funktionen mithilfe von Triggern direkt aufrufen. Diese Dienste leiten Ereignisse an Lambda weiter, und die Funktion wird sofort aufgerufen, wenn das angegebene Ereignis eintritt. Trigger eignen sich für diskrete Ereignisse und die Verarbeitung in Echtzeit. Wenn Sie mit der Lambda-Konsole einen Trigger erstellen, interagiert die Konsole mit dem entsprechenden AWS Dienst, um die Ereignisbenachrichtigung für diesen Dienst zu konfigurieren. Der Trigger wird tatsächlich von dem Dienst gespeichert und verwaltet, der die Ereignisse generiert, nicht von Lambda. Hier sind einige Beispiele für Dienste, die Trigger verwenden, um Lambda-Funktionen aufzurufen:

Ereignisquellenzuordnungen sind Lambda-Ressourcen, die innerhalb des Lambda-Service erstellt und verwaltet werden. Zuordnungen von Ereignisquellen sind für die Verarbeitung umfangreicher Streaming-Daten oder Nachrichten aus Warteschlangen konzipiert. Die stapelweise Verarbeitung von Datensätzen aus einem Stream oder einer Warteschlange ist effizienter als die Verarbeitung einzelner Datensätze.

Batching-Verhalten

Standardmäßig batcht eine Ereignisquellenzuordnung Datensätze in einer einzigen Nutzlast, die Lambda an Ihre Funktion sendet. Zur Feinabstimmung des Batchverhaltens können Sie ein Batchfenster (MaximumBatchingWindowInSekunden) und eine Batchgröße () konfigurieren. BatchSize Ein Batch-Fenster ist die maximale Zeitspanne zur Erfassung von Datensätzen in einer einzigen Nutzlast. Eine Batch-Größe ist die maximale Anzahl von Datensätzen in einem einzigen Batch. Lambda ruft Ihre Funktion auf, wenn eines der folgenden drei Kriterien erfüllt ist:

  • Das Batching-Fenster erreicht seinen Maximalwert. Das Standardverhalten des Batchfensters hängt von der jeweiligen Ereignisquelle ab.

    • Für Kinesis-, DynamoDB- und Amazon SQS SQS-Ereignisquellen: Das Standard-Batch-Fenster beträgt 0 Sekunden. Das bedeutet, dass Lambda Batches nur dann an Ihre Funktion sendet, wenn entweder die Batchgröße erreicht oder die Nutzlastgrößenbeschränkung erreicht ist. Um ein Batching-Fenster festzulegen, konfigurieren Sie. MaximumBatchingWindowInSeconds Sie können diesen Parameter auf einen beliebigen Wert zwischen 0 und 300 Sekunden in Schritten von 1 Sekunde festlegen. Wenn Sie ein Batching-Fenster konfigurieren, beginnt das nächste Fenster, sobald der vorherige Funktionsaufruf abgeschlossen ist.

    • Für Amazon-MSK-, selbstverwaltete Apache-Kafka-, Amazon-MQ- und Amazon-DocumentDB-Ereignisquellen: Das standardmäßige Batching-Fenster beträgt 500 ms. Sie können MaximumBatchingWindowInSeconds auf einen beliebigen Wert von 0 Sekunden bis 300 Sekunden in Sekundenschritten einstellen. Ein Batch-Fenster beginnt, sobald der erste Datensatz eintrifft.

      Anmerkung

      Da Sie Änderungen nur MaximumBatchingWindowInSeconds in Sekundenschritten vornehmen können, können Sie nach der Änderung nicht mehr zum standardmäßigen Batchfenster von 500 ms zurückkehren. Um das Standard-Batch-Fenster wiederherzustellen, müssen Sie eine neue Ereignisquellenzuordnung erstellen.

  • Die Batch-Größe wird erreicht. Die minimale Batch-Größe beträgt 1. Die Standard- und die maximale Batch-Größe hängen von der Ereignisquelle ab. Einzelheiten zu diesen Werten finden Sie in der BatchSizeSpezifikation für den CreateEventSourceMapping API-Vorgang.

  • Die Nutzlastgröße erreicht 6 MB. Sie können dieses Limit nicht ändern.

Das folgende Diagramm verdeutlicht diese Bedingungen. Angenommen, ein Batch-Fenster beginnt bei t = 7 Sekunden. Im ersten Szenario erreicht das Batch-Fenster sein Maximum von 40 Sekunden bei t = 47 Sekunden nach dem Erfassen von 5 Datensätzen. Im zweiten Szenario erreicht die Batch-Größe 10, bevor das Batch-Fenster abläuft, sodass das Batch-Fenster früh endet. Im dritten Szenario wird die maximale Nutzlastgröße erreicht, bevor das Batch-Fenster abläuft, sodass das Batch-Fenster frühzeitig endet.

Ein Batch-Fenster läuft ab, wenn eines der folgenden drei Kriterien erfüllt ist: Das Batch-Fenster erreicht seinen Maximalwert, die Batch-Größe wird erreicht oder die Nutzlastgröße erreicht 6 MB.

API für die Ereignisquellenzuordnung

Um eine Ereignisquelle mit der AWS Command Line Interface (AWS CLI) oder einem AWS-SDK zu verwalten, können Sie die folgenden API-Operationen verwenden: