Un limiteur de taux en mémoire est souvent suffisant dans un processus unique et de longue durée.
Il cesse d'être fiable une fois que le même point de terminaison est servi par plusieurs instances éphémères.
C'est pourquoi les déploiements sans serveur ont généralement besoin d'une limitation de taux soutenue par un état partagé.
Pourquoi les compteurs locaux échouent
Si chaque instance de fonction conserve son propre compte de requêtes, la limite s'applique par instance, et non par identité client.
Cela signifie qu'un déploiement distribué peut accidentellement multiplier la limite de taux effective simplement en se scalant.
Ce n'est pas un bug dans la bibliothèque. C'est le résultat naturel de l'état local dans un système distribué.
Pourquoi Redis est adapté
Redis est utile ici car il vous offre :
- un état partagé rapide
- des opérations atomiques
- des primitives d'expiration
Cela suffit pour implémenter des approches de fenêtre fixe, de fenêtre glissante ou de jeton seau selon le modèle d'équité et de coût dont vous avez besoin.
Utilisez l'algorithme le plus simple qui correspond aux besoins
Vous n'avez pas toujours besoin d'un journal de fenêtre glissante.
- la fenêtre fixe est simple et souvent suffisante
- la fenêtre glissante est plus équitable mais plus coûteuse
- le seau de jetons est bon lorsqu'une capacité de rafale contrôlée est acceptable
Le choix correct dépend du comportement du produit, et non de l'algorithme qui semble le plus avancé.
Gardez la décision atomique
Si plusieurs commandes Redis sont nécessaires pour évaluer et mettre à jour la limite, gardez-les atomiques avec soit :
- un script Lua
- un modèle de transaction qui correspond vraiment à l'algorithme
Cela est important en cas de concurrence.
La règle pratique
Pour les API distribuées et sans serveur :
- stockez l'état de limitation de taux de manière centrale
- choisissez un algorithme qui correspond à l'expérience utilisateur que vous souhaitez
- gardez le chemin de mise à jour atomique
Cela est plus important que le middleware du framework avec lequel vous avez commencé.
Lectures complémentaires