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.
Wiederholungen für langlebige Lambda-Funktionen
Stabile Funktionen bieten automatische Wiederholungsfunktionen, die Ihre Anwendungen widerstandsfähig gegen vorübergehende Ausfälle machen. Das SDK verarbeitet Wiederholungen auf zwei Ebenen: Schrittwiederholungen bei Fehlern in der Geschäftslogik und Backend-Wiederholungen bei Infrastrukturausfällen.
Wiederholungen in Schritt 2
Wenn innerhalb eines Schritts eine nicht abgefangene Ausnahme auftritt, wiederholt das SDK den Schritt automatisch auf der Grundlage der konfigurierten Wiederholungsstrategie. Bei Wiederholungsschritten handelt es sich um Checkpoint-Operationen, die es dem SDK ermöglichen, die Ausführung auszusetzen und später wieder aufzunehmen, ohne dass der Fortschritt verloren geht.
Verhalten bei Wiederholungsversuchen
In der folgenden Tabelle wird beschrieben, wie das SDK Ausnahmen schrittweise behandelt:
| Szenario | Was passiert | Messung der Auswirkungen |
|---|---|---|
| Ausnahme im Gleichschritt mit den verbleibenden Wiederholungsversuchen | Das SDK erstellt einen Checkpoint für den Wiederholungsversuch und unterbricht die Funktion. Beim nächsten Aufruf wiederholt der Schritt den Vorgang mit der konfigurierten Backoff-Verzögerung. | 1 Vorgang + Fehler, Nutzlastgröße |
| Ausnahme in Schritt 2 ohne weitere Wiederholungsversuche | Der Schritt schlägt fehl und löst eine Ausnahme aus. Wenn Ihr Handlercode diese Ausnahme nicht abfängt, schlägt die gesamte Ausführung fehl. | 1 Vorgang + Fehler, Nutzlastgröße |
Wenn ein Schritt erneut versucht werden muss, überprüft das SDK den Wiederholungsstatus und beendet den Lambda-Aufruf, wenn keine andere Arbeit ausgeführt wird. Dadurch kann das SDK Backoff-Verzögerungen implementieren, ohne Rechenressourcen zu verbrauchen. Die Funktion wird nach der Backoff-Periode automatisch wieder aufgenommen.
Strategien zur schrittweisen Wiederholung konfigurieren
Konfigurieren Sie Strategien für Wiederholungen, um zu steuern, wie Schritte mit Fehlern umgehen. Sie können die maximale Anzahl von Versuchen, Abbruchintervalle und Bedingungen für Wiederholungsversuche angeben. Eine vollständige Referenz der Strategiehelfer, Voreinstellungen und benutzerdefinierten Strategien für Wiederholungen finden Sie unter Wiederholungen in der Durable Execution SDK-Dokumentation.
Ausnahmen außerhalb der Stufen
Wenn in Ihrem Handlercode, aber außerhalb eines Schritts, eine nicht abgefangene Ausnahme auftritt, markiert das SDK die Ausführung als fehlgeschlagen. Dadurch wird sichergestellt, dass Fehler in Ihrer Anwendungslogik ordnungsgemäß erfasst und gemeldet werden.
| Szenario | Was passiert | Messung der Auswirkungen |
|---|---|---|
| Ausnahme im Handlercode außerhalb eines beliebigen Schritts | Das SDK markiert die Ausführung als FEHLGESCHLAGEN und gibt den Fehler zurück. Die Ausnahme wird nicht automatisch wiederholt. | Fehler bei der Payload-Größe |
Um die automatische Wiederholung von fehleranfälligem Code zu aktivieren, schließen Sie ihn in einen Schritt mit einer Wiederholungsstrategie ein. Schritte ermöglichen eine automatische Wiederholung mit konfigurierbarem Backoff, während Code außerhalb der Schritte sofort fehlschlägt.
Der Aufruf wird wiederholt
Wiederholungen auf Aufrufebene werden unterschiedlich behandelt, je nachdem, wie versucht wird, die dauerhafte Lambda-Funktion aufzurufen. In der folgenden Tabelle wird beschrieben, wie die verschiedenen Aufruftypen die Wiederholungsversuche auf Aufrufebene beeinflussen können.
| Aufruftyp | Was passiert |
|---|---|
| Synchroner Aufruf | Lambda wiederholt den Aufruf bei einem Fehler während der Ausführung einer dauerhaften Funktion nicht automatisch. Wiederholungsversuche bei fehlgeschlagenen Aufrufen hängen von der Quelle des synchronen Aufrufs ab. Sie verwenden beispielsweise das AWS SDK InternalFailure und ThrottlingException werden standardmäßig automatisch wiederholt. |
| Asynchroner Aufruf | Schlägt die Ausführung einer dauerhaften Funktion fehl (sie tritt beispielsweise in den Status FAILED, STOPPED oder TIMED_OUT ein), wiederholt Lambda die Ausführung nicht. Dies unterscheidet sich von Standard-Lambda-Funktionen, bei denen Lambda die Funktion bei asynchronen Aufrufen erneut versucht. Die MaximumRetryAttempts Einstellung für asynchrone Aufrufe gilt nicht für dauerhafte Ausführungen. Wenn Sie eine Dead-Letter-Queue (DLQ) für die Funktion konfigurieren, sendet Lambda das auslösende Ereignis an die DLQ. |
| ESM (Zuordnung der Ereignisquellen) | Lambda wiederholt standardmäßig den gesamten Batch, bis er erfolgreich ist. Für Stream-Quellen (DynamoDB und Kinesis) können Sie die maximale Anzahl von Wiederholungsversuchen von Lambda konfigurieren, wenn Ihre Funktion einen Fehler zurückgibt. Siehe Stapelverarbeitung von Ereignisquellenzuordnungen. Für Amazon SQS ESM können Sie die maximale Anzahl an Wiederholungsversuchen über einen DLQ in der ursprünglichen Amazon SQS-Warteschlange konfigurieren. Siehe Amazon SQS ESM konfigurieren. Als bewährte Methode könnten Sie einen DLQ auf Funktionsebene in Betracht ziehen, und Lambda sendet das auslösende Ereignis, das fehlschlägt, an den DLQ. Siehe Funktion DLQ. Hinzufügen einer Warteschlange für unzustellbare Nachrichten |
| Direkter Trigger | Das hängt vom „Trigger“ ab. Lambda verarbeitet beispielsweise Funktionen, die durch Amazon S3-Ereignisbenachrichtigungen ausgelöst werden, asynchron. Siehe Verarbeiten von Amazon SQS-Ereignisbenachrichtigungen mit Lambda. Lambda verarbeitet Funktionen, die durch Amazon SNS-Ereignisbenachrichtigungen ausgelöst werden, asynchron. Siehe Aufrufen von Lambda-Funktionen mit Amazon SNS-Benachrichtigungen. Das Verhalten beim erneuten Versuch eines asynchronen Aufrufs ist weiter oben im Tabelleneintrag „Asynchroner Aufruf“ beschrieben. Wenn Amazon SNS Lambda nicht erreichen kann, oder die Nachricht abgelehnt wird, wiederholt Amazon SNS den Vorgang in zunehmenden Intervallen über mehrere Stunden. Weitere Details finden Sie unter Zuverlässigkeit |
Wiederholungen im Backend
Backend-Wiederholungen erfolgen, wenn Lambda auf Infrastrukturausfälle oder Laufzeitfehler stößt oder wenn das SDK nicht mit dem Durable Execution Service kommunizieren kann. Lambda versucht diese Fehler automatisch erneut, damit Ihre dauerhaften Funktionen nach vorübergehenden Infrastrukturproblemen wiederhergestellt werden können.
Backend-Szenarien für Wiederholungsversuche
Lambda versucht Ihre Funktion automatisch erneut, wenn die folgenden Szenarien auftreten:
-
Interne Servicefehler — Wenn Lambda oder der Durable Execution Service einen 5xx-Fehler zurückgibt, was auf ein vorübergehendes Serviceproblem hinweist.
-
Drosselung — Wenn Ihre Funktion aufgrund von Parallelitätsbeschränkungen oder Dienstkontingenten gedrosselt wird.
-
Timeouts — Wenn das SDK den dauerhaften Ausführungsdienst nicht innerhalb des Timeout-Zeitraums erreichen kann.
-
Sandbox-Initialisierungsfehler — Wenn Lambda die Ausführungsumgebung nicht initialisieren kann.
-
Laufzeitfehler — Wenn die Lambda-Laufzeit auf Fehler außerhalb Ihres Funktionscodes stößt, wie z. B. Speicherfehler oder Prozessabstürze.
-
Ungültige Checkpoint-Token-Fehler — Wenn das Checkpoint-Token nicht mehr gültig ist, was in der Regel auf dienstseitige Statusänderungen zurückzuführen ist.
In der folgenden Tabelle wird beschrieben, wie das SDK mit diesen Szenarien umgeht:
| Szenario | Was passiert | Messung der Auswirkungen |
|---|---|---|
| Laufzeitfehler außerhalb des dauerhaften Handlers (OOM, Timeout, Absturz) | Lambda versucht den Aufruf automatisch erneut. Das SDK wird vom letzten Checkpoint aus wiederholt, wobei abgeschlossene Schritte übersprungen werden. | Fehler: Nutzlastgröße + 1 Vorgang pro Wiederholungsversuch |
Servicefehler (5xx) oder Timeout beim Aufrufen von/APIs CheckpointDurableExecution GetDurableExecutionState |
Lambda versucht den Aufruf automatisch erneut. Das SDK wird vom letzten Checkpoint aus erneut abgespielt. | Fehler: Nutzlastgröße + 1 Vorgang pro Wiederholungsversuch |
Drosselung (429) oder ungültiges Checkpoint-Token beim Aufrufen von/APIs CheckpointDurableExecution GetDurableExecutionState |
Lambda wiederholt den Aufruf automatisch mit exponentiellem Backoff. Das SDK wird vom letzten Checkpoint aus wiederholt. | Fehler: Nutzlastgröße + 1 Vorgang pro Wiederholungsversuch |
Client-Fehler (4xx, außer 429 und ungültiges Token) bei/APIs CheckpointDurableExecution GetDurableExecutionState |
Das SDK markiert die Ausführung als FEHLGESCHLAGEN. Es erfolgt kein automatischer Wiederholungsversuch, da der Fehler auf ein permanentes Problem hinweist. | Fehler: Größe der Nutzlast |
Backend-Wiederholungen verwenden einen exponentiellen Backoff und fahren fort, bis die Funktion erfolgreich ist oder das Ausführungs-Timeout erreicht ist. Während der Wiedergabe überspringt das SDK abgeschlossene Checkpoints und setzt die Ausführung ab dem letzten erfolgreichen Vorgang fort, um sicherzustellen, dass Ihre Funktion abgeschlossene Arbeiten nicht erneut ausführt.
Versuchen Sie es erneut mit den bewährten Methoden
Beachten Sie bei der Konfiguration von Wiederholungsstrategien die folgenden bewährten Methoden:
-
Konfigurieren Sie explizite Wiederholungsstrategien — Verlassen Sie sich nicht auf das standardmäßige Wiederholungsverhalten in der Produktion. Konfigurieren Sie Strategien für explizite Wiederholungen mit angemessenen maximalen Versuchen und Backoff-Intervallen für Ihren Anwendungsfall.
-
Verwenden Sie bedingte Wiederholungen — Implementieren Sie eine
shouldRetryLogik, um nur vorübergehende Fehler (Ratengrenzen, Timeouts) zu wiederholen und bei dauerhaften Fehlern (Validierungsfehler, nicht gefunden) schnell zu scheitern. -
Legen Sie die maximale Anzahl an Versuchen fest — ein ausgewogenes Verhältnis zwischen Belastbarkeit und Ausführungszeit. Zu viele Wiederholungsversuche können die Fehlererkennung verzögern, während zu wenige zu unnötigen Fehlern führen können.
-
Verwenden Sie exponentielles Backoff — Exponentielles Backoff reduziert die Belastung nachgelagerter Dienste und erhöht die Wahrscheinlichkeit einer Wiederherstellung nach vorübergehenden Ausfällen.
-
Fehleranfälligen Code in Schritte unterteilen — Code, der außerhalb von Schritten liegt, kann nicht automatisch wiederholt werden. Führen Sie externe API-Aufrufe, Datenbankabfragen und andere fehleranfällige Operationen schrittweise mit Wiederholungsstrategien zusammen.
-
Überwachen Sie Wiederholungskennzahlen — Verfolgen Sie schrittweise Wiederholungsvorgänge und Ausführungsfehler in Amazon, um Muster CloudWatch zu identifizieren und Wiederholungsstrategien zu optimieren.
