Jak zaimplementować ograniczanie szybkości (rate limiting) za pomocą Redis?

Question

Accepted Answer

**Ograniczanie szybkości** (restricting how many requests/actions are allowed in a time window) to częsty przypadek użycia Redis — szybkie atomowe liczniki Redis i TTL-e czynią go idealnym. Istnieje kilka algorytmów (fixed window, sliding window, token bucket), każdy z różnymi kompromisami.

## Okno stałe (najprostsze)

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

Podejście **fixed window**: atomowy licznik na (użytkownik, okno czasowe) z TTL — inkrementuj przy każdym żądaniu, odrzuć gdy przekroczona jest granica. Proste i wydajne, wykorzystujące atomowe `INCR` i automatyczne wygasanie.

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

## Okno przesuwane (płynniejsze)

```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 (umożliwia kontrolowane bursting)

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

## Dlaczego Redis jest idealny do tego

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

## Dlaczego to ważne

Implementowanie ograniczania szybkości za pomocą Redis to częsty, praktyczny przypadek użycia, dlatego zrozumienie go to cenna wiedza — ograniczanie szybkości (ochrona API i usług przed nadużyciami, zapewnienie uczciwego użycia, zapobieganie przeciążeniu) to niemal uniwersalna potrzeba, a Redis to standardowe narzędzie do tego.

Zrozumienie **dlaczego Redis jest idealny** to kluczowe: jego **atomowe liczniki** (`INCR`) sprawiają, że liczenie szybkości jest poprawne przy współbieżności (brak race conditions/utraty liczb), jego **szybkość** (w pamięci) dodaje minimalny czas opóźnienia do każdego żądania, **TTL-e** automatycznie czyszczą okna, a co ważne jest **współdzielone między serwerami** — umożliwiając **rozproszone ograniczanie szybkości** gdzie wszystkie serwery aplikacji egzekwują jedno spójne ograniczenie (niezbędne we wdrożeniach wieloserwerowych, gdzie ograniczenia w pamięci per-serwer nie działałyby).

Zrozumienie **algorytmów** i ich kompromisów pozwala na właściwy wybór: **fixed window** (najprostsze — atomowy licznik na okno czasowe z TTL, ale umożliwiające bursting na granicy), **sliding window** (płynniejsze i dokładniejsze przy użyciu posortowanego zestawu żądań z czasami, przy wyższych kosztach pamięci) i **token bucket** (umożliwiające kontrolowane bursting przy jednoczesnym ograniczeniu średniej szybkości, często poprzez skrypt Lua dla atomowości).

Wiedzenie jak to zaimplementować (zwłaszcza proste, częste podejście fixed-window z `INCR` + `EXPIRE`) to praktyczna, zastosowalna umiejętność.

Ponieważ ograniczanie szybkości to powszechny wymóg ochrony usług, a Redis (ze swoimi atomowymi licznikami, szybkością, TTL-ami i współdzieleniem między serwerami) to standardowe, idealne narzędzie do rozproszonego ograniczania szybkości, zrozumienie jak to zaimplementować za pomocą Redis — algorytmy, ich kompromisy i dlaczego Redis pasuje tak dobrze — to cenna, często stosowana wiedza do budowania solidnych, chronionych usług, jedno z najczęstszych praktycznych zastosowań Redis poza cachingiem.