Gewinne:
- Kann Geschwindigkeitsbegrenzungen (RPM/ITPM/OTPM) und 429-Fehler interpretieren
- Implementiert einen exponentiellen Backoff und einen erneuten Versuch mit „retry-after“.
- Klassifiziert und behandelt häufige HTTP-Fehlercodes (400/401/429/500/529) korrekt.
In einer Produktionsumgebung reagiert keine API immer perfekt. Manchmal sendet man Anfragen zu schnell und stößt an die Grenzen; manchmal ist der Server vorübergehend ausgelastet; Manchmal ist Ihre Anfrage von Anfang an falsch. Was eine solide Integration von einem Amateurversuch unterscheidet, ist, dass sie diese Situationen vorausschauend und automatisch bewältigt. In dieser Einheit erfahren Sie mehr über Ratenlimits (RPM/ITPM/OTPM), 429-Fehler, Wiederholungsversuche mit exponentiellem Backoff und die richtige Klassifizierung gängiger HTTP-Fehlercodes. Das Ziel: einen Flow aufzubauen, der so robust ist, dass ein Benutzer ihn nie bemerkt.
Was sind Geschwindigkeitsbegrenzungen?
Der Anbieter begrenzt, wie viel Arbeit ein Switch in einem bestimmten Zeitraum leisten kann. Dieser Schutz; Es schützt sowohl die Infrastruktur als auch Sie vor plötzlichen Kostenexplosionen. Es gibt drei gängige Arten von Grenzwerten:
- RPM (Requests Per Minute): Anzahl der Anfragen pro Minute.
- ITPM (Input Tokens Per Minute): Eingabetoken, die pro Minute verarbeitet werden können.
- OTPM (Output Tokens Per Minute): Ausgabetoken, die pro Minute produziert werden können.
Wenn Sie einen dieser Grenzwerte überschreiten, lehnt der Anbieter die Anfrage ab und gibt den Fehlercode 429 zurück. Die Limits variieren im Allgemeinen je nach Kontoebene (Stufe) und können im Laufe der Zeit erhöht werden.
Tipp: Sie können anhand der Antwortheader beobachten, wann Sie sich dem Limit nähern. Die meisten Anbieter melden Ihr verbleibendes Kontingent mit Headern wie x-ratelimit-remaining-*. Die Überwachung dieser Werte und die Drosselung des vorausgehenden Datenverkehrs ist die ausgereifteste Methode, um das Problem zu verhindern, ohne eine 429 zu erhalten.
429 und exponentielles Retracement
429 (Ratenbegrenzung) ist ein vorübergehender und wiederholbarer Fehler. Die richtige Antwort besteht darin, eine Weile auf die Anfrage zu warten und es dann erneut zu versuchen. Aber ständiges Warten reicht nicht aus; Wenn es alle gleichzeitig noch einmal versuchen, wird das Limit erneut erreicht. Die Lösung ist ein exponentielles Backoff: Die Wartezeit wird mit jedem fehlgeschlagenen Versuch exponentiell verlängert.
# Exponentielle Backoff-Logik Versuch 1 → 429 → 1 Sek. warten Versuch 2 → 429 → 2 Sek. warten Versuch 3 → 429 → 4 Sek. warten Versuch 4 → 429 → 8 Sek. warten (+ kleiner zufälliger „Jitter“) ... aufgeben und nach höchstens N Versuchen Bericht erstatten
Durch Hinzufügen einer kleinen Zufälligkeit (Jitter) wird verhindert, dass Anfragen kollidieren, wenn gleichzeitig versucht wird, es erneut zu versuchen. Darüber hinaus enthält die 429-Antwort häufig den Header „retry-after“: „Versuchen Sie es in diesen vielen Sekunden noch einmal.“ Diesen Titel zu respektieren ist zutreffender als blindes Warten.
Achtung: Wenn Sie eine 429 erhalten, wird die Situation durch „Erzwingen durch das Senden weiterer Anfragen“ verschlimmert; Das Limit ist weiterhin ausgeschöpft und es werden keine Anfragen bearbeitet. Die richtige Reaktion ist Rückzug, nicht Beschleunigung. Gute Nachrichten: Die meisten offiziellen SDKs versuchen 429- und Serverfehler automatisch mit einem Backoff erneut – nutzen Sie dieses Verhalten des SDK, bevor Sie es manuell installieren.
Klassifizierung von HTTP-Fehlercodes
Nicht jeder Fehler ist gleich. Kritischer Unterschied: Kann es erneut versucht werden oder handelt es sich um ein Anfrage-/Identitätsproblem?
Code
Bedeutung
Kann es noch einmal versucht werden?
richtige Antwort
400
Ungültige Anfrage (Format-/Parameterfehler)
Nein
Korrigieren Sie die Anfrage. Schicken Sie das Gleiche nicht noch einmal
401
Authentifizierungsfehler (Schlüssel ungültig/fehlend)
Nein
Schlüssel/Titel korrigieren
403
Keine Autorisierung (kein Zugriff auf Modell/Funktion)
Nein
Überprüfen Sie die Berechtigungen/den Umfang
404
Nicht gefunden (falsche Modell-ID/falscher Endpunkt)
Nein
Richtige Modell-ID/Adresse
429
Geschwindigkeitsbegrenzung überschritten
Ja
Rückzug + erneuter Versuch danach
500
Serverfehler
Ja
Versuchen Sie es erneut mit Rückzug
529
Server überlastet
Ja
Versuchen Sie es erneut mit Rückzug
Goldene Regel: 429, 500 und 529 sind vorübergehend; Es wird erneut mit Rückzug versucht. 400, 401, 403, 404 sind Anfrage-/Identitätsprobleme; Ein erneuter Versuch wird das Problem nicht lösen, und es ist Zeitverschwendung. Ihr Code muss zwischen diesen beiden Gruppen unterscheiden.
Schritt für Schritt: Dauerhafter Anruf
- Senden Sie die Anfrage. Bei Erfolg fahren Sie fort.
- Klassifizieren Sie den Fehlercode. Kann es noch einmal versucht werden?
- Wenn möglich: Befolgen Sie „Retry-After“, wenden Sie exponentiellen Backoff + Jitter an und versuchen Sie es nur mit begrenzter Anzahl (z. B. maximal 5).
- Falls nicht versucht: Korrigieren Sie (Format/Schlüssel) und stoppen Sie; Wiederholen Sie nicht dieselbe fehlerhafte Anfrage in der Schleife.
- Erwägen Sie, aufzugeben. Wenn nach n Versuchen immer noch kein Erfolg besteht, zeigen Sie dem Benutzer eine höfliche Nachricht und protokollieren Sie das Ereignis (Tracking-Einheit 11).
# Robuster Aufruf pseudo-codedene = 0repeat: Response = request_at() if Response.success: Antwort zurückgeben, wenn Response.code in [429, 500, 529] und try < 5: wait = retry_after ?? (2^try sec + Jitter) sleep(wait); versuche es mit += 1; git erneut, wenn Response.code in [400, 401, 403, 404]: save_error(response); Rückgabe „Anfrage muss behoben werden“ Rückgabe „dauerhafter Fehler, versuchen Sie es später“
# Höfliches Feedback an den Benutzer (wenn die Wiederholungsversuche erschöpft sind) „Ich bin gerade beschäftigt, ich konnte Ihre Anfrage nicht bearbeiten. Versuchen Sie es bald noch einmal, oder ich habe Ihre Anfrage gespeichert. Ich melde mich bei Ihnen, wenn sie fertig ist.“
Schwache Eingabeaufforderung / Starke Eingabeaufforderung (hier: Fehlermeldungsdesign)
# SCHWACH (zeigt dem Benutzer den Rohfehler an) „Fehler 429: rate_limit_error“
# STARK (benutzerfreundlich, beruhigend, Handlungsempfehlungen) „Es gab eine vorübergehende Überlastung im System. Wir haben Ihre Anfrage sicher erhalten und es wird automatisch erneut versucht. Sollte innerhalb weniger Sekunden kein Ergebnis angezeigt werden, können Sie die Seite aktualisieren.“
Die Offenlegung des groben technischen Fehlers gegenüber dem Endbenutzer untergräbt das Vertrauen und kann eine Sicherheitslücke darstellen. Kategorisieren Sie Fehler intern und übermitteln Sie dem Benutzer eine ruhige, handlungsorientierte Nachricht; Schreiben Sie einfach die technischen Details fürs Protokoll.
Drei Mini-Hüllen
Fall 1 – Boot stürzte bei Verkehrsexplosion ab. Ein Kundenservice-Bot verzeichnete am Tag der Kampagne einen Traffic-Anstieg von 429; Es gab keinen Wiederholungsversuch im Code, jeder Fehler wurde dem Benutzer direkt als „Fehler“ angezeigt. Sie fügten exponentielles Retracement + Wiederholungsversuch hinzu; Bei gleichem Datenverkehr wurden Anfragen mit einer Verzögerung von mehreren Sekunden weitergeleitet, der Benutzer sah keine Fehler.
Fall 2 – Versuchen Sie 400 in der Schleife. Eine Integration erhielt aufgrund einer ungültigen Modell-ID einen 404-Fehler, behandelte jedoch alle Fehler als „vorübergehend“ und versuchte es erneut in einer Endlosschleife. Der Stamm schwollen an und es entstand eine unnötige Belastung. Sie fügten eine Fehlerklassifizierung hinzu: 404 gilt als dauerhaft, die Schleife wird gestoppt und die Modell-ID wird korrigiert. Lektion: Versuchen Sie nicht jeden Fehler noch einmal.
Fall 3 – Das Limit von vorne verwalten. Ein Datenanreicherungsjob wurde ständig mit der Grenze von 429 ausgeführt. Sie folgten dem x-ratelimit-remaining-Header und drosselten den Datenverkehr entsprechend der Quote. Sie hielten also ein konstantes Tempo knapp unter dem Limit, ohne irgendwelche 429er zu fahren; Die Arbeit wurde vorhersehbarer und schneller erledigt.
Häufige Fehler
- Geschwindigkeitserhöhung bei 429: Verschlimmert die Situation; Wechseln Sie zum Rückzug.
- Jeder Fehler wird erneut versucht: 400/401/404 ist dauerhaft; Ein erneuter Versuch ist eine Verschwendung.
- Festes Warten verwenden: Erzeugt eine Kollision; Verwenden Sie Exponential + Jitter.
- Ignorieren von „retry-after“: Am genauesten ist es, die vom Anbieter vorgegebene Zeit einzuhalten.
- Offenlegung des groben Fehlers für den Benutzer: Erschüttert das Vertrauen, schafft Schwachstellen; Innen klassifizieren.
- Unbegrenzte Wiederholungen: Legen Sie eine Obergrenze fest (z. B. 5 Wiederholungen); dann gib höflich auf.
Tiefer: Warteschlangen, Parallelität und Leistungsschalter
Das Aushalten eines einzelnen Wunsches ist der erste Schritt; Die eigentliche Reife besteht darin, eine große Anzahl von Anfragen zu verwalten, ohne an die Grenzen zu stoßen. Hier kommen drei Konzepte ins Spiel.
Warteschlange: Sie stellen Anfragen in eine Warteschlange, um sie nicht sofort, sondern in einem kontrollierten Tempo zu senden. Durch die Warteschlange werden plötzliche Datenverkehrsspitzen ausgeglichen: Selbst wenn 1.000 Anfragen gleichzeitig eingehen, werden sie von der Warteschlange mit einer Geschwindigkeit freigegeben, die unter dem Grenzwert liegt. Auf diese Weise verhindern Sie 429 und müssen sich nicht um die Behebung kümmern.
Parallelitätslimit: Sie begrenzen, wie viele Anfragen gleichzeitig „in der Luft“ sind. Unbegrenzte parallele Anfragen erfüllen schnell die RPM- und TPM-Grenzen. Eine angemessene Obergrenze für die Parallelität (z. B. nicht mehr als 10 gleichzeitige Anfragen) hält einerseits die Grenzen aufrecht und macht das System vorhersehbar.
Leistungsschalter: Wenn der Anbieter weiterhin 500/529 zurückgibt, unterbrechen Sie, anstatt beharrlich jede Anfrage zu versuchen, den Stromkreis für eine Weile und scheitern schnell an der Anfrage, ohne sie jemals zu senden. Nach einer Weile schalten Sie den Stromkreis wieder ein und versuchen es. Dieses Muster verhindert, dass Ihr System im Falle eines vorübergehenden Providerausfalls abstürzt.
Zusammen sorgen diese drei für eine Ausfallsicherheit auf Systemebene, die über die Wiederholungslogik eines einzelnen Aufrufs hinausgeht. Im kleinen Maßstab reicht der automatische Wiederholungsversuch des SDK aus; Mit zunehmender Größe werden Warteschlangen, Parallelität und Schutzschalter unverzichtbar. Sie alle haben das gleiche gemeinsame Ziel: Dem Benutzer ein vorübergehendes Problem nicht als Absturz, sondern als unsichtbare Verzögerung von einigen Sekunden darzustellen.
Zusammenfassend
429 kehrt zurück, wenn Geschwindigkeitsbegrenzungen (RPM/ITPM/OTPM) überschritten werden; Dies ist ein vorübergehender Fehler und wird mit „Retry After“ und exponentiellem Backoff + Jitter erneut versucht. 500 und 529 sind ebenfalls vorläufig; 400/401/403/404 ist ein Anfrage-/Identitätsproblem und kann nicht durch einen erneuten Versuch gelöst werden. Ein robuster Ablauf unterteilt Fehler in diese beiden Gruppen, versucht es mit einer begrenzten Anzahl von Malen, überwacht das Limit von vorne und zeigt dem Benutzer beruhigende Meldungen an.
Anwendungsaufgabe
Denken Sie über Ihre Integration nach. (1) Listen Sie die Fehlercodes auf, auf die Sie möglicherweise stoßen, und unterteilen Sie sie in „wiederholbar/permanent“. (2) Notieren Sie Ihren exponentiellen Pullback-Plan (anfängliches Halten, Koeffizient, Obergrenze, Jitter). (3) Geben Sie an, wie der Retry-After-Header verwendet werden soll. (4) Schreiben Sie die Höflichkeitsnachricht, die dem Benutzer angezeigt werden soll, wenn die Wiederholungsversuche erschöpft sind.
Checkliste
- [ ] Ich kann RPM/ITPM/OTPM-Grenzwerte und 429 erklären.
- [ ] Ich kann die Logik von exponentiellem Rückzug + Jitter + Wiederholungsversuch anwenden.
- [ ] Ich kann Fehlercodes als wiederholbar/permanent klassifizieren.
- [ ] Ich weiß, dass wir nicht jeden Fehler ausprobieren sollten.
- [ ] Anstelle eines groben Fehlers kann ich dem Benutzer eine ruhige, handlungsorientierte Nachricht anzeigen.