Cum implementezi limitarea ratei de cereri cu Redis?

Question

Accepted Answer

**Limitarea ratei de cereri** (restricționarea numărului de cereri/acțiuni permise într-o fereastră de timp) este un caz de utilizare comun al Redis — contoarele atomice rapide și TTL-urile Redis o fac ideală. Există mai mulți algoritmi (fereastră fixă, fereastră deslizantă, token bucket), fiecare cu compromisuri.

## Fereastră fixă (cea mai simplă)

```js
// allow N requests per time window using an atomic counter with a TTL
async function rateLimit(userId, limit = 100, windowSec = 60) {
  const key = `rate:${userId}:${Math.floor(Date.now() / 1000 / windowSec)}`;
  const count = await redis.incr(key);     // atomic increment
  if (count === 1) await redis.expire(key, windowSec);  // set TTL on first request
  return count <= limit;                    // allowed if under the limit
}
// → INCR is atomic (correct under concurrency); the key auto-expires each window
```

Abordarea **ferestrei fixe**: un contor atomic per (utilizator, fereastră de timp) cu un TTL — incrementare per cerere, respingere când se depășește limita. Simplă și eficientă, utilizând `INCR` atomic și expirare automată.

```text
✗ Limitation: bursts at window boundaries (2x limit possible across two adjacent windows)
```

## Fereastră deslizantă (mai lin)

```text
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 (permite rafale controlate)

```text
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
```

## De ce Redis este ideal pentru aceasta

```text
✓ 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.
```

## De ce conteaza

Implementarea limitării ratei de cereri cu Redis este un caz de utilizare comun și practic, deci înțelegerea acestuia este o cunoaștere valoroasă — limitarea ratei de cereri (protejarea API-urilor și serviciilor de abuzuri, asigurarea unei utilizări corecte, prevenirea supraîncărcării) este o nevoie aproape universală, iar Redis este instrumentul standard pentru aceasta.

Înțelegerea **de ce Redis este ideal** este esențială: **contoarele sale atomice** (`INCR`) fac numărarea ratei corectă sub concurență (fără condiții de cursă/pierdere de numărări), **viteza** (în memorie) adaugă latență minimă pentru fiecare cerere, **TTL-urile** gestionează curățarea ferestrei automat, și în mod crucial este **partajat între servere** — permițând **limitarea ratei de cereri distribuită** unde toate serverele de aplicații impun o limită comună și consecventă (esențial în implementările multi-server, unde limitele în memorie per-server nu ar funcționa).

Înțelegerea **algoritmilor** și a compromisurilor lor vă permite să alegeți în mod corespunzător: **fereastră fixă** (cea mai simplă — un contor atomic per fereastră de timp cu un TTL, dar permițând rafale la graniță), **fereastră deslizantă** (mai lin și mai precis folosind un set sortat de cereri cu marcă de timp, la cost mai mare de memorie), și **token bucket** (permițând rafale controlate în timp ce se limitează rata medie, adesea printr-un script Lua pentru atomicitate).

Cunoașterea modului de implementare a acestora (în special modelul simplu și comun de fereastră fixă cu `INCR` + `EXPIRE`) este o abilitate practică și aplicabilă.

Deoarece limitarea ratei de cereri este o cerință comună pentru protejarea serviciilor, și deoarece Redis (cu contoarele sale atomice, viteza, TTL-urile și partajarea între servere) este instrumentul standard și ideal pentru limitarea distribuită a ratei de cereri, înțelegerea modului de implementare cu Redis — algoritmii, compromisurile acestora și de ce Redis se potrivește atât de bine — este o cunoaștere valoroasă și frecvent aplicabilă pentru construirea unor servicii robuste și protejate, una dintre cele mai comune aplicații practice ale Redis dincolo de caching.