Ratenlimits und Quoten

Rate Limits und Quoten sind die grundlegende Mechanik des Nachfragemanagements für gemeinsame Ressourcen: CPU, Netzwerk, DB, Warteschlangen, externe APIs. Das Ziel ist Fairness, Berechenbarkeit von SLO und Schutz vor Ausbrüchen, Missbrauch und „noisy neighbor“.

1) Grundbegriffe

Rate limit - Begrenzung der Intensität von Anfragen/Operationen (req/s, msg/min, byte/sec).
Burst ist ein zulässiger kurzzeitiger Anstieg über die durchschnittliche Rate.
Quota - Volumenlimit pro Zeitfenster (Dokumente/Tag, GB/Monat).
Concurrency cap - Begrenzung der gleichzeitigen Operationen (gleichzeitige Anfragen/Jobs).
Scope - Anwendungsbereich: per-tenant, per-user, per-token, per-endpoint, per-IP, per-region, per-feature.

2) Begrenzungsalgorithmen

2. 1 Token Bucket (Eimer mit Token)

Parameter: 'rate' (tokens/sec), 'burst' (bucket size).
Funktioniert wie ein „Kredit“: Akkumulierte Token ermöglichen kurze Spitzen.
Geeignet für externe APIs und benutzerdefinierte Abfragen.

2. 2 Leaky Bucket (undichter Eimer)

Sanft „entlüftet“ die Strömung mit konstanter Geschwindigkeit.
Gut, um den Verkehr zu den empfindlichen Backend's zu glätten.

2. 3 Fixed/Sliding Window

Fixed window: einfach, aber anfällig für „Fensterwechsel“.
Sliding window: genauer, aber rechnerisch teurer.

2. 4 GCRA (Generic Cell Rate Algorithm)

Das Äquivalent von Token Bucket in Bezug auf die virtuelle Ankunftszeit.
Präzise und stabil für verteilte Limiter (weniger Konfliktzustand).

2. 5 Concurrency Limits

Beschränken Sie gleichzeitig ausgeführte Vorgänge.
Schützt vor Erschöpfung von Threads/Verbindungspools und „Head-of-Line-Blocking“.

3) Wo die Grenzen gelten

An der Grenze (L7/API-Gateway): Hauptbarriere, schneller Ausfall (429/503), billige Kontrollen.
Innerhalb der Dienstleistungen: zusätzliche Caps für schwere Operationen (Exporte, Berichte, Transformationen).
Am Ausgang zu externen Systemen: individuelle Limits für Dritte (Anti-Penalty).
Auf Warteschlangen/Worker: Fairness zu geteilten Pools.

4) Scopes und Prioritäten (Multi-Tenant)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.
Priority-aware: VIPs/Enterprise bekommen mehr „Burst“ und Gewicht, aber brechen nicht die allgemeinen SLOs.
Zusammensetzung der Grenzen: endgültige Toleranz = 'min (global, regional, tenant, custom, endpoint)'.

5) Quoten nach Volumen

Tages-/Monatskontingente: Dokumente/Tag, GB/Monat, Nachrichten/min.
Weiche/harte Schwellen: Warnungen (80/90%) und „harter Stopp“.
Roll-up: Buchhaltung für Objekte (Tabellen, Dateien, Ereignisse) und „Rückzug“ in der Abrechnung.

6) Verteilte Limiter

Anforderungen: geringe Latenz, Konsistenz, Ausfallsicherheit, horizontale Skalierung.

Local + probabilistic sync: lokale Shard-Buckets + periodische Synchronisation.
Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding: Schlüssel der Art 'limit: {scope}: {id}: {window}' mit gleichmäßiger Verteilung.
Clock skew: Speichern Sie die „Wahrheit“ auf dem Limiter-Server, nicht in den Clients.
Idempotenz: Die Schlüssel der „Operationen“ (Idempotency-Key) reduzieren falsche Abschreibungen.

7) Anti-Missbrauch und Schutz

Per-IP + Device Fingerprint für öffentliche Endpunkte.
Proof-of-Work/CAPTCHA bei Anomalien.
Slowdown (Durchdrehen) statt Totalausfall, wenn UX wichtiger ist (Suchhinweise).
Adaptive Limits: dynamisches Absenken der Schwellenwerte bei Störfällen/teuren Degradationen.

8) Kundenverhalten und Protokoll

Codes: „429 Too Many Requests“ (Rate), „403“ (Quote/Plan überschritten), „503“ (Schutzdegradation).

• 'Retry-After: ' - wenn Sie es erneut versuchen.

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff: exponentiell + Jitter (full jitter, equal jitter).
• Idempotenz: Überschrift „Idempotency-Key“ und Wiederholbarkeit sicherer Operationen.
• Timeouts und Stornierungen: Unterbrechen Sie hängende Anfragen korrekt, um Limits nicht zu „erfassen“.

9) Beobachtbarkeit und Prüfung

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).
Metriken: Bandbreite, 429/403/503-Fehlerquote, p95/p99 Limiter-Latenz, Hit Ratio des Schlüsselcaches, Verteilung nach Plänen.
Audit-Protokolle: die Gründe für die Blöcke, die Spitze der „lauten“ Schlüssel.
Tests: Lastprofile „Säge/Burst/Plateau“, Chaos - Redis/Scharda-Ausfall, Uhr nicht synchron.

10) Integration mit Abrechnung

Usage-Zähler werden an der Grenze gesammelt, aggregiert durch Schlachten (alle N min) mit Idempotenz.
Zusammenfassung der Pläne: Überschreitung → Overcharge oder vorübergehende Erhöhung des Plans.
Unstimmigkeiten: usage vs invoice; alert auf Delta.

11) Fairness im Inneren (Warteschlangen, Worker)

Weighted Fair Queuing/DRR: Zuweisung von Slots an Mieter nach Plangewicht.
Per-tenant Arbeiterpools: harte Isolierung von VIP/laut.
Admissionskontrolle: Ablehnung vor der Ausführung, wenn die Kontingente ausgeschöpft sind; Warteschlangen werden nicht aufgeblasen.
Caps auf Betonung: Begrenzen Sie gleichzeitige schwere Jobs.

12) Typische Planprofile (Beispiel)

yaml plans:
starter:
rate: 50  # req/s burst: 100 concurrency: 20 quotas:
daily_requests: 100_000 monthly_gb_egress: 50 business:
rate: 200 burst: 400 concurrency: 100 quotas:
daily_requests: 1_000_000 monthly_gb_egress: 500 enterprise:
rate: 1000 burst: 2000 concurrency: 500 quotas:
daily_requests: 10_000_000 monthly_gb_egress: 5000

13) Architektonischer Maßstab (verbales Schema)

1. Edge/API-Gateway: TLS → den Kontext (tenant/plan) extrahieren → Limits/Kontingente überprüfen → RateLimit- → Log/Trace-Header platzieren.
2. Policy Engine: Prioritätsregeln (VIP), adaptive Schwellenwerte.
3. Limiter Store: Redis/KeyDB (atomic ops, LUA), Schlüsselvernetzung, Replikation.
4. Dienstleistungen: Sekundärlimit und Caps für schwere Operationen; Idempotenz; Warteschlangen mit WFQ/DRR.
5. Verwendung/Billing: Sammlung, Aggregation, Rechnung, Warnungen nach Schwellenwerten.
6. Observability: Metriken/Logs/Traces mit Tags, Dashboards per tenant.

14) Checkliste vor dem Verkauf

• Scopes der Limits (tenant/user/token/endpoint/IP) und deren Hierarchie sind definiert.
• Algorithmus (Token Bucket/GCRA) und 'rate/burst' Parameter ausgewählt.
• Implementierte Concurrency Caps und Admission Control für schwere Operationen.
• Die Überschriften „RateLimit-“ und „Retry-After“ sind enthalten. Kunden unterstützen backoff + jitter.
• Limiter verteilt und störungsresistent (Shards, Replikation, Degradation).
• Die Nutzungsgebühr ist idempotent; Verbindung mit der Abrechnung, Warnungen für Überausgaben.
• Beobachtbarkeit: Metriken/Traces/Logs mit Tags, top „noise“ Keys, alerter 's.
• Tests: Bursts, „Säge“, Stor-Ausfall, Taktskew, Kaltstart.
• Kundendokumentation: Limits für Pläne, Beispiele für 429/Retry-After, Best Practices für Retrays.
• Ausnahmepolitik: Wie und wann die Grenzwerte vorübergehend angehoben werden.

15) Typische Fehler

Globale Grenze ohne per-tenant/per-endpoint - „noisy neighbor“ bricht alle SLOs.
Mangel an 'burst': UX leidet unter kurzen Ausbrüchen.
Die Verwendung nur eines festen Fensters → „Doppelschlag an der Fenstergrenze“.
Keine Idempotenz und Retraits mit Jitter → ein Sturm von Wiederholungen.
Limits nur an der Grenze, keine Caps in den Diensten/Warteschlangen → interne „Staus“.
Die Nichtwiderlegung von Limits in den Antworten (kein 'Retry-After', 'RateLimit-') → Kunden passen sich nicht an.
Die Speicherung des Limiter-Status in der OLTP-Datenbank → eine hohe Latenz und „heiße“ Sperren.

16) Schnelle Strategieauswahl

Öffentliche APIs mit Spitzen: Token Bucket + Big 'Burst', RateLimit - Header, CDN/Edge-Cache.
Interne schwere Jobs: Concurrency Caps + WFQ/DRR, Admission Control.
Integrationen mit Dritten: separate Ausstiegslimits, Pufferung/Retrays.
Multi-Tenant SaaS: Limithierarchie (global→tenant→user→endpoint), VIP-Priorisierung, Kontingente nach Monat.

Schluss

Gute Ratenlimits und Quoten sind ein Systemvertrag zwischen Plattform und Kunde: fairer Anteil an Ressourcen, Widerstandsfähigkeit gegen Spitzen, planbare SLOs und transparente Abrechnung. Kombinieren Sie Algorithmen (Token/GCRA + Concurrency Caps), implementieren Sie eine Copy-Hierarchie, geben Sie klare Überschriften und Metriken und überprüfen Sie regelmäßig Diagramme unter realen Verkehrsprofilen - so bleibt die Plattform auch bei aggressivem Lastwachstum stabil.