Il rate limiting (limitare quanti richieste/azioni sono consentite in una finestra di tempo) è un caso d'uso comune di Redis — i contatori atomici veloci di Redis e i TTL lo rendono ideale. Esistono diversi algoritmi (finestra fissa, finestra scorrevole, token bucket), ciascuno con compromessi.
() {
key = ;
count = redis.(key);
(count === ) redis.(key, windowSec);
count <= limit;
}
L'approccio finestra fissa: un contatore atomico per (utente, finestra-temporale) con un TTL — incrementa per ogni richiesta, rifiuta quando oltre il limite. Semplice ed efficiente, sfruttando INCR atomico e auto-scadenza.
✗ 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.
Implementare il rate limiting con Redis è un caso d'uso comune e pratico, quindi comprenderlo è una conoscenza preziosa — il rate limiting (proteggere API e servizi da abusi, garantire un uso equo, prevenire sovraccarichi) è un'esigenza quasi universale, e Redis è lo strumento standard per questo.
Comprendere perché Redis è ideale è fondamentale: i suoi contatori atomici (INCR) rendono il conteggio del rate corretto sotto concorrenza (nessuna race condition/conteggi persi), la sua velocità (in-memory) aggiunge latenza minima a ogni richiesta, i TTL gestiscono automaticamente la pulizia della finestra, e crucialmente è condiviso tra server — abilitando il rate limiting distribuito dove tutti i server applicativi applicano un limite consistente e unico (essenziale in distribuzioni multi-server, dove i limiti in-memory per-server non funzionerebbero).
Comprendere gli algoritmi e i loro compromessi consente di scegliere appropriatamente: finestra fissa (più semplice — un contatore atomico per finestra temporale con un TTL, ma consentendo burst ai confini), finestra scorrevole (più uniforme e accurata usando un sorted set di richieste con timestamp, a costo di memoria superiore), e token bucket (consentendo burst controllati limitando il tasso medio, spesso tramite uno script Lua per l'atomicità).
Sapere come implementare questi (specialmente il pattern semplice e comune di finestra fissa con INCR + EXPIRE) è una competenza pratica e applicabile.
Poiché il rate limiting è un requisito comune per proteggere i servizi, e poiché Redis (con i suoi contatori atomici, velocità, TTL e condivisione cross-server) è lo strumento standard e ideale per il rate limiting distribuito, comprendere come implementarlo con Redis — gli algoritmi, i loro compromessi e perché Redis si adatta così bene — è una conoscenza preziosa e frequentemente applicabile per costruire servizi robusti e protetti, una delle applicazioni Redis più comuni e pratiche oltre al caching.