Beispiel für ein Standard-Warteschlangen-Nachrichtenereignis Beispiel für ein FIFO-Warteschlangen-Nachrichtenereignis Konfigurieren einer Warteschlange zur Verwendung mit Lambda Berechtigungen für die Ausführungsrolle Konfigurieren einer Warteschlange als Ereignisquelle Skalierung und Verarbeitung Maximale Gleichzeitigkeit APIs für die Ereignisquellenzuordnung Backoff-Strategie für fehlgeschlagene Aufrufe Implementierung von partiellen Batch-Antworten Konfigurationsparameter zu Amazon SQS

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 die 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. Deshalb muss der Funktionscode in der Lage sein, dieselbe Nachricht mehrmals ohne unbeabsichtigte Begleiterscheinungen zu verarbeiten.

Um zu verhindern, dass Lambda eine Nachricht mehrfach verarbeitet, können Sie entweder Ihre Zuordnung von Ereignisquellen so konfigurieren, dass Batch-Elementfehler in Ihre Funktionsantwort aufgenommen werden, oder Sie können die Amazon-SQS-API-Aktion DeleteMessage verwenden, um Nachrichten aus der Warteschlange zu entfernen, während Ihre Lambda-Funktion diese erfolgreich verarbeitet. Weitere Informationen über die Verwendung der Amazon SQS API finden Sie unter Referenz zu Amazon Simple Queue Service API

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

Lambda benötigt die folgenden Berechtigungen zum Verwalten von Nachrichten in der Amazon-SQS-Warteschlange. Fügen Sie sie 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:

kms:Decrypt

Konfigurieren einer Warteschlange als Ereignisquelle

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 in der Lambda-Konsole zu konfigurieren, erstellen Sie einen SQS-Auslöser.

So erstellen Sie einen Auslöser

Öffnen Sie die Seite Funktionen der Lambda-Konsole.
Wählen Sie den Namen einer Funktion aus.
Wählen Sie unter Function overview (Funktionsübersicht) die Option Add trigger (Trigger hinzufügen).
Wählen Sie den SQS-Auslösertyp.
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 Metadatenfeldern von Amazon SQS finden Sie in der Dokumentation zur ReceiveMessage-API-Operation in der Referenz für die API von Amazon Simple Queue Service.

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 60 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 Grundlegendes zur Skalierung von AWS Lambda mit Amazon-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 60 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. Lambda sortiert die Nachrichten in Gruppen und sendet jeweils nur einen Batch für eine Gruppe. 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 als Ereignisquelle im AWS-Compute Blog.

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

Öffnen Sie die Seite Funktionen der Lambda-Konsole.
Wählen Sie den Namen einer Funktion aus.
Wählen Sie unter Function overview (Funktionsübersicht) die Option SQS aus. Dadurch wird die Registerkarte Configuration (Konfiguration) geöffnet.
Wählen Sie den Amazon-SQS-Auslöser aus und klicken Sie auf Edit (Bearbeiten).
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.
Wählen Sie Save (Speichern).

Konfigurieren der maximalen Gleichzeitigkeit mithilfe der AWS Command Line Interface (AWS CLI)

Verwenden Sie den update-event-source-mapping-Befehl mit der Option --scaling-config. 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 CreateEventSourceMapping- oder UpdateEventSourceMapping-Aktion mit einem ScalingConfig-Objekt.

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:

Im folgenden Beispiel wird die AWS CLI verwendet, um eine Funktion mit dem Namen my-function einer Amazon-SQS-Warteschlange zu mappen, die durch den Amazon-Ressourcennamen (ARN) angegeben wird; die Batchgröße beträgt 5 und das Batch-Fenster beträgt 60 Sekunden.


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, setzt Lambda schrittweise Wiederholungsversuche zurück, indem es die Menge der Gleichzeitigkeit reduziert, die Ihrer Zuordnung von Ereignisquellen in Amazon SQS zugewiesen ist. Wenn Aufrufe weiterhin fehlschlagen, verwirft Lambda die Nachricht schließlich, ohne es erneut zu versuchen.
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 Zuordnung von Ereignisquellen die Aktion FunctionResponseTypes 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

Sehen Sie sich die bewährten Methoden für die Implementierung von partiellen Batch-Antworten an.
Führen Sie den folgenden Befehl aus, um ReportBatchItemFailures für Ihre Funktion zu aktivieren. Führen Sie den list-event-source-mappings AWS CLI-Befehl aus, um die UID Ihrer Zuordnung von Ereignisquellen abzurufen.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--function-response-types "ReportBatchItemFailures"
```

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

Auf GitHub finden Sie noch mehr. 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.


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;
    }
}

Java

SDK für Java 2.x

Anmerkung

Auf GitHub finden Sie noch mehr. 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.


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);
     }
}

Python

SDK für Python (Boto3)

Anmerkung

Auf GitHub finden Sie noch mehr. 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.


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

Wenn die fehlgeschlagenen Ereignisse nicht in die Warteschlange zurückkehren, finden Sie weitere Informationen unter Wie behebe ich die Lambda-Funktion SQS ReportBatchItemFailures? 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 herauszufinden, ob Ihre Funktion Batch-Element-Fehler korrekt meldet, können Sie die Amazon-SQS-Metriken NumberOfMessagesDeleted und ApproximateAgeOfOldestMessage 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-Ereignisquellentypen verwenden dieselben API-Operationen CreateEventSourceMapping und UpdateEventSourceMapping. 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.
Enabled	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

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Beispiel-Code

Tutorial