Ein ausgelasteter Sender kann sein Anfragebudget aufbrauchen, bevor alle Nachrichten in die Warteschlange gestellt sind. Das Lesen des verbleibenden Kontingents ermöglicht es, rechtzeitig zu drosseln, bevor weitere Aufrufe abgelehnt werden.
Wie bestimmt Bird mein Limit?
Bird wendet eine Basisrate, eine etwaige Planerhöhung und dann einen etwaigen Override für die betreffende Gruppe an. Ein Override ersetzt die anderen Werte.
Verwandte Endpunkte teilen sich eine Gruppe. Das Erschöpfen einer Sendegruppe erschöpft nicht automatisch die separaten Gruppen für Statusabfragen oder Webhook-Verwaltung.
Der Geltungsbereich jedes Budgets hängt von der Operation ab:
| Gruppe | Wer teilt sich das Budget? |
|---|---|
| Produktversand | Alle Zugangsdaten in der Organisation für dieses Produkt. |
| Verwaltung: Lesen, Auflisten, Schreiben | Anfragen derselben handelnden Zugangsdaten innerhalb der Organisation. |
| Nicht authentifizierte Anmeldung oder Passwortzurücksetzung | Anfragen von derselben Client-IP. |
Nicht authentifizierte Limits verwenden feste Schwellenwerte. Im Rate-Limits-Leitfaden finden Sie die den einzelnen Endpunkten zugewiesenen Gruppen.
Sendelimits zählen Anfragen, nicht Empfänger. Eine Batch-Anfrage kann mehrere Nachrichten in die Warteschlange stellen. Ihre Gruppe kann ein anderes Kontingent haben.
Vergleichen Sie die aktuellen Kontingente und die Anzahl der Empfänger, die Sie bündeln können, bevor Sie den Endpunkt wechseln. Ein Batch mit nur einem Empfänger bringt möglicherweise keinen Durchsatzgewinn.
Wie lese ich die Antwort-Header?
Lesen Sie RateLimit-Policy für Kontingent und Zeitfenster, dann RateLimit für die verbleibenden Anfragen und die Zeit bis zum Zurücksetzen.
Beispiel:
RateLimit-Policy: "email_send";q=1000;w=60
RateLimit: "email_send";r=842;t=35Dieses Beispiel erlaubt 1.000 Anfragen pro 60-Sekunden-Fenster. Es sind noch 842 Anfragen übrig, mit 35 Sekunden bis zum Zurücksetzen.
Die Zahlen veranschaulichen die Header. Sie sind kein garantiertes Kontingent. Lesen Sie die Werte, die an Ihren Client zurückgegeben werden.
| Feld | Bedeutung |
|---|---|
| Quoted name | Die Gruppe, für die die Richtlinie gilt. |
q | Erlaubte Anfragen pro Fenster. |
w | Fensterlänge in Sekunden. |
r | Verbleibende Anfragen. |
t | Sekunden bis zum Zurücksetzen, kein Zeitstempel. |
Eine Antwort kann mehr als eine Richtlinie enthalten. Berücksichtigen Sie jede geltende Richtlinie beim Planen der nächsten Anfrage.
Was gibt ein Rate-Limit-Fehler zurück?
Ein erschöpftes API-Limit gibt 429 Too Many Requests mit Retry-After in Sekunden zurück. Die Rate-Limit-Header identifizieren die erschöpfte Gruppe. Das verbleibende Kontingent ist r=0.
Die Fehlerantwort enthält diese Felder:
{
"error": {
"type": "rate_limit_error",
"code": "E01003",
"name": "RateLimited"
}
}Prüfen Sie in Ihrem Handler den Typ oder Code. Die menschenlesbare Nachricht kann sich ändern, ohne dass sich die Wiederherstellungsaktion ändert.
Wie sollte mein Client einen 429 behandeln?
Warten Sie auf Retry-After, und versuchen Sie es dann mit einer begrenzten Backoff-Strategie erneut. Verwenden Sie denselben Idempotenzschlüssel, wenn Sie denselben Schreibvorgang wiederholen.
Koordinieren Sie Worker, die dasselbe Gruppenbudget nutzen. Die letzte Antwort eines Workers kann Anfragen, die andere Worker seitdem abgesetzt haben, nicht berücksichtigen.
Drosseln Sie, wenn das verbleibende Kontingent sinkt. Behalten Sie den Retry-Pfad für parallelen Datenverkehr bei. Taktung reduziert Fehler, kann aber nicht garantieren, dass kein Aufruf einen 429 erhält.
Bird SDKs behandeln 429-Wiederholungen und Retry-After. Sie koordinieren keine gemeinsame Warteschlange über all Ihre Prozesse hinweg.
Wenn das Kontingent für die Arbeitslast zu niedrig bleibt, kontaktieren Sie Bird wegen eines Overrides. Das Erstellen weiterer Schlüssel erhöht kein organisationsweites Sendelimit.
Hat eine ratenbegrenzte Anfrage Arbeit verrichtet?
Bird lehnt eine ratenbegrenzte Anfrage ab, bevor die angeforderte Arbeit ausgeführt wird. Diese Ablehnung verbraucht den Idempotenzschlüssel nicht. Versuchen Sie die Anfrage nach dem Warten mit demselben Schlüssel erneut.
Der Limiter lässt Anfragen durch, wenn er das Limit nicht auswerten kann. Ein Problem bei der Auswertung von Kontingenten erzeugt daher nicht selbst einen 429.
Behalten Sie die Idempotenz-Behandlung auch für andere Fehler bei. Ein Serverfehler oder eine verlorene Antwort kann auftreten, nachdem ein Schreibvorgang begonnen hat.
Kurz gesagt
Lesen Sie das Kontingent aus den Antworten.
Das geltende Limit hängt von der Gruppe, dem Plan und einem eventuellen Override ab. Eine fest codierte Zahl kann falsch werden.
Koordinieren Sie Sender, die sich ein Kontingent teilen.
Sendelimits gelten organisationsweit, sodass separate Schlüssel keine separaten Sendebudgets erzeugen.
Warten Sie, bevor Sie einen 429 erneut versuchen.
Retry-Afterliefert die Wartezeit in Sekunden. Begrenzen Sie Ihre Wiederholungsversuche. Verwenden Sie denselben Idempotenzschlüssel für denselben Schreibvorgang.Behandeln Sie Header als gemeinsamen Zustand.
Verbleibende Anfragen können von anderen Workern verbraucht werden. Taktung reduziert Rate-Limit-Fehler, eliminiert sie aber nicht.