Wiederholungen für langlebige Lambda-Funktionen - AWS Lambda
Schrittweise WiederholungenAusnahmen außerhalb von SchrittenWiederholungen im BackendVersuchen Sie es erneut mit bewährten Methoden

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

Langlebige Funktionen bieten automatische Wiederholungsfunktionen, die Ihre Anwendungen widerstandsfähig gegen vorübergehende Ausfälle machen. Das SDK verarbeitet Wiederholungen auf zwei Ebenen: schrittweise Wiederholungen bei Ausfällen der Geschäftslogik und Backend-Wiederholungen bei Infrastrukturausfällen.

Schrittweise Wiederholungen

Wenn innerhalb eines Schritts eine nicht abgefangene Ausnahme auftritt, wiederholt das SDK den Schritt automatisch auf der Grundlage der konfigurierten Wiederholungsstrategie. Wiederholungen von Schritten sind Operationen, bei denen das SDK die Ausführung unterbrechen und später fortsetzen kann, ohne dass der Fortschritt verloren geht.

Verhalten bei schrittweisen Wiederholungen

In der folgenden Tabelle wird beschrieben, wie das SDK Ausnahmen in Schritten behandelt:

Szenario Was passiert Messung der Auswirkungen
Ausnahme im Gleichschritt mit den verbleibenden Wiederholungsversuchen Das SDK erstellt einen Checkpoint für den erneuten Versuch und unterbricht die Funktion. Beim nächsten Aufruf wiederholt sich der Schritt mit der konfigurierten Backoff-Verzögerung. 1 Vorgang + Fehler, Payload-Größe
Ausnahme im Schritt ohne verbleibende Wiederholungsversuche Der Schritt schlägt fehl und löst eine Ausnahme aus. Wenn Ihr Handler-Code diese Ausnahme nicht catch, schlägt die gesamte Ausführung fehl. 1 Vorgang + Fehler, Größe der Nutzlast

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. Auf diese Weise kann das SDK Backoff-Verzögerungen implementieren, ohne Rechenressourcen zu verbrauchen. Die Funktion wird nach Ablauf der Backoff-Periode automatisch wieder aufgenommen.

Konfiguration von Strategien zur schrittweisen Wiederholung

Konfigurieren Sie Wiederholungsstrategien, um zu steuern, wie Schritte mit Fehlern umgehen. Sie können maximale Versuche, Backoff-Intervalle und Bedingungen für Wiederholungsversuche angeben.

Exponentieller Backoff mit maximaler Anzahl von Versuchen:

TypeScript

const result = await context.step('call-api', async () => {
  const response = await fetch('https://api.example.com/data');
  if (!response.ok) throw new Error(`API error: ${response.status}`);
  return await response.json();
}, {
  retryStrategy: (error, attemptCount) => {
    if (attemptCount >= 5) {
      return { shouldRetry: false };
    }
    // Exponential backoff: 2s, 4s, 8s, 16s, 32s (capped at 300s)
    const delay = Math.min(2 * Math.pow(2, attemptCount - 1), 300);
    return { shouldRetry: true, delay: { seconds: delay } };
  }
});
Python

def retry_strategy(error, attempt_count):
    if attempt_count >= 5:
        return {'should_retry': False}
    # Exponential backoff: 2s, 4s, 8s, 16s, 32s (capped at 300s)
    delay = min(2 * (2 ** (attempt_count - 1)), 300)
    return {'should_retry': True, 'delay': delay}

result = context.step(
    lambda _: call_external_api(),
    name='call-api',
    config=StepConfig(retry_strategy=retry_strategy)
)

Backoff mit festem Intervall:

TypeScript

const orders = await context.step('query-orders', async () => {
  return await queryDatabase(event.userId);
}, {
  retryStrategy: (error, attemptCount) => {
    if (attemptCount >= 3) {
      return { shouldRetry: false };
    }
    return { shouldRetry: true, delay: { seconds: 5 } };
  }
});
Python

def retry_strategy(error, attempt_count):
    if attempt_count >= 3:
        return {'should_retry': False}
    return {'should_retry': True, 'delay': 5}

orders = context.step(
    lambda _: query_database(event['userId']),
    name='query-orders',
    config=StepConfig(retry_strategy=retry_strategy)
)

Bedingter Wiederholungsversuch (nur bei bestimmten Fehlern wiederholen):

TypeScript

const result = await context.step('call-rate-limited-api', async () => {
  const response = await fetch('https://api.example.com/data');
  
  if (response.status === 429) throw new Error('RATE_LIMIT');
  if (response.status === 504) throw new Error('TIMEOUT');
  if (!response.ok) throw new Error(`API_ERROR_${response.status}`);
  
  return await response.json();
}, {
  retryStrategy: (error, attemptCount) => {
    // Only retry rate limits and timeouts
    const isRetryable = error.message === 'RATE_LIMIT' || error.message === 'TIMEOUT';
    
    if (!isRetryable || attemptCount >= 3) {
      return { shouldRetry: false };
    }
    
    // Exponential backoff: 1s, 2s, 4s (capped at 30s)
    const delay = Math.min(Math.pow(2, attemptCount - 1), 30);
    return { shouldRetry: true, delay: { seconds: delay } };
  }
});
Python

def retry_strategy(error, attempt_count):
    # Only retry rate limits and timeouts
    is_retryable = str(error) in ['RATE_LIMIT', 'TIMEOUT']
    
    if not is_retryable or attempt_count >= 3:
        return {'should_retry': False}
    
    # Exponential backoff: 1s, 2s, 4s (capped at 30s)
    delay = min(2 ** (attempt_count - 1), 30)
    return {'should_retry': True, 'delay': delay}

result = context.step(
    lambda _: call_rate_limited_api(),
    name='call-rate-limited-api',
    config=StepConfig(retry_strategy=retry_strategy)
)

Wiederholungen deaktivieren:

TypeScript

const isDuplicate = await context.step('check-duplicate', async () => {
  return await checkIfOrderExists(event.orderId);
}, {
  retryStrategy: () => ({ shouldRetry: false })
});
Python

is_duplicate = context.step(
    lambda _: check_if_order_exists(event['orderId']),
    name='check-duplicate',
    config=StepConfig(
        retry_strategy=lambda error, attempt: {'should_retry': False}
    )
)

Wenn die Wiederholungsstrategie zurückkehrtshouldRetry: false, schlägt der Schritt ohne erneute Versuche sofort fehl. Verwenden Sie diese Option für Operationen, die nicht wiederholt werden sollten, z. B. Idempotenzprüfungen oder Operationen mit Nebenwirkungen, die nicht sicher wiederholt werden können.

Ausnahmen außerhalb von Schritten

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 Handler-Code 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 Größe der Payload

Um die automatische Wiederholung von fehleranfälligem Code zu aktivieren, schließen Sie den Vorgang in einem Schritt mit einer Wiederholungsstrategie ab. Schritte bieten automatische Wiederholungsversuche mit konfigurierbarem Backoff, während Code außerhalb von Schritten sofort fehlschlägt.

Wiederholungen im Backend

Backend-Wiederholungen treten auf, 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, um sicherzustellen, dass Ihre dauerhaften Funktionen nach vorübergehenden Infrastrukturproblemen wiederhergestellt werden können.

Szenarien für Wiederholungsversuche im Backend

Lambda versucht Ihre Funktion automatisch erneut, wenn die folgenden Szenarien auftreten:

  • Interne Dienstfehler — 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 Servicekontingenten gedrosselt wird.

  • Timeouts — Wenn das SDK den Durable Execution Service innerhalb des Timeout-Zeitraums nicht 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, z. B. out-of-memory Fehler oder Prozessabstürze.

  • Ungültige Checkpoint-Token-Fehler — Wenn das Checkpoint-Token nicht mehr gültig ist, typischerweise aufgrund von Statusänderungen auf der Serviceseite.

In der folgenden Tabelle wird beschrieben, wie das SDK mit diesen Szenarien umgeht:

Szenario Was passiert Messung der Auswirkungen
Laufzeitfehler außerhalb des Durable-Handlers (OOM, Timeout, Absturz) Lambda versucht den Aufruf automatisch erneut. Das SDK wiederholt die Wiedergabe ab dem letzten Checkpoint, wobei abgeschlossene Schritte übersprungen werden. Fehler: Payload-Größe + 1 Vorgang pro Wiederholung
Dienstfehler (5xx) oder Timeout beim Aufrufen/CheckpointDurableExecutionGetDurableExecutionState APIs Lambda versucht den Aufruf automatisch erneut. Das SDK wiederholt die Wiedergabe ab dem letzten Checkpoint. Fehler: Payload-Größe + 1 Vorgang pro Wiederholung
Drosselung (429) oder ungültiges Checkpoint-Token beim Aufrufen von/CheckpointDurableExecutionGetDurableExecutionState APIs Lambda wiederholt den Aufruf automatisch mit exponentiellem Backoff. Das SDK wiederholt die Wiedergabe ab dem letzten Checkpoint. Fehler: Payload-Größe + 1 Vorgang pro Wiederholung
Client-Fehler (4xx, außer 429 und ungültigem Token) wenn/CheckpointDurableExecutionGetDurableExecutionState APIs Das SDK markiert die Ausführung als FEHLGESCHLAGEN. Es erfolgt kein automatischer Wiederholungsversuch, da der Fehler auf ein permanentes Problem hinweist. Fehler bei der Größe der Payload

Backend-Wiederholungen verwenden exponentielles Backoff und werden fortgesetzt, bis die Funktion erfolgreich ist oder das Ausführungstimeout erreicht ist. Während der Wiedergabe überspringt das SDK abgeschlossene Prüfpunkte und setzt die Ausführung ab dem letzten erfolgreichen Vorgang fort, um sicherzustellen, dass Ihre Funktion abgeschlossene Arbeit nicht erneut ausführt.

Versuchen Sie es erneut mit 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 einer für Ihren Anwendungsfall angemessenen maximalen Anzahl von Versuchen und Backoff-Intervallen.

  • Verwenden Sie bedingte Wiederholungen — Implementieren Sie shouldRetry Logik, um nur vorübergehende Fehler (Ratenbegrenzungen, Timeouts) zu wiederholen und bei dauerhaften Fehlern (Validierungsfehler, nicht gefunden) schnell fehlzuschlagen.

  • Stellen Sie eine angemessene maximale Anzahl von Versuchen ein — Balance zwischen Belastbarkeit und Ausführungszeit. Zu viele Wiederholungen können die Fehlererkennung verzögern, während zu wenige Versuche zu unnötigen Fehlern führen können.

  • Exponentielles Backoff verwenden — Exponentielles Backoff reduziert die Belastung nachgeschalteter Dienste und erhöht die Wahrscheinlichkeit einer Wiederherstellung nach vorübergehenden Ausfällen.

  • Fehleranfälligen Code schrittweise zusammenfassen — Code außerhalb von Schritten kann nicht automatisch wiederholt werden. Integrieren Sie externe API-Aufrufe, Datenbankabfragen und andere fehleranfällige Operationen schrittweise mit Wiederholungsstrategien.

  • Überwachen Sie Wiederholungsmetriken — Verfolgen Sie schrittweise Wiederholungsvorgänge und Ausführungsfehler in Amazon CloudWatch , um Muster zu identifizieren und Wiederholungsstrategien zu optimieren.