API-Ratenbegrenzung: 4 Algorithmen, die jeder Entwickler kennen sollte

Ihr Batch-Job löst 200 Anfragen in 3 Sekunden aus und jede Antwort kommt zurück 429 Too Many Requests. Ihr Webhook-Prozessor attackiert eine Drittanbieter-API und wird für 15 Minuten blockiert. Die Integration eines Kunden verstummt, da die Wiederholungsschleife in der ersten Stunde das Tageskontingent durchbrennt. Diese Fehler teilen sich Eine Hauptursache: Der Code respektiert die Ratenbeschränkungen nicht.

Dieser Leitfaden behandelt die vier Kernalgorithmen zur Ratenbegrenzung und zeigt Ihnen, wie man sie liest X-RateLimit Header von jeder API und ermöglicht Ihnen das Kopieren und Einfügen von Node.js-Code für Wiederholungslogik mit exponentiellem Backoff.

Die vier ratenbegrenzenden Algorithmen

Jeder Ratenbegrenzer beantwortet die gleiche Frage: „Soll dieser Antrag durchgehen oder soll ich ihn ablehnen?“ Die vier Algorithmen unterscheiden sich darin, wie sie die Zeit verfolgen und Bursts verarbeiten.

1. Festes Fenster

Der einfachste Ansatz. Teilen Sie die Zeit in feste Intervalle ein (z. B. 1 Minute). Zählen Sie Anfragen pro Intervall. Wenn die Zählung das Limit erreicht, lehnen Sie alles ab, bis das nächste Intervall beginnt.

Das feste Fenster ist einfach zu erstellen: ein Zähler und ein Zeitstempel pro Client. Der Nachteil ist der Grenzproblem. Ein Client kann das vollständige Limit am Ende eines Fensters und das gesamte Limit senden zu Beginn des nächsten, wobei in einem kurzen Stoß das Zweifache der beabsichtigten Rate erreicht wird. GitHubs ältere API Geschwindigkeitsbegrenzer verwendet feste Fenster; Seitdem sind sie zu ausgefeilteren Ansätzen übergegangen.

2. Schiebefenster

Anstatt an festen Grenzen zurückzusetzen, verschiebt sich das Fenster bei jeder Anfrage. Zu jedem Zeitpunkt, Der Begrenzer blickt auf die letzten N Sekunden zurück und zählt die Anfragen in diesem Zeitraum.

Das Schiebefenster eliminiert das Grenzburst-Problem. Die Kosten sind höher, Speicher: Sie speichern einen Zeitstempel Für jede Anfrage kein einziger Schalter. Redis ZRANGEBYSCORE macht dies im großen Maßstab praktisch. Cloudflare und viele API-Gateways verwenden Schiebefenster für Ratenbegrenzungen pro Benutzer.

3. Token-Bucket

Stellen Sie sich einen Eimer vor, der Token enthält. Jede Anfrage kostet einen Token. Tokens werden zu einem festen Preis wiederaufgefüllt. Wenn der Bucket leer ist, wird die Anfrage abgelehnt. Wenn der Bucket voll ist, sammeln sich keine überschüssigen Token an.

Der Token-Bucket ist der beliebteste Algorithmus in der Produktion. Stripe, AWS API Gateway und die meisten Clouds Anbieter nutzen Varianten davon. Die Eimerkapazität steuert die Burstgröße und die Nachfüllrate anhaltender Durchsatz. Zwei Parameter ermöglichen Ihnen eine detaillierte Kontrolle über die Verkehrsform.

4. Undichte Schaufel

Das Gegenteil von Token-Bucket. Anfragen füllen einen Eimer. Der Eimer entleert sich mit konstanter Geschwindigkeit. Wenn die Der Bucket läuft über, überschüssige Anfragen werden abgelehnt. Die Ausgaberate bleibt unabhängig von der Eingabe konstant platzt.

Leaky Bucket eignet sich gut für die Verkehrsgestaltung, bei der eine konstante Ausgaberate erforderlich ist: Warteschlangenarbeiter, Webhook-Bereitstellung und Videokodierungspipelines. Der Nachteil besteht darin, dass Bursts eher in die Warteschlange gestellt werden als serviert; Die Latenz erhöht sich unter Last.

Vergleich der vier Algorithmen

Algorithmus	Burst erlaubt?	Erinnerung	Häufiger Anwendungsfall
Festes Fenster	Randausbrüche (2x an der Grenze)	Niedrig (1 Zähler)	Einfache Zähler, Analysen
Schiebefenster	Glatt, keine Randspitzen	Mittel (Zeitstempel pro Anfrage)	API-Grenzwerte pro Benutzer
Token-Eimer	Kontrollierte Bursts bis zur Kapazität	Niedrig (2 Werte)	Die meisten Produktions-APIs (Stripe, AWS)
Undichter Eimer	In der Warteschlange, konstante Ausgaberate	Mittel (Warteschlange)	Traffic Shaping, Warteschlangenarbeiter

Lesen von X-RateLimit-Headern

Die meisten APIs enthalten Informationen zur Ratenbegrenzung in Antwortheadern. Drei Überschriften sagen Ihnen alles Sie müssen unter dem Grenzwert bleiben:

• X-RateLimit-Limit: Maximal zulässige Anfragen pro Fenster
• X-RateLimit-Remaining: Anfragen, die Sie im aktuellen Fenster hinterlassen haben
• X-RateLimit-Reset: Unix-Zeitstempel (Sekunden), wenn das Fenster zurückgesetzt wird

Wenn Sie den Grenzwert überschreiten, lautet der Antwortstatus 429 Too Many Requests und die Retry-After In der Kopfzeile erfahren Sie, wie viele Sekunden Sie warten müssen.

Versuchen Sie es mit Botois API. Dieser Curl-Befehl hasht eine Zeichenfolge und gibt die Ratenbegrenzungsheader aus:

Antwortheader:

Dies sagt Ihnen, dass das Limit bei 5 Anfragen pro Fenster liegt, nach dieser Anfrage noch 4 übrig sind und die Das Fenster wird zum angegebenen Unix-Zeitstempel zurückgesetzt. Verfolgen Sie diese Werte in Ihrem HTTP-Client, um Treffer zu vermeiden 429er in erster Linie.

Wiederholungslogik mit exponentiellem Backoff in Node.js

Wenn ein 429-Fehler auftritt, versuchen Sie es nicht sofort erneut. Eine enge Wiederholungsschleife verschlimmert das Problem: Sie bleiben Die Rate ist länger begrenzt und der Server markiert Sie als beleidigend. Verwenden Sie stattdessen einen exponentiellen Backoff mit Jitter.

Verwenden Sie es mit jedem Endpunkt:

Die Funktion prüft auf a Retry-After Kopfzeile zuerst. Wenn der Server Ihnen sagt, wie lange warten, respektiere es. Wenn kein Header vorhanden ist, wird auf den exponentiellen Backoff zurückgegriffen: 1 Sekunde, 2 Sekunden, 4 Sekunden, 8 Sekunden. Zufälliger Jitter (0-500 ms) verhindert das Problem der donnernden Herde, bei der Hunderte von Clients versuchen es genau im selben Moment erneut.

Proaktive Drosselung: Vermeiden Sie 429-Fehler, bevor sie auftreten

Reaktive Wiederholungen behandeln Fehler, nachdem sie aufgetreten sind. Proaktive Drosselung verhindert sie. Wenn Sie es wissen Bestimmen Sie das Ratenlimit (von Dokumenten oder Headern) und beschleunigen Sie Ihre Anfragen auf der Clientseite.

Dieser clientseitige Ratenbegrenzer verfolgt Zeitstempel von Anfragen in einem Schiebefenster. Vor jeder Anfrage Es prüft, ob das Fenster voll ist und wartet bei Bedarf. Sie senden Anfragen mit maximaler Sicherheit Rate ohne einen einzigen 429.

Botois Ratenbegrenzungsmodell

Botoi verwendet ein zweistufiges Tarifbegrenzungssystem:

Planen	Burst (pro Minute)	Quote	Auth
Kostenlos (0 $)	5 Anforderungen/Min	100/Tag	Keine (IP-basiert)
Starter ($9/mo)	30 Anforderungen/Min	300.000/Monat	API-Schlüssel
Pro ($49/mo)	300 Anforderungen/Min	3.000.000/Monat	API-Schlüssel
Geschäftlich (199 $/Monat)	1.000 Anforderungen/Min	30.000.000/Monat	API-Schlüssel

Der anonyme Zugriff verfolgt Anfragen anhand der IP-Adresse. Die tägliche Zählung wird um Mitternacht UTC über a zurückgesetzt Cloudflare KV-Zähler. Authentifizierte Anfragen nutzen den API-Schlüssel zur Identifizierung und Begrenzung werden durchgesetzt Unkeys Token-Bucket-Ratenbegrenzer am Rand.

Jede Antwort von api.botoi.com umfasst die drei X-RateLimit Kopfzeilen wie oben beschrieben, sodass Ihre Wiederholungslogik unabhängig vom Plan auf die gleiche Weise funktioniert.

Bewährte Ansätze für API-Konsumenten

• Lesen Sie die Überschriften jeder Antwort. Kodieren Sie Ratengrenzen nicht fest aus der Dokumentation. APIs ändern die Grenzwerte ohne Vorankündigung. Die Überschriften sind die Quelle der Wahrheit.
• Verwenden Sie einen exponentiellen Backoff mit Jitter. Feste Wiederholungsintervalle führen zu einer Synchronisierung Wiederholungsversuche über mehrere Clients hinweg. Jitter verteilt die Last.
• Batch, bei dem die API dies unterstützt. Eine Anfrage mit 10 Artikeln kostet 1 Ratenlimit Token. Zehn Einzelanfragen kosten 10.
• Cache-Antworten. Wenn sich die Daten zwischen den Anfragen nicht ändern, speichern Sie das Ergebnis und überspringen Sie den API-Aufruf. DNS-Einträge, SSL-Zertifikate und WHOIS-Daten ändern sich selten innerhalb von Minuten.
• Verwenden Sie eine Warteschlange für Hintergrundarbeiten. Lösen Sie keine API-Aufrufe aus einer Hot-Loop aus. Drücken Arbeiten Sie an einer Warteschlange (BullMQ, SQS, Cloudflare Queues) und verarbeiten Sie Elemente mit einer kontrollierten Geschwindigkeit.
• Überwachen Sie Ihr verbleibendes Kontingent. Protokoll X-RateLimit-Remaining zu deinem Metrik-Dashboard. Legen Sie eine Warnung fest, wenn der Wert unter 20 % des Grenzwerts fällt.

Wichtige Punkte

• Es dominieren vier Algorithmen. Ein festes Fenster ist am einfachsten. Am beliebtesten ist der Token-Bucket. Das Schiebefenster verhindert Grenzüberschreitungen. Undichte Schaufel sorgt für gleichmäßigere Ausgabe.
• X-RateLimit-Header sind Ihre API. Lesen Limit, Remaining, Und Reset auf jede Antwort, um unter der Obergrenze zu bleiben.
• Exponentieller Backoff mit Jitter bewältigt 429 Sekunden. Kopieren Sie die fetchWithRetry Fügen Sie die obige Funktion in Ihre Codebasis ein und schließen Sie jeden externen API-Aufruf ein.
• Proaktive Drosselung verhindert 429-Fehler. Bestimmen Sie das Tempo Ihrer Anfragen auf der Clientseite anstatt darauf zu warten, dass der Server zurückschickt.
• Zum Testen ist kein Konto erforderlich. Treffen Sie einen beliebigen Botoi-Endpunkt api.botoi.com mit 5 kostenlosen Anfragen pro Minute, um Ratenlimit-Header in Aktion zu sehen.