Wiederholung von Cloud-Anforderungen konfigurieren

  • Freigeben Version: Yokohama
  • Aktualisiert 30. Januar 2025
  • 2 Minuten Lesedauer
  • Wenn eine Anforderung während der Discovery von einem Cloud-Anbieter gedrosselt wird, bietet die Konfiguration der Wiederholung von Cloud-Anforderungen eine anpassbare Methode zum erneuten Versuch von Anforderungen. Muster für Discovery und Service-MappingEnthält eine Wiederholungskonfiguration für AWSUnd Azure. Sie können die enthaltene Konfiguration anpassen oder eine eigene erstellen.

    Discovery-Administratoren und Cloud-Administratoren können unter auf die Konfiguration der Anforderungswiederholung zugreifen Alle > Discovery > Wiederholung von Cloud-Anforderungen konfigurierenan. Sie können eine Konfiguration für jeden Anbieter erstellen.

    Wenn eine Anforderung gedrosselt wird, verwendet das Wiederholungs-Framework die für den Provider definierte Wiederholungskonfiguration, um Wiederholungen zu verarbeiten, bevor die endgültige Antwort an die ApiCommand-Klassen zurückgegeben wird:
    • AwsApiCommand
    • AzureApiCommand

    Die Wiederholungskonfigurationen werden mit synchronisiert MID ServersDurch MID-ServerEigenschaft, mid.cloud.discovery.retry.configuration.

    Es gibt die folgenden Wiederholungsstrategien:
    • Exponentieller Backoff
    • Antwortheader-Backoff
    • Anwenderdefiniertes Backoff

    Exponentieller Backoff

    Für die folgende Beispielkonfiguration:
    Einstellung Wert
    Max. Wiederholungen 3
    Antwortcodes 429
    Basisverzögerung in ms 1000
    Max. Verzögerung in ms 10000
    Zusätzliches Verzögerungsfenster in ms 1500
    Die Wiederholungsstrategie für exponentielle Backoff funktioniert wie folgt:
    • Erster Versuch: Der Backoff-Multiplikator wird zufällig zwischen 0 und 1 ausgewählt. Der maximale Verzögerungswert beträgt 400 ms (400 * 1).
    • 2. Wiederholung: Der Backoff-Multiplikator wird zufällig zwischen 0 und 3 ausgewählt. Der maximale Verzögerungswert beträgt 1200 ms (400 * 3).
    • 3. Wiederholung: Der Backoff-Multiplikator wird zufällig zwischen 0 und 7 ausgewählt. Der maximale Verzögerungswert beträgt 2800 ms (400 * 7).

    Wenn die Verzögerung bei nachfolgenden Wiederholungen 10000 (die maximale Verzögerung) überschreitet, werden 10000 als anfängliche Verzögerung verwendet.

    Sobald die anfängliche Verzögerung generiert wurde, wird der Verzögerung ein Jitter hinzugefügt. Das Jitter-Fenster wird durch definiert Zusätzliches Verzögerungsfenster in ms Feld. Das System wählt einen zufälligen Wert zwischen 0 und 1500 aus und fügt ihn der anfänglichen Verzögerung hinzu.

    Wenn die anfängliche Verzögerung 500 beträgt, kann die endgültige Verzögerung (mit Jitter) ein Wert zwischen 500 und 2000 ms sein.

    Antwortheader-Backoff

    Für die folgende Beispielkonfiguration:
    Einstellung Wert
    Max. Wiederholungen 3
    Antwortcodes 429
    Antwortheader Erneut Versuchen Nach
    Verzögerungseinheit des Antwortheaders Sekunden
    Zusätzliches Verzögerungsfenster in ms 1500
    Die Backoff-Strategie für den Antwortheader funktioniert wie folgt:
    • Rufen Sie den Wert des Headers ab Retry-AfterAus der Serverantwort.
    • Konvertieren Sie Retry-AfterAuf Millisekunden durch Multiplikation mit 1000.

    Sobald die anfängliche Verzögerung generiert wurde, wird der Verzögerung ein Jitter hinzugefügt. Das Jitter-Fenster wird durch definiert Zusätzliches Verzögerungsfenster in ms Feld. Das System wählt einen zufälligen Wert zwischen 0 und 1500 aus und fügt ihn der anfänglichen Verzögerung hinzu.

    Wenn die anfängliche Verzögerung 2000 beträgt, kann die endgültige Verzögerung (mit Jitter) ein Wert zwischen 2000 und 3500 ms sein.

    Anwenderdefiniertes Backoff

    Mit einer anwenderdefinierten Backoff-Wiederholungsstrategie definieren Sie Max. Wiederholungen Und Antwortcodes Und erstellen Sie eigene Mid-Skripteinbindung Das definiert, wie Anforderungen mit wiederholt werden getDelay()Funktion. Weitere Informationen finden Sie unter Skripteinbindungen .