Hallo zusammen,
ich baue n8n-Workflows, die stark von externen APIs abhängen, und ich versuche, eine zuverlässige Möglichkeit zu finden, um Rate Limits zu handhaben, ohne den gesamten Workflow zu verlangsamen.
Zum Beispiel kann eine API folgendes zurückgeben: {
“status”: 429,
“message”: “Too Many Requests”,
“retry_after”: 30
}
Meine Hauptbedenken sind: Vermeidung unnötiger Wiederholungen
Einhaltung von API-Rate-Limits
Verhinderndes, dass eine langsame API andere Workflows blockiert
Behandlung vorübergehender Fehler ohne Datenverlust
Ich erwäge exponentielles Backoff, Request-Queues und Begrenzung der Parallelität.
Für diejenigen, die n8n in der Produktion ausführen:
Wie handhaben Sie normalerweise 429-Antworten?
Verwenden Sie eine Queue oder führen Sie einfach Wiederholungen mit Verzögerungen durch?
Wie entscheiden Sie über die maximale Anzahl von Wiederholungen?
Haben Sie eine gute Möglichkeit gefunden, um zu verhindern, dass eine API zu einem Engpass für die gesamte n8n-Instanz wird?
Beschreiben Sie das Problem/den Fehler/die Frage
Welche Fehlermeldung wird angezeigt (falls vorhanden)?
Bitte teilen Sie Ihren Workflow mit
(Wählen Sie die Knoten auf Ihrer Canvas aus und verwenden Sie die Tastaturkürzel CMD+C/STRG+C und CMD+V/STRG+V zum Kopieren und Einfügen des Workflows.)
Geben Sie die Ausgabe an, die vom letzten Knoten zurückgegeben wird
Hallo @Greg_John Ein guter Produktionsansatz besteht darin, Rate Limits als erwartetes Verhalten zu behandeln, anstatt einfach alles sofort erneut zu versuchen.
API-Anfrage
↓
429 / Temporärer Fehler?
↓ Ja
Warten + Exponentielles Backoff
↓
Erneut versuchen
↓
Maximale Versuche erreicht?
↓ Ja
Dead-Letter / Error-Workflow
Empfohlener Ansatz
Respektiere den Retry-After-Wert der API, wenn angegeben
Verwende exponentielles Backoff bei temporären Fehlern
Lege eine maximale Wiederholungsanzahl fest
Begrenzen Sie die gleichzeitigen Anfragen an die API
Sende permanent fehlgeschlagene Jobs an einen Error-/Recovery-Workflow
Zum Beispiel: Wiederholung 1 → 2 Sekunden
Wiederholung 2 → 4 Sekunden
Wiederholung 3 → 8 Sekunden
Wiederholung 4 → 16 Sekunden
Die genauen Verzögerungen sollten von den Limits der API abhängen.
Der Schlüssel ist es, Retry-Stürme zu vermeiden. Wenn Hunderte von Ausführungen gleichzeitig einen 429-Fehler erhalten und alle sofort erneut versuchen, können Sie das Problem noch verschlimmern.
Bei Hochlast-Systemen bietet eine Kombination aus Concurrency-Limits + exponentiellem Backoff + einem Recovery-Pfad normalerweise ein viel zuverlässigeres Setup.
@Greg_John HTTPS-Anfragen haben Wiederholungszeiten mit einer Wartezeit, die dir helfen könnten, aber du kannst die Ratenlimits nicht wirklich schneller machen, es sei denn, du hast einen höheren Plan. Du kannst es so einrichten, dass sie in Batches arbeiten und bei Fehler erneut versuchen, + Wartknoten helfen dir!
Das Einrichten von Fehler-Workflows kann auch bei der Überwachung helfen!
Gute Antworten oben. Ein paar Dinge, die speziell deine Sorge angehen, dass eine langsame API andere Workflows blockiert:
**Isoliere API-Ausführungen mit Sub-Workflows**
Der Kerngedanke: Behandle Rate Limits nicht in deinem Haupt-Workflow. Verschiebe jeden externen API-Aufruf in seinen eigenen Sub-Workflow (Execute Workflow-Knoten). Dein Haupt-Flow bleibt schnell; der Sub-Workflow verwaltet seine eigene Wiederholungslogik und kann unabhängig ausgeführt werden, ohne andere parallele Ausführungen zu blockieren.
**Verfolge den Kontingent-Status über Ausführungen hinweg**
Die integrierte HTTP-Wiederholung handhabt nur vorübergehende Fehler. Für echtes Rate-Limit-Management über gleichzeitige Ausführungen hinweg benötigst du einen Status, der zwischen Durchläufen persistent ist:
1. Vor dem API-Aufruf verbleibendes Kontingent aus einem Key-Value-Store auslesen (Airtable-Zeile, Redis über HTTP oder ein Google Sheet)
2. Falls das Kontingent fast leer ist, schreibe einen „Cooldown bis
Gute Antworten oben zu Backoff und Sub-Workflow-Isolation. Drei Dinge, die
in der Produktion Probleme verursachen und bisher nicht erwähnt wurden.
Wiederhole nicht jeden Fehler. Nur 429 und 5xx sind einen Wiederholungsversuch wert. Ein 400, 401
oder 403 schlägt bei jedem Versuch identisch fehl, daher verschwendet ein Wiederholungsversuch nur dein
Wiederholungsbudget und lässt einen schlechten Credential wie ein Rate-Limit-Problem aussehen. Verzweige
basierend auf dem Statuscode vor der Wiederholungslogik, nicht danach. Dies ist die häufigste Ursache für
„meine Wiederholungsversuche helfen nicht".
Füge Jitter zum Backoff hinzu. Einfaches exponentielles Backoff bedeutet, dass jedes parallele
Element, das zur gleichen Zeit gedrosselt wurde, zur gleichen Zeit wiederholt wird, und du
löst das Limit im Gleichschritt erneut aus. Randomisiere jede Verzögerung um etwa plus oder
minus 30 Prozent. Bei zehn gleichzeitigen Elementen ist dies der Unterschied zwischen
wieder funktionieren beim zweiten Versuch und eine Minute lang Thrashing.
Mache wiederholte Schreibvorgänge idempotent. Dies ist derjenige, der tatsächlich Geld kostet.
Wenn ein POST eine Zeitüberschreitung aufweist oder 502 zurückgibt, weißt du oft nicht, ob der Server
ihn verarbeitet hat. Ein Wiederholungsversuch kann den Datensatz zweimal erstellen. Wenn die API einen
Idempotency-Key unterstützt, sende einen und verwende ihn über mehrere Wiederholungsversuche derselben logischen
Operation hinweg erneut. Wenn nicht, prüfe auf den Datensatz vor dem Schreiben bei jedem Versuch
nach dem ersten. Ein Wiederholungsversuch bei einem Lesezugriff ist kostenlos; ein Wiederholungsversuch bei einem Schreibzugriff nicht.
Noch eine Sache zu deinem retry_after: 30 Beispiel: Respektiere diesen Wert anstelle deiner eigenen Backoff-Kurve,
wenn die API ihn sendet. Es ist auch wertvoll zu wissen, dass es zwei verschiedene Situationen hinter einem 429 gibt,
und sie erfordern unterschiedliche Reaktionen. Ein
per-Endpoint-Fenster-Limit bedeutet, dass das Kontingent bis zu einer festen Reset-Zeit erschöpft ist,
also ist die einzige Lösung das Warten und das Drosseln deiner Request-Rate. Allgemeine Service-
Drosselung bedeutet, dass du einfach zu schnell sendest, daher wird Backoff plus
reduzierte Parallelität es beheben. Wenn die Antwort einen Reset-Zeitstempel enthält, befindest du dich
im ersten Fall; wenn sie nur Retry-After enthält, befindest du dich normalerweise im
zweiten.
