La limitation de débit (restreindre le nombre de requêtes/actions autorisées dans une fenêtre de temps) est un cas d'usage courant de Redis — les compteurs atomiques rapides de Redis et les TTL le rendent idéal. Plusieurs algorithmes existent (fenêtre fixe, fenêtre glissante, token bucket), chacun avec des compromis.
() {
key = ;
count = redis.(key);
(count === ) redis.(key, windowSec);
count <= limit;
}
L'approche fenêtre fixe : un compteur atomique par (utilisateur, fenêtre de temps) avec un TTL — incrémenter à chaque requête, rejeter quand la limite est dépassée. Simple et efficace, en exploitant l'atomicité de INCR et l'expiration automatique.
✗ Limitation: bursts at window boundaries (2x limit possible across two adjacent windows)
SLIDING WINDOW → tracks requests over a rolling time period (no boundary bursts)
→ often uses a SORTED SET: add each request with a timestamp score,
remove old entries (ZREMRANGEBYSCORE), count remaining (ZCARD)
✓ More accurate/smooth ✗ More memory and complexity
TOKEN BUCKET → tokens refill at a steady rate; each request consumes a token
→ allows bursts (up to the bucket size) while limiting the average rate
→ often implemented with a Lua SCRIPT for atomic check-and-consume
✓ ATOMIC counters (INCR) → correct under concurrency, no race conditions
✓ Fast (in-memory) → minimal latency added to each request
✓ TTL → automatic window cleanup (no manual expiry management)
✓ SHARED across servers → distributed rate limiting (all app servers use one Redis)
→ Redis is the standard tool for distributed rate limiting.
Implémenter la limitation de débit avec Redis est un cas d'usage courant et pratique, donc la comprendre est une connaissance précieuse — la limitation de débit (protéger les API et services contre les abus, assurer une utilisation équitable, prévenir les surcharges) est un besoin quasi universel, et Redis est l'outil standard pour cela.
Comprendre pourquoi Redis est idéal est essentiel : ses compteurs atomiques (INCR) rendent le comptage de débit correct en concurrence (pas de conditions de course/pertes de comptage), sa rapidité (en mémoire) ajoute une latence minimale à chaque requête, les TTL gèrent automatiquement le nettoyage des fenêtres, et de manière cruciale il est partagé entre les serveurs — permettant une limitation de débit distribuée où tous les serveurs d'application appliquent une limite cohérente unique (essentiel dans les déploiements multi-serveurs, où les limites en mémoire par serveur ne fonctionneraient pas).
Comprendre les algorithmes et leurs compromis vous permet de choisir correctement : fenêtre fixe (la plus simple — un compteur atomique par fenêtre de temps avec un TTL, mais permettant des pics aux limites), fenêtre glissante (plus lisse et plus précise en utilisant un ensemble trié de requêtes horodatées, à un coût mémoire plus élevé), et token bucket (permettant des pics contrôlés tout en limitant le débit moyen, souvent via un script Lua pour l'atomicité).
Savoir comment implémenter ceux-ci (particulièrement le motif simple et courant de fenêtre fixe avec INCR + EXPIRE) est une compétence pratique et applicable.
Puisque la limitation de débit est une exigence courante pour protéger les services, et puisque Redis (avec ses compteurs atomiques, sa rapidité, ses TTL et son partage entre serveurs) est l'outil standard et idéal pour la limitation de débit distribuée, comprendre comment l'implémenter avec Redis — les algorithmes, leurs compromis, et pourquoi Redis est si bien adapté — est une connaissance précieuse et fréquemment applicable pour construire des services robustes et protégés, l'une des applications Redis pratiques les plus courantes au-delà de la mise en cache.