Verwenden von Lambda mit Amazon SQS - AWS Lambda

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.

Verwenden von Lambda mit Amazon SQS

Anmerkung

Wenn Sie Daten an ein anderes Ziel als eine Lambda-Funktion senden oder die Daten vor dem Senden anreichern möchten, finden Sie weitere Informationen unter Amazon EventBridge Pipes.

Mit einer Lambda-Funktion können Sie Nachrichten in einer Amazon-SQS-Warteschlange (Amazon Simple Queue Service) verarbeiten. Lambda-Ereignisquellen-Zuweisungenen unterstützen Standardwarteschlangen und First-in-First-out-Warteschlangen (FIFO). Mit Amazon SQS können Sie Aufgaben von einer Komponente Ihrer Anwendung auslagern, indem Sie sie an eine Warteschlange senden und asynchron verarbeiten.

Lambda fragt die Warteschlange ab und ruft Ihre Lambda-Funktion synchron mit einem Ereignis auf, das Warteschlangennachrichten enthält. Lambda liest Nachrichten in Batches und ruft Ihre Funktion einmal für jeden Batch auf. Wenn Ihre Funktion einen Batch erfolgreich verarbeitet, löscht Lambda deren Nachrichten aus der Warteschlange.

Wenn Lambda einen Batch liest, bleiben die Nachrichten in der Warteschlange, werden aber für die Dauer der Zeitbeschränkung für die Sichtbarkeit der Warteschlange ausgeblendet. Wenn Ihre Funktion den Batch erfolgreich verarbeitet, löscht Lambda die Nachrichten aus der Warteschlange. Wenn Ihre Funktion bei der Verarbeitung eines Batches auf einen Fehler stößt, werden standardmäßig alle Nachrichten in diesem Batch wieder in der Warteschlange sichtbar, nachdem das Sichtbarkeits-Timeout abgelaufen ist. Deshalb muss der Funktionscode in der Lage sein, dieselbe Nachricht mehrmals ohne unbeabsichtigte Begleiterscheinungen zu verarbeiten.

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

Um zu verhindern, dass Lambda eine Nachricht mehrfach verarbeitet, können Sie entweder Ihre Ereignisquellenzuordnung so konfigurieren, dass Batch-Elementfehler in Ihre Funktionsantwort aufgenommen werden, oder Sie können die Amazon SQS SQS-API-Aktion verwenden, um Nachrichten aus der Warteschlange DeleteMessagezu entfernen, wenn Ihre Lambda-Funktion sie erfolgreich verarbeitet. Weitere Informationen zur Verwendung der Amazon SQS SQS-API finden Sie in der Amazon Simple Queue Service API-Referenz.

Beispiel für ein Standard-Warteschlangen-Nachrichtenereignis

Beispiel Amazon-SQS-Nachrichtenereignis (Standardwarteschlange)
{ "Records": [ { "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d", "receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...", "body": "Test message.", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1545082649183", "SenderId": "AIDAIENQZJOLO23YVJ4VO", "ApproximateFirstReceiveTimestamp": "1545082649185" }, "messageAttributes": {}, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue", "awsRegion": "us-east-2" }, { "messageId": "2e1424d4-f796-459a-8184-9c92662be6da", "receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...", "body": "Test message.", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1545082650636", "SenderId": "AIDAIENQZJOLO23YVJ4VO", "ApproximateFirstReceiveTimestamp": "1545082650649" }, "messageAttributes": {}, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue", "awsRegion": "us-east-2" } ] }

Lambda fragt standardmäßig bis zu 10 Nachrichten in Ihrer Warteschlange sofort ab und sendet diesen Batch an die Funktion. Damit die Funktion nicht mit einer kleinen Anzahl von Datensätzen aufgerufen wird, können Sie die Ereignisquelle anweisen, Datensätze bis zu 5 Minuten lang zu puffern, indem Sie ein Batch-Fenster konfigurieren. Vor dem Aufrufen der Funktion fragt Lambda weiter Nachrichten aus der SQS-Standardwarteschlange ab, bis das Batch-Fenster abläuft, das Nutzlastkontingent pro Aufruf erreicht ist oder die konfigurierte maximale Batch-Größe erreicht ist.

Wenn Sie ein Batch-Fenster verwenden und Ihre SQS-Warteschlange sehr wenig Datenverkehr enthält, wartet Lambda möglicherweise bis zu 20 Sekunden, bevor Sie Ihre Funktion aufruft. Dies gilt auch, wenn Sie ein Batch-Fenster unter 20 Sekunden festlegen.

Anmerkung

In Java können beim Deserialisieren von JSON Nullzeigerfehler auftreten. Dies könnte daran liegen, dass die Groß- und Kleinschreibung von „Records“ und „eventSourceARN“ vom JSON-Objektmapper konvertiert wird.

Beispiel für ein FIFO-Warteschlangen-Nachrichtenereignis

Bei FIFO-Warteschlangen enthalten Datensätze zusätzliche Attribute, die mit der Deduplizierung und Sequenzierung zusammenhängen.

Beispiel Amazon-SQS-Nachrichtenereignis (FIFO-Warteschlange)
{ "Records": [ { "messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5", "receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...", "body": "Test message.", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1573251510774", "SequenceNumber": "18849496460467696128", "MessageGroupId": "1", "SenderId": "AIDAIO23YVJENQZJOL4VO", "MessageDeduplicationId": "1", "ApproximateFirstReceiveTimestamp": "1573251510774" }, "messageAttributes": {}, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo", "awsRegion": "us-east-2" } ] }

Konfigurieren einer Warteschlange zur Verwendung mit Lambda

Erstellen Sie eine SQS-Warteschlange als Ereignisquelle für Ihre Lambda-Funktion. Konfigurieren Sie dann die Warteschlange so, dass Ihre Lambda-Funktion Zeit zum Verarbeiten der Ereignisse jedes Batches erhält und Lambda es erneut versuchen kann, wenn Ablehnungsfehler beim Aufwärtsskalieren auftreten.

Damit die Funktion Zeit hat, jeden Stapel von Datensätzen zu verarbeiten, legen Sie das Sichtbarkeits-Timeout der Ausgangswarteschlange auf mindestens das Sechsfache des Timeouts das Sie für Ihre Funktion konfigurieren, fest. Diese zusätzliche Zeit ermöglicht es Lambda, einen erneuten Versuch zu machen, wenn die Funktion gedrosselt wird, während ein früherer Batch verarbeitet wird.

Wenn die Funktion eine Nachricht mehrmals nicht verarbeiten kann, kann Amazon SQS sie an eine Warteschlange für unzustellbare Nachrichten senden. Wenn Ihre Funktion einen Fehler zurückgibt, werden alle Elemente im Stapel in die Warteschlange zurückgegeben. Nach Ablauf des Sichtbarkeits-Timeouts empfängt Lambda die Nachricht erneut. Um Nachrichten nach einer Anzahl von Empfangsvorgängen an eine zweite Warteschlange zu senden, konfigurieren Sie eine Warteschlange für den Posteingang in der Quellwarteschlange.

Anmerkung

Stellen Sie sicher, dass Sie die Warteschlange für unzustellbare Nachrichten für die Quell-Warteschlange und nicht für die Lambda-Funktion konfigurieren. Die Warteschlange für unzustellbare Nachrichten, die Sie für eine Funktion konfigurieren, wird für die Warteschlange asynchroner Aufrufe der Funktion und nicht für Ereignisquellen-Warteschlangen verwendet.

Wenn Ihre Funktion einen Fehler zurückgibt oder nicht aufgerufen werden kann, da ihre maximale Gleichzeitigkeit erreicht wurde, kann die Verarbeitung mit zusätzlichen Versuchen erfolgreich sein. Damit Nachrichten besser verarbeitet werden können, bevor sie an die Warteschlange gesendet werden, stellen Sie maxReceiveCount für die Redrive-Richtlinie der Quellwarteschlange auf mindestens 5 ein.

Berechtigungen für die Ausführungsrolle

Die AWSLambdaSQSQueueExecutionRole AWS verwaltete Richtlinie umfasst die Berechtigungen, die Lambda benötigt, um aus Ihrer Amazon SQS SQS-Warteschlange zu lesen. Fügen Sie diese verwaltete Richtlinie der Ausführungsrolle Ihrer Funktion hinzu.

Wenn Sie optional eine verschlüsselte Warteschlange verwenden, müssen Sie Ihrer Ausführungsrolle auch die folgende Berechtigung hinzufügen:

Fügen Sie Berechtigungen hinzu und erstellen Sie die Zuordnung der Ereignisquellen

Erstellen Sie ein Ereignisquellen-Mapping, um Lambda anzuweisen, Elemente aus Ihrer Warteschlange an eine Lambda-Funktion zu senden. Sie können mehrere Ereignisquellen-Zuweisungen zum Verarbeiten von Elementen aus mehreren Warteschlangen mit nur einer Funktion erstellen. Wenn Lambda die Zielfunktion aufruft, kann das Ereignis mehrere Elemente bis zu einer konfigurierbaren maximalen Batch-Größe enthalten.

Um Ihre Funktion für das Lesen aus Amazon SQS zu konfigurieren, fügen Sie die AWSLambdaSQSQueueExecutionRole AWS verwaltete Richtlinie Ihrer Ausführungsrolle hinzu und erstellen Sie dann einen SQS-Trigger.

Um Berechtigungen hinzuzufügen und einen Trigger zu erstellen
  1. Öffnen Sie die Seite Funktionen der Lambda-Konsole.

  2. Wählen Sie den Namen einer Funktion aus.

  3. Wählen Sie die Registerkarte Konfiguration und dann Berechtigungen aus.

  4. Wählen Sie unter Rollenname den Link zu Ihrer Ausführungsrolle aus. Dieser Link öffnet die Rolle in der IAM-Konsole.

    Link zur Ausführungsrolle
  5. Wählen Sie Berechtigungen hinzufügen aus und wählen Sie dann Richtlinien direkt anhängen aus.

    Fügen Sie Richtlinien in der IAM-Konsole hinzu
  6. Geben Sie im Suchfeld AWSLambdaSQSQueueExecutionRole ein. Fügen Sie diese Richtlinie Ihrer Ausführungsrolle hinzu. Dies ist eine AWS verwaltete Richtlinie, die die Berechtigungen enthält, die Ihre Funktion zum Lesen aus einer Amazon SQS SQS-Warteschlange benötigt. Weitere Informationen zu dieser Richtlinie finden Sie AWSLambdaSQSQueueExecutionRolein der Referenz zu AWS verwalteten Richtlinien.

  7. Kehren Sie zu Ihrer Funktion in der Lambda-Konsole zurück. Wählen Sie unter Function overview (Funktionsübersicht) die Option Add trigger (Trigger hinzufügen).

    Abschnitt „Funktionsübersicht“ der Lambda-Konsole
  8. Wählen Sie einen Auslösertyp aus.

  9. Konfigurieren Sie die erforderlichen Optionen und wählen Sie dann Add (Hinzufügen) aus.

Lambda unterstützt die folgenden Optionen für Amazon-SQS-Ereignisquellen:

SQS Queue

Die Amazon-SQS-Warteschlange, aus der Datensätze gelesen werden sollen.

Aktivieren von Auslösern

Der Status der Zuordnung von Ereignisquellen. Enable trigger (Auslöser aktivieren) ist standardmäßig ausgewählt.

Batch-Größe

Die maximale Anzahl der Datensätze, die in jedem Stapel an die Funktion gesendet werden sollen. Bei einer Standardwarteschlange können dies bis zu 10.000 Datensätze sein. Bei einer FIFO-Warteschlange liegt der Höchstwert bei 10. Bei einer Stapelgröße über 10 müssen Sie das Stapelfenster (MaximumBatchingWindowInSeconds) zusätzlich auf mindestens 1 Sekunde festlegen.

Konfigurieren Sie Ihr Funktions-Timeout so, dass genügend Zeit bleibt, um einen ganzen Stapel von Elementen zu verarbeiten. Wenn die Verarbeitung bestimmter Elemente lange Zeit in Anspruch nimmt, wählen Sie eine kleinere Batch-Größe. Eine große Batchgröße kann die Effizienz für Workloads erhöhen, die sehr schnell sind oder viel Overhead aufweisen. Wenn Sie reservierte Nebenläufigkeit für Ihre Funktion konfigurieren, legen Sie mindestens fünf gleichzeitige Ausführungen fest, um das Risiko von Drosselungsfehlern zu senken, wenn Lambda die Funktion aufruft.

Lambda übergibt alle Datensätze im Batch in einem einzigen Aufruf an die Funktion, solange die Gesamtgröße der Ereignisse nicht das Nutzlastkontingent pro Aufruf für synchrone Aufrufe überschreitet (6 MB). Sowohl Lambda als auch Amazon SQS generieren Metadaten für jeden Datensatz. Diese zusätzlichen Metadaten werden auf die Gesamtnutzlastgröße angerechnet und können dazu führen, dass die Gesamtzahl der in einem Batch gesendeten Datensätze niedriger ist als die konfigurierte Batch-Größe. Die Metadatenfelder, die Amazon SQS sendet, können in der Länge variabel sein. Weitere Informationen zu den Amazon SQS-Metadatenfeldern finden Sie in der Dokumentation zum ReceiveMessageAPI-Betrieb in der Amazon Simple Queue Service API-Referenz.

Batchfenster

Die maximale Zeitspanne zur Erfassung von Datensätzen vor dem Aufruf der Funktion in Sekunden. Dies gilt nur für Standardwarteschlangen.

Wenn Sie ein Stapelfenster von mehr als 0 Sekunden verwenden, müssen Sie die erhöhte Verarbeitungszeit im Sichtbarkeits-Timeout Ihrer Warteschlange berücksichtigen. Wir empfehlen, das Sichtbarkeits-Timeout Ihrer Warteschlange auf das Sechsfache Ihres Funktions-Timeouts plus den Wert von MaximumBatchingWindowInSeconds festzulegen. Dies gibt Ihrer Lambda-Funktion Zeit, jeden Ereignis-Batch zu verarbeiten und es im Falle eines Drosselungsfehlers erneut zu versuchen.

Wenn Nachrichten verfügbar werden, beginnt Lambda, Nachrichten stapelweise zu verarbeiten. Lambda beginnt mit der gleichzeitigen Verarbeitung von fünf Stapeln mit fünf gleichzeitigen Aufrufen Ihrer Funktion. Wenn weiterhin Nachrichten verfügbar sind, fügt Lambda Ihrer Funktion bis zu 300 weitere Instances pro Minute hinzu, bis zu einem Maximum von 1 000 Funktions-Instances. Informationen darüber, wie Gleichzeitigkeit mit der Skalierung interagiert, finden Sie unter Funktionsskalierung von Lambda.

Um mehr Nachrichten zu verarbeiten, können Sie Ihre Lambda-Funktion für einen höheren Durchsatz optimieren. Weitere Informationen finden Sie unter Erläuterung der AWS Lambda Skalierung mit Amazon SQS SQS-Standardwarteschlangen.

Maximale Gleichzeitigkeit

Die maximale Anzahl der gleichzeitigen Funktionen, die die Ereignisquelle aufrufen kann. Weitere Informationen finden Sie unter Konfigurieren der maximalen Gleichzeitigkeit für Amazon-SQS-Ereignisquellen.

Filterkriterien

Verwenden Sie Filterkriterien, um zu steuern, welche Ereignisse Lambda zur Verarbeitung an Ihre Funktion sendet. Weitere Informationen finden Sie unter Lambda-Ereignisfilterung.

Skalierung und Verarbeitung

Bei Standardwarteschlangen verwendet Lambda Langabfrage, um eine Warteschlange so lange abzufragen, bis sie aktiv wird. Wenn Nachrichten verfügbar sind, beginnt Lambda mit der gleichzeitigen Verarbeitung von fünf Stapeln mit fünf gleichzeitigen Aufrufen Ihrer Funktion. Wenn weiterhin Nachrichten verfügbar sind, erhöht Lambda die Anzahl der die Batches lesenden Prozesse um bis zu 300 weitere Instances pro Minute. Die maximale Anzahl von Batches, die eine Ereignisquellenzuordnung gleichzeitig verarbeiten kann, ist 1 000.

Bei FIFO-Warteschlangen sendet Lambda Nachrichten in der Reihenfolge, in der sie empfangen wurden, an Ihre Funktion. Wenn Sie eine Nachricht an eine FIFO-Warteschlange senden, geben Sie eine Nachrichtengruppen-ID an. Amazon SQS stellt sicher, dass Nachrichten in derselben Gruppe in der Reihenfolge an Lambda übermittelt werden. Wenn Lambda Ihre Nachrichten in Batches liest, kann jeder Batch Nachrichten aus mehr als einer Nachrichtengruppe enthalten, aber die Reihenfolge der Nachrichten wird beibehalten. Wenn die Funktion einen Fehler zurückgibt, führt sie alle Wiederholungsversuche für die betroffenen Nachrichten aus, bevor Lambda weitere Nachrichten von derselben Gruppe erhält.

Ihre Funktion kann in Gleichzeitigkeit auf die Anzahl aktiver Nachrichtengruppen skaliert werden. Weitere Informationen finden Sie unter SQS FIFO as a event source im Compute-Blog. AWS

Konfigurieren der maximalen Gleichzeitigkeit für Amazon-SQS-Ereignisquellen

Die Einstellung für die maximale Gleichzeitigkeit begrenzt die Anzahl der gleichzeitigen Instances der Funktion, die eine Amazon-SQS-Ereignisquelle aufrufen kann. Die maximale Gleichzeitigkeit ist eine Einstellung auf der Ebene der Ereignisquelle. Wenn Sie einer Funktion mehrere Amazon-SQS-Ereignisquellen zugeordnet haben, kann jede Ereignisquelle eine separate Einstellung für die maximale Gleichzeitigkeit haben. Sie können die maximale Parallelität verwenden, um zu verhindern, dass eine Warteschlange die gesamte reservierte Gleichzeitigkeit der Funktion oder den Rest des Gleichzeitigkeitskontingents des Kontos verwendet. Für die Konfiguration der maximalen Gleichzeitigkeit auf einer Amazon-SQS-Ereignisquelle fallen keine Gebühren an.

Wichtig ist, dass maximale und reservierte Parallelität zwei unabhängige Einstellungen sind. Setzen Sie die maximale Parallelität nicht höher als die reservierte Parallelität der Funktion. Wenn Sie maximale Parallelität konfigurieren, stellen Sie sicher, dass die reservierte Parallelität Ihrer Funktion größer oder gleich der gesamten maximalen Parallelität für alle Amazon SQS-Ereignisquellen auf der Funktion ist. Andernfalls könnte Lambda Ihre Nachrichten drosseln.

Wenn die maximale Parallelität nicht festgelegt ist, kann Lambda Ihre Amazon SQS-Ereignisquelle auf das Gesamtkontingent für Parallelität Ihres Kontos skalieren, das standardmäßig 1.000 beträgt.

Anmerkung

Bei FIFO-Warteschlangen sind gleichzeitige Aufrufe entweder durch die Anzahl der Nachrichtengruppen-IDs (messageGroupId) oder die maximale Gleichzeitigkeitseinstellung begrenzt, je nachdem, welcher Wert niedriger ist. Wenn Sie beispielsweise sechs Nachrichtengruppen-IDs haben und die maximale Gleichzeitigkeit auf 10 festgelegt ist, kann Ihre Funktion maximal sechs gleichzeitige Aufrufe haben.

Sie können die maximale Gleichzeitigkeit für neue und vorhandene Zuordnung von Ereignisquellen in Amazon SQS konfigurieren.

Konfigurieren der maximalen Gleichzeitigkeit mithilfe der Lambda-Konsole
  1. Öffnen Sie die Seite Funktionen der Lambda-Konsole.

  2. Wählen Sie den Namen einer Funktion aus.

  3. Wählen Sie unter Function overview (Funktionsübersicht) die Option SQS aus. Dadurch wird die Registerkarte Configuration (Konfiguration) geöffnet.

  4. Wählen Sie den Amazon-SQS-Auslöser aus und klicken Sie auf Edit (Bearbeiten).

  5. Geben Sie für Maximum concurrency (Maximale Gleichzeitigkeit) eine Zahl zwischen 2 und 1 000 ein. Um die maximale Gleichzeitigkeit zu deaktivieren, lassen Sie das Feld leer.

  6. Wählen Sie Speichern.

Konfigurieren Sie die maximale Parallelität mithilfe von () AWS Command Line InterfaceAWS CLI

Verwenden Sie den update-event-source-mappingBefehl mit der --scaling-config Option. Beispiel:

aws lambda update-event-source-mapping \ --uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \ --scaling-config '{"MaximumConcurrency":5}'

Um die maximale Gleichzeitigkeit zu deaktivieren, geben Sie einen leeren Wert für --scaling-config ein:

aws lambda update-event-source-mapping \ --uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \ --scaling-config "{}"
Konfigurieren der maximalen Gleichzeitigkeit mithilfe der Lambda-API

Verwenden Sie die UpdateEventSourceMappingAktion CreateEventSourceMappingoder mit einem ScalingConfigObjekt.

APIs 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:

Das folgende Beispiel verwendet die AWS CLI , um eine Funktion mit dem Namen my-function einer Amazon SQS SQS-Warteschlange zuzuordnen, die durch ihren Amazon-Ressourcennamen (ARN) mit einer Batchgröße von 5 und einem Batchfenster von 60 Sekunden angegeben ist.

aws lambda create-event-source-mapping --function-name my-function --batch-size 5 \ --maximum-batching-window-in-seconds 60 \ --event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue

Die Ausgabe sollte folgendermaßen aussehen:

{ "UUID": "2b733gdc-8ac3-cdf5-af3a-1827b3b11284", "BatchSize": 5, "MaximumBatchingWindowInSeconds": 60, "EventSourceArn": "arn:aws:sqs:us-east-2:123456789012:my-queue", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "LastModified": 1541139209.351, "State": "Creating", "StateTransitionReason": "USER_INITIATED" }

Backoff-Strategie für fehlgeschlagene Aufrufe

Wenn ein Aufruf fehlschlägt, versucht Lambda, den Aufruf zu wiederholen, während eine Backoff-Strategie implementiert wird. Die Backoff-Strategie unterscheidet sich geringfügig, je nachdem, ob Lambda den Fehler aufgrund eines Fehlers in Ihrem Funktionscode oder aufgrund einer Drosselung festgestellt hat.

  • Wenn Ihr Funktionscode den Fehler verursacht hat, stoppt Lambda die Verarbeitung und versucht erneut, den Aufruf zu starten. In der Zwischenzeit macht Lambda schrittweise einen Rückzieher und reduziert die Anzahl der Parallelität, die Ihrer Amazon SQS SQS-Ereignisquellenzuordnung zugewiesen ist. Wenn das Sichtbarkeits-Timeout Ihrer Warteschlange abgelaufen ist, erscheint die Nachricht wieder in der Warteschlange.

  • Wenn der Aufruf aufgrund von Drosselung fehlschlägt, setzt Lambda schrittweise Wiederholungsversuche zurück, indem es die Menge der Gleichzeitigkeit reduziert, die Ihrer Zuordnung von Ereignisquellen in Amazon SQS zugewiesen ist. Lambda fährt fort, die Nachricht erneut zu versuchen, bis der Zeitstempel der Nachricht das Sichtbarkeits-Timeout Ihrer Warteschlange überschreitet, an welchem Punkt Lambda die Nachricht verwirft.

Implementierung von partiellen Batch-Antworten

Wenn die Lamda-Funktion während der Verarbeitung eines Batches auf einen Fehler stößt, werden standardmäßig alle Nachrichten in diesem Batch wieder in der Warteschlange sichtbar, einschließlich Nachrichten, die Lambda erfolgreich verarbeitet hat. Infolgedessen kann es passieren, dass die Funktion dieselbe Nachricht mehrmals verarbeitet.

Damit nicht erfolgreich bearbeiten Nachrichten in einem fehlgeschlagenen Batch erneut verarbeitet werden, können Sie die Zuordnung von Ereignisquellen so konfigurieren, dass nur die fehlgeschlagenen Nachrichten wieder sichtbar werden. Dies wird als partielle Batch-Antwort bezeichnet. Um partielle Batch-Antworten zu aktivieren, geben Sie ReportBatchItemFailures bei der Konfiguration Ihrer Ereignisquellenzuordnung die entsprechende FunctionResponseTypesAktion an. Dadurch kann die Funktion einen Teilerfolg zurückgeben, was die Anzahl unnötiger Wiederholungsversuche für Datensätze reduzieren kann.

Wenn ReportBatchItemFailures aktiviert ist, skaliert Lambda die Nachrichtenabfrage nicht herunter, wenn Funktionsaufrufe fehlschlagen. Wenn Sie erwarten, dass einige Nachrichten ausfallen – und Sie nicht möchten, dass sich diese Fehler auf die Nachrichtenverarbeitungsrate auswirken – verwenden Sie ReportBatchItemFailures.

Anmerkung

Berücksichtigen Sie bei Verwendung von partiellen Batch-Antworten Folgendes:

  • Wenn die Funktion eine Ausnahme ausgibt, gilt der gesamte Batch als fehlgeschlagen.

  • Wenn Sie dieses Feature mit einer FIFO-Warteschlange verwenden, sollte Ihre Funktion die Verarbeitung von Nachrichten nach dem ersten Fehler beenden und alle fehlgeschlagenen und nicht verarbeiteten Nachrichten in batchItemFailures zurückgeben. Das hilft, die Reihenfolge der Nachrichten in der Warteschlange beizubehalten.

So aktivieren Sie partielle Batchberichterstattung
  1. Sehen Sie sich die bewährten Methoden für die Implementierung von partiellen Batch-Antworten an.

  2. Führen Sie den folgenden Befehl aus, um ReportBatchItemFailures für Ihre Funktion zu aktivieren. Führen Sie den Befehl aus, um die UUID Ihrer Ereignisquellenzuordnung abzurufen. list-event-source-mappings AWS CLI

    aws lambda update-event-source-mapping \ --uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \ --function-response-types "ReportBatchItemFailures"
  3. Aktualisieren Sie Ihren Funktionscode, um alle Ausnahmen abzufangen und fehlgeschlagene Nachrichten in einer batchItemFailures-JSON-Antwort zurückzugeben. Die batchItemFailures-Antwort muss eine Liste von Nachrichten-IDs als itemIdentifier-JSON-Werte enthalten.

    Angenommen, Sie haben einen Batch von fünf Nachrichten mit den Nachrichten-IDs id1, id2, id3, id4 und id5. Die Funktion verarbeitet erfolgreich id1, id3 und id5. Damit die Nachrichten id2 und id4 in der Warteschlange wieder sichtbar werden, sollte Ihre Funktion folgende Antwort zurückgeben:

    { "batchItemFailures": [ { "itemIdentifier": "id2" }, { "itemIdentifier": "id4" } ] }

    Hier sind einige Beispiele für Funktionscodes, die die Liste der fehlgeschlagenen Nachrichten-IDs im Batch zurückgeben:

    .NET
    AWS SDK for .NET
    Anmerkung

    Es gibt noch mehr dazu. GitHub Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit Serverless-Beispielen.

    Melden von SQS-Batchelementfehlern mit Lambda unter Verwendung von .NET.

    // Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. // SPDX-License-Identifier: Apache-2.0 using Amazon.Lambda.Core; using Amazon.Lambda.SQSEvents; // Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class. [assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))] namespace sqsSample; public class Function { public async Task<SQSBatchResponse> FunctionHandler(SQSEvent evnt, ILambdaContext context) { List<SQSBatchResponse.BatchItemFailure> batchItemFailures = new List<SQSBatchResponse.BatchItemFailure>(); foreach(var message in evnt.Records) { try { //process your message await ProcessMessageAsync(message, context); } catch (System.Exception) { //Add failed message identifier to the batchItemFailures list batchItemFailures.Add(new SQSBatchResponse.BatchItemFailure{ItemIdentifier=message.MessageId}); } } return new SQSBatchResponse(batchItemFailures); } private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context) { if (String.IsNullOrEmpty(message.Body)) { throw new Exception("No Body in SQS Message."); } context.Logger.LogInformation($"Processed message {message.Body}"); // TODO: Do interesting work based on the new message await Task.CompletedTask; } }
    Go
    SDK für Go V2
    Anmerkung

    Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit Serverless-Beispielen.

    Melden von Fehlern bei SQS-Batch-Elementen mit Lambda mithilfe von Go.

    // Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. // SPDX-License-Identifier: Apache-2.0 package main import ( "context" "encoding/json" "fmt" "github.com/aws/aws-lambda-go/events" "github.com/aws/aws-lambda-go/lambda" ) func handler(ctx context.Context, sqsEvent events.SQSEvent) (map[string]interface{}, error) { batchItemFailures := []map[string]interface{}{} for _, message := range sqsEvent.Records { if /* Your message processing condition here */ { batchItemFailures = append(batchItemFailures, map[string]interface{}{"itemIdentifier": message.MessageId}) } } sqsBatchResponse := map[string]interface{}{ "batchItemFailures": batchItemFailures, } return sqsBatchResponse, nil } func main() { lambda.Start(handler) }
    Java
    SDK für Java 2.x
    Anmerkung

    Es gibt noch mehr dazu. GitHub Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit Serverless-Beispielen.

    Melden von Fehlern bei SQS-Batchelementen mit Lambda unter Verwendung von Java.

    // Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. // SPDX-License-Identifier: Apache-2.0 import com.amazonaws.services.lambda.runtime.Context; import com.amazonaws.services.lambda.runtime.RequestHandler; import com.amazonaws.services.lambda.runtime.events.SQSEvent; import com.amazonaws.services.lambda.runtime.events.SQSBatchResponse; import java.util.ArrayList; import java.util.List; public class ProcessSQSMessageBatch implements RequestHandler<SQSEvent, SQSBatchResponse> { @Override public SQSBatchResponse handleRequest(SQSEvent sqsEvent, Context context) { List<SQSBatchResponse.BatchItemFailure> batchItemFailures = new ArrayList<SQSBatchResponse.BatchItemFailure>(); String messageId = ""; for (SQSEvent.SQSMessage message : sqsEvent.getRecords()) { try { //process your message messageId = message.getMessageId(); } catch (Exception e) { //Add failed message identifier to the batchItemFailures list batchItemFailures.add(new SQSBatchResponse.BatchItemFailure(messageId)); } } return new SQSBatchResponse(batchItemFailures); } }
    JavaScript
    SDK für JavaScript (v3)
    Anmerkung

    Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit Serverless-Beispielen.

    Melden von SQS-Batch-Elementfehlern mit Lambda unter Verwendung von. JavaScript

    // Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. // SPDX-License-Identifier: Apache-2.0 export const handler = async (event, context) => { const batchItemFailures = []; for (const record of event.Records) { try { await processMessageAsync(record, context); } catch (error) { batchItemFailures.push({ itemIdentifier: record.messageId }); } } return { batchItemFailures }; }; async function processMessageAsync(record, context) { if (record.body && record.body.includes("error")) { throw new Error("There is an error in the SQS Message."); } console.log(`Processed message: ${record.body}`); }

    Melden von SQS-Batch-Elementfehlern mit Lambda unter Verwendung von. TypeScript

    // Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. // SPDX-License-Identifier: Apache-2.0 import { SQSEvent, SQSBatchResponse, Context, SQSBatchItemFailure, SQSRecord } from 'aws-lambda'; export const handler = async (event: SQSEvent, context: Context): Promise<SQSBatchResponse> => { const batchItemFailures: SQSBatchItemFailure[] = []; for (const record of event.Records) { try { await processMessageAsync(record); } catch (error) { batchItemFailures.push({ itemIdentifier: record.messageId }); } } return {batchItemFailures: batchItemFailures}; }; async function processMessageAsync(record: SQSRecord): Promise<void> { if (record.body && record.body.includes("error")) { throw new Error('There is an error in the SQS Message.'); } console.log(`Processed message ${record.body}`); }
    PHP
    SDK für PHP
    Anmerkung

    Es gibt noch mehr dazu. GitHub Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit Serverless-Beispielen.

    Melden von Fehlern bei SQS-Batch-Elementen mit Lambda mithilfe von PHP.

    // Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. // SPDX-License-Identifier: Apache-2.0 <?php use Bref\Context\Context; use Bref\Event\Sqs\SqsEvent; use Bref\Event\Sqs\SqsHandler; use Bref\Logger\StderrLogger; require __DIR__ . '/vendor/autoload.php'; class Handler extends SqsHandler { private StderrLogger $logger; public function __construct(StderrLogger $logger) { $this->logger = $logger; } /** * @throws JsonException * @throws \Bref\Event\InvalidLambdaEvent */ public function handleSqs(SqsEvent $event, Context $context): void { $this->logger->info("Processing SQS records"); $records = $event->getRecords(); foreach ($records as $record) { try { // Assuming the SQS message is in JSON format $message = json_decode($record->getBody(), true); $this->logger->info(json_encode($message)); // TODO: Implement your custom processing logic here } catch (Exception $e) { $this->logger->error($e->getMessage()); // failed processing the record $this->markAsFailed($record); } } $totalRecords = count($records); $this->logger->info("Successfully processed $totalRecords SQS records"); } } $logger = new StderrLogger(); return new Handler($logger);
    Python
    SDK für Python (Boto3)
    Anmerkung

    Es gibt noch mehr dazu. GitHub Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit Serverless-Beispielen.

    Melden von Fehlern bei SQS-Batchelementen mit Lambda unter Verwendung von Python.

    # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. # SPDX-License-Identifier: Apache-2.0 import json def lambda_handler(event, context): if event: batch_item_failures = [] sqs_batch_response = {} for record in event["Records"]: try: # process message except Exception as e: batch_item_failures.append({"itemIdentifier": record['messageId']}) sqs_batch_response["batchItemFailures"] = batch_item_failures return sqs_batch_response
    Ruby
    SDK für Ruby
    Anmerkung

    Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit Serverless-Beispielen.

    Melden von Fehlern bei SQS-Batchelementen mit Lambda unter Verwendung von Ruby.

    # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. # SPDX-License-Identifier: Apache-2.0 require 'json' def lambda_handler(event:, context:) if event batch_item_failures = [] sqs_batch_response = {} event["Records"].each do |record| begin # process message rescue StandardError => e batch_item_failures << {"itemIdentifier" => record['messageId']} end end sqs_batch_response["batchItemFailures"] = batch_item_failures return sqs_batch_response end end
    Rust
    SDK für Rust
    Anmerkung

    Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit Serverless-Beispielen.

    Melden von Fehlern bei SQS-Batchelementen mit Lambda unter Verwendung von Rust.

    // Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. // SPDX-License-Identifier: Apache-2.0 use aws_lambda_events::{ event::sqs::{SqsBatchResponse, SqsEvent}, sqs::{BatchItemFailure, SqsMessage}, }; use lambda_runtime::{run, service_fn, Error, LambdaEvent}; async fn process_record(_: &SqsMessage) -> Result<(), Error> { Err(Error::from("Error processing message")) } async fn function_handler(event: LambdaEvent<SqsEvent>) -> Result<SqsBatchResponse, Error> { let mut batch_item_failures = Vec::new(); for record in event.payload.records { match process_record(&record).await { Ok(_) => (), Err(_) => batch_item_failures.push(BatchItemFailure { item_identifier: record.message_id.unwrap(), }), } } Ok(SqsBatchResponse { batch_item_failures, }) } #[tokio::main] async fn main() -> Result<(), Error> { run(service_fn(function_handler)).await }

Wenn die fehlgeschlagenen Ereignisse nicht in die Warteschlange zurückkehren, finden Sie weitere Informationen unter Wie behebe ich Probleme mit der Lambda-Funktion ReportBatchItemFailures SQS? im AWS Knowledge Center.

Erfolgs- und Misserfolgsbedingungen

Lambda behandelt einen Batch als komplett erfolgreich, wenn die Funktion eines der folgenden Elemente zurückgibt:

  • Eine leere batchItemFailures-Liste

  • Eine ungültige batchItemFailures-Liste

  • Ein leeres EventResponse

  • Ein ungültiges EventResponse

Lambda behandelt einen Batch als komplett fehlgeschlagen, wenn die Funktion eines der folgenden Elemente zurückgibt:

  • Eine ungültige JSON-Antwort

  • Eine leere Zeichenfolge itemIdentifier

  • Ein ungültiges itemIdentifier

  • Ein itemIdentifier mit einem falschen Schlüsselnamen

  • Einen itemIdentifier-Wert mit einer Nachrichten-ID, die nicht existiert

CloudWatch Metriken

Um festzustellen, ob Ihre Funktion Fehler bei Chargenartikeln korrekt meldet, können Sie die Amazon SQS-Metriken NumberOfMessagesDeleted und die ApproximateAgeOfOldestMessage Amazon SQS-Metriken in Amazon CloudWatch überwachen.

  • NumberOfMessagesDeleted verfolgt die Anzahl der Nachrichten, die aus der Warteschlange entfernt wurden. Wenn der Wert auf 0 sinkt, ist dies ein Zeichen dafür, dass die Funktionsantwort fehlgeschlagene Nachrichten nicht korrekt zurückgibt.

  • ApproximateAgeOfOldestMessage verfolgt, wie lange die älteste Nachricht in der Warteschlange geblieben ist. Ein starker Anstieg dieser Metrik kann darauf hinweisen, dass die Funktion fehlgeschlagene Nachrichten nicht korrekt zurückgibt.

Konfigurationsparameter zu Amazon SQS

Alle Lambda-Ereignisquelltypen verwenden dieselben CreateEventSourceMappingUpdateEventSourceMappingAPI-Operationen. Allerdings gelten nur einige der Parameter für Amazon SQS.

Ereignisquellparameter, die für Amazon SQS gelten
Parameter Erforderlich Standard Hinweise

BatchSize

N

10

Bei Standardwarteschlangen beträgt der Maximalwert 10 000. Bei FIFO-Warteschlangen beträgt der Maximalwert 10.

Aktiviert

N

true

EventSourceArn

Y

Der ARN des Datenstroms oder eines Stream-Konsumenten

FunctionName

Y

FilterCriteria

N

Lambda-Ereignisfilterung

FunctionResponseTypes

N

Damit Ihre Funktion bestimmte Fehler in einem Batch meldet, beziehen Sie den Wert ReportBatchItemFailures in FunctionResponseTypes ein. Weitere Informationen finden Sie unter Implementierung von partiellen Batch-Antworten.

MaximumBatchingWindowInSeconds

N

0

ScalingConfig

N

Konfigurieren der maximalen Gleichzeitigkeit für Amazon-SQS-Ereignisquellen