Fallback-/Retry-Strategie

In diesem Thema wird die Notwendigkeit einer Fallback-/Retry-Strategie für Dynamic Ingest-Anforderungen erläutert und eine allgemeine Beschreibung der Implementierung einer solchen Strategie gegeben.

Hintergrund

Dynamisches Ingest erzwingt eine Ratenbegrenzung (pro Konto) auf zwei Arten:

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

Die erste ist in Ihrer App nicht schwer zu verwalten - Sie können einfach eine Verzögerung von 3 Sekunden oder mehr zwischen den Anfragen festlegen. Die zweite ist komplizierter, da es keine Möglichkeit gibt, das System direkt abzufragen, um festzustellen, wie viele Jobs Sie derzeit bearbeiten. Erwägen Sie alternativ die Verwendung der Warteschlange mit niedriger Priorität Dadurch können Sie mehr als 100 Jobs in die Warteschlange stellen.

Sie können einfach eine gewisse Zeit warten und Anfragen wiederholen, bis sie erfolgreich sind, aber Sie können ein rationaleres Fallback-/Wiederholungssystem implementieren, indem Sie auf warten Benachrichtigungen aus dem Dynamic Ingest-System und verwenden Sie die Informationen, um die laufenden Jobs selbst zu verfolgen.

Eine Möglichkeit, dies zu implementieren, besteht darin, eine Transceiver-App zu erstellen, die sowohl die Aufnahmeanforderungen sendet als auch auf Benachrichtigungen wartet. Das folgende Diagramm zeigt die übergeordnete Logik einer solchen App.

Transceiver-Logik
Transceiver-Logik

Beispiel-App

Sie finden die Quelle für ein Beispiel Knoten-Express App in diesem Github-Repository