Jak implementujete rate limiting s Redis?

Question

Accepted Answer

**Rate limiting** (omezování počtu povolených požadavků/akcí v časovém okně) je běžný případ použití Redis — rychlé atomické čítače Redis a TTL to dělají ideálním. Existuje několik algoritmů (pevné okno, posuvné okno, token bucket), každý s různými kompromisy.

## Pevné okno (nejjednoduší)

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

Přístup **pevného okna**: atomický čítač na (uživatel, časové okno) s TTL — inkrementace na požadavek, odmítnutí když překročí limit. Jednoduchý a efektivní, využívající atomické `INCR` a automatické vypršení.

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

## Posuvné okno (hladší)

```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žňuje kontrolované nárůsty)

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

## Proč je Redis ideální na to

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

## Proč na tom záleží

Implementace rate limitingu s Redis je běžný, praktický případ použití, takže jeho porozumění je cenné — rate limiting (ochrana API a služeb před zneužitím, zajištění spravedlivého použití, prevence přetížení) je téměř univerzální potřeba a Redis je na to standardní nástroj.

Porozumění **proč je Redis ideální** je klíčové: jeho **atomické čítače** (`INCR`) činí počítání sazby správné při souběhu (žádné podmínky závodu/ztracené počty), jeho **rychlost** (v paměti) přidává minimální latenci každému požadavku, **TTL** automaticky řeší vyčištění okna a zásadně je **sdílený mezi servery** — umožňující **distribuovaný rate limiting** kde všechny aplikační servery vynucují jeden konzistentní limit (nezbytné v nasazeních s více servery, kde limity v paměti na server by nefungovaly).

Porozumění **algoritmům** a jejich kompromisům vám umožní vybrat vhodně: **pevné okno** (nejjednoduší — atomický čítač na časové okno s TTL, ale umožňující nárůsty na hranici), **posuvné okno** (hladší a přesnější pomocí seřazené sady požadavků s časovými razítky, s vyšší cenou paměti), a **token bucket** (umožňující kontrolované nárůsty při omezení průměrné sazby, často přes Lua skript pro atomicitu).

Znalost jak to implementovat (obzvláště jednoduchý, běžný vzor pevného okna s `INCR` + `EXPIRE`) je praktická, aplikovatelná dovednost.

Keďže rate limiting je běžný požadavek na ochranu služeb a keďže Redis (s jeho atomickými čítači, rychlostí, TTL a sdílením mezi servery) je standardní, ideální nástroj pro distribuovaný rate limiting, porozumění jak to implementovat s Redis — algoritmy, jejich kompromisy a proč se Redis hodí tak dobře — je cenná, často používaná znalost pro budování robustních, chráněných služeb, jedné z nejběžnějších praktických aplikací Redis mimo ukládání do mezipaměti.