Support Kontakt Support | Systemstatus Systemstatus

Fallback / Retry-Strategie

In diesem Thema wird die Notwendigkeit einer Fallback- / Wiederholungsstrategie für dynamische Ingest-Anforderungen erläutert. Außerdem wird eine allgemeine Beschreibung der Implementierung eines solchen Problems bereitgestellt.

Hintergrund

Dynamic Ingest erzwingt die Ratenbegrenzung (pro Konto) auf zwei Arten:

  • Nicht mehr als 20-Anfragen (CMS API und / oder Ingest-API-Anforderungen) pro Sekunde sind zulässig
  • Nicht mehr als gleichzeitige 100-Jobs mit normaler Priorität sind zulässig

Die erste ist nicht schwer in Ihrer App zu verwalten - Sie können nur eine Verzögerung von 3 Sekunden oder mehr zwischen Anfragen auferlegen. Die zweite ist komplizierter, da es keine Möglichkeit gibt, das System direkt abzufragen, um festzustellen, wie viele Jobs Sie gerade verarbeiten. Verwenden Sie alternativ die Option Warteschlange mit niedriger Priorität Damit können Sie mehr als 100-Jobs in die Warteschlange stellen.

Sie können einfach auf einen bestimmten Zeitraum warten und Anforderungen wiederholen, bis sie erfolgreich sind, aber Sie können ein rationaleres Fallback- / Wiederholungs-System implementieren, indem Sie darauf warten Benachrichtigungen aus dem Dynamic Ingest System und nutzen Sie die Informationen, um Aufträge selbst während des Fluges zu verfolgen.

Eine Möglichkeit, dies zu implementieren, wäre, eine Transceiver-App zu erstellen, die sowohl die Ingest-Anfragen übermittelt als auch auf Benachrichtigungen wartet. Das folgende Diagramm zeigt die High-Level-Logik einer solchen App.

Transceiverlogik
Transceiverlogik

Beispiel-App

Sie können die Quelle für ein Beispiel finden Knoten-Express App in diesem Github Repo


Seite zuletzt aktualisiert am 12. Juni 2020