Rate Limiter-Konnektor

Übersicht

Der Rate Limiter-Konnektor begrenzt die Rate, mit der Payloads durch eine Pipeline fließen, unter Verwendung eines Token-Bucket-Algorithmus. Er unterstützt zwei Strategien: Überschüssige Payloads zu verwerfen oder sie für eine spätere Zustellung in eine Queue zu legen.

Konnektor-Typ: MeddleRateLimiter

Drop-Strategie

Überschüssige Payloads werden sofort verworfen und auf dem Fehlerkanal gemeldet.

{
  "type": "MeddleRateLimiter",
  "config": {
    "maxRate": 10,
    "burstSize": 20,
    "strategy": "drop"
  }
}

Erlaubt bis zu 10 Ereignisse pro Sekunde, mit Bursts von bis zu 20. Wenn der Bucket leer ist, werden eingehende Payloads verworfen.

Queue-Strategie

Überschüssige Payloads werden in einer begrenzten Queue gepuffert und mit der konfigurierten Rate abgearbeitet.

{
  "type": "MeddleRateLimiter",
  "config": {
    "maxRate": 5,
    "burstSize": 5,
    "strategy": "queue",
    "queueSize": 200
  }
}

Wenn die Queue voll ist, werden zusätzliche Payloads auf dem Fehlerkanal als Überlauf gemeldet.

Konfigurationsparameter

maxRate (erforderlich, > 0): Anhaltender Durchsatz in Ereignissen pro Sekunde (Float)
burstSize (erforderlich, > 0): Maximale Burst-Kapazität des Token-Buckets
strategy (erforderlich): drop oder queue
queueSize: Queue-Kapazität für die queue-Strategie (Standard 100)

Token-Bucket-Semantik

Der Bucket hält höchstens burstSize Tokens und füllt sich mit maxRate Tokens pro Sekunde wieder auf
Jede Payload verbraucht ein Token
Bei drop wird eine Payload sofort weitergeleitet, wenn ein Token verfügbar ist; andernfalls wird sie verworfen
Bei queue wird die Payload in die Queue gestellt und dann weitergeleitet, sobald das nächste Token gewährt wird. Überlauf tritt auf, wenn die Queue voll ist.

Anwendungsfälle

Nachgelagerte APIs schützen mit strengen Rate-Limits (z.B. Drittanbieter-SaaS-Endpunkte)
Bursty-Eingaben glätten vor dem Schreiben in eine Datenbank
Benachrichtigungsfrequenz begrenzen, um Alarmstürme zu vermeiden
Ausgehende Webhooks drosseln, um unter Provider-Quoten zu bleiben

Beispiel: Glätten eines bursty MQTT-Streams

{
  "type": "MeddleRateLimiter",
  "config": {
    "maxRate": 50,
    "burstSize": 100,
    "strategy": "queue",
    "queueSize": 1000
  }
}

Hält 50 Ereignisse/Sek mit einer 100-Ereignis-Burst-Reserve. Bis zu 1000 Ereignisse können während Spitzenverkehr in die Queue gestellt werden, bevor ein Überlauf auftritt.

Beispiel: Überschüssige Alarme verwerfen

{
  "type": "MeddleRateLimiter",
  "config": {
    "maxRate": 1,
    "burstSize": 1,
    "strategy": "drop"
  }
}

Höchstens eine Payload pro Sekunde wird weitergeleitet; alles darüber wird still verworfen (mit einem geloggten Fehler).

Best Practices

Passen Sie maxRate an das dokumentierte Limit des langsamsten nachgelagerten Konsumenten an, mit Reserve
Verwenden Sie drop, wenn Aktualität wichtiger ist als Vollständigkeit (z.B. Live-Dashboards)
Verwenden Sie queue, wenn keine Payload verloren gehen darf; bemessen Sie die Queue, um erwartete Burst-Dauern aufzunehmen
Überwachen Sie den Fehlerkanal — verworfene/übergelaufene Payloads werden dort gemeldet
Kombinieren Sie mit On Change, um zuerst Duplikate zu entfernen und dann eindeutige Ereignisse zu drosseln