Hogyan implementálsz sebességhatárlást Redis-szel?

Question

Accepted Answer

A **sebességhatárlás** (annak korlátozása, hogy hány kérés/művelet engedélyezett egy időablakban) egy gyakori Redis használati eset — a Redis gyors atomikus számlálói és TTL-jei ideálissá teszik. Több algoritmus létezik (fix időablak, csúszó ablak, token bucket), mindegyiknek vannak előnyei és hátrányai.

## Fix időablak (legegyszerűbb)

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

A **fix időablak** megközelítés: egy atomikus számláló (felhasználó, időablak) páronként TTL-lel — növelj meg minden kérésnél, utasíts el, amikor a limit túllépődik. Egyszerű és hatékony, az atomikus `INCR` és az automatikus lejárat kihasználásával.

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

## Csúszó ablak (simább)

```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 (vezérelt kitörések engedélyezése)

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

## Miért ideális a Redis erre

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

## Miért fontos

A sebességhatárlás Redis-szel történő implementálása egy gyakori, gyakorlati használati eset, ezért annak megértése értékes tudás — a sebességhatárlás (az API-k és szolgáltatások védelme a visszaéléstől, a méltányos használat biztosítása, a túlterhelés megakadályozása) szinte univerzális szükséglet, és a Redis az ehhez szokásos eszköz.

Annak megértése, hogy **miért ideális a Redis**, kulcsfontosságú: az **atomikus számlálói** (`INCR`) helyesek az egyidejűség alatt (nincs versenyfeltétel/elveszett számlálás), a **sebesség** (memóriában) minimális késést ad hozzá minden kéréshez, a **TTL-ek** automatikusan kezelik az ablak tisztítását, és meghatározóan **szervek közötti megosztottság** — lehetővé téve az **elosztott sebességhatárlást**, ahol az összes alkalmazáskiszolgáló egy konzisztens limitet érvényesít (lényeges a több kiszolgálós telepítésekben, ahol a szerver-specifikus memóriabeli limitek nem működnének).

Az **algoritmusok** és azok előnyei/hátrányai megértése lehetővé teszi a megfelelő kiválasztást: **fix időablak** (legegyszerűbb — egy atomikus számláló időablakonként TTL-lel, de engedélyezi az ablak-határok kitöréseit), **csúszó ablak** (simább és pontosabb, az időbélyegzett kérések rendezett halmazát használva, magasabb memóriaköltséggel), és **token bucket** (vezérelt kitörések engedélyezése az átlagos ráta korlátozása mellett, gyakran Lua-szkripttel az atomicitáshoz).

Annak ismerete, hogyan kell ezeket implementálni (különösen az egyszerű, gyakori fix-időablak mintát `INCR` + `EXPIRE` használatával), gyakorlati, alkalmazható készség.

Mivel a sebességhatárlás a szolgáltatások védelméhez szükséges közös követelmény, és mivel a Redis (atomikus számlálóival, sebességével, TTL-jeivel és szerver közötti megosztottságával) az elosztott sebességhatárláshoz szokásos, ideális eszköz, az annak Redis-szel történő implementálásának megértése — az algoritmusok, azok előnyei/hátrányai, és az, hogy miért illik a Redis így jól — értékes, gyakran alkalmazható tudás a robusztus, védett szolgáltatások felépítéséhez, a Redis leggyakoribb gyakorlati alkalmazásainak egyike a gyorsítótárazáson túl.