Ein in-memory Ratenbegrenzer ist oft in einem einzigen langlebigen Prozess ausreichend.
Er wird unzuverlässig, sobald derselbe Endpunkt von vielen ephemeren Instanzen bedient wird.
Deshalb benötigen serverless Bereitstellungen in der Regel eine Ratenbegrenzung, die durch einen gemeinsamen Zustand unterstützt wird.
Warum lokale Zähler scheitern
Wenn jede Funktionsinstanz ihre eigenen Anfragezähler führt, gilt die Begrenzung pro Instanz und nicht pro Client-Identität.
Das bedeutet, dass eine verteilte Bereitstellung versehentlich die effektive Ratenbegrenzung allein durch das Hochskalieren vervielfachen kann.
Das ist kein Fehler in der Bibliothek. Es ist das natürliche Ergebnis eines lokalen Zustands in einem verteilten System.
Warum Redis passt
Redis ist hier nützlich, weil es Ihnen bietet:
- schnellen gemeinsamen Zustand
- atomare Operationen
- Ablauf-Primitiven
Das reicht aus, um fixe Fenster-, gleitende Fenster- oder Token-Bucket-Ansätze zu implementieren, abhängig von dem Fairness- und Kostenmodell, das Sie benötigen.
Verwenden Sie den einfachsten Algorithmus, der dem Bedarf entspricht
Sie benötigen nicht immer ein gleitendes Fensterprotokoll.
- fixed window ist einfach und oft ausreichend
- sliding window ist fairer, aber teurer
- token bucket ist gut, wenn kontrollierte Burst-Kapazität akzeptabel ist
Die richtige Wahl hängt vom Produktverhalten ab, nicht davon, welcher Algorithmus am fortschrittlichsten klingt.
Halten Sie die Entscheidung atomar
Wenn mehrere Redis-Befehle erforderlich sind, um die Begrenzung zu bewerten und zu aktualisieren, halten Sie sie atomar mit einem der folgenden Mittel:
- einem Lua-Skript
- einem Transaktionsmuster, das wirklich zum Algorithmus passt
Das ist wichtig unter Konkurrenzbedingungen.
Die praktische Regel
Für verteilte und serverless APIs:
- speichern Sie den Zustand der Ratenbegrenzung zentral
- wählen Sie einen Algorithmus, der der gewünschten Nutzererfahrung entspricht
- halten Sie den Aktualisierungsweg atomar
Das ist wichtiger, als mit welchem Framework-Middleware Sie begonnen haben.
Weiterführende Literatur