Kako implementiraš omejevanje stopnje zahtevkov z Redisom?

Question

Accepted Answer

**Omejevanje stopnje zahtevkov** (omejevanje števila dovoljenih zahtevkov/akcij v časovnem oknu) je pogosta uporaba Redisa — Redisovi hitri atomski števci in TTL (time-to-live) ga naredijo idealnim. Obstaja več algoritmov (fiksno okno, drsljivo okno, žetoni), vsak ima svoje prednosti in slabosti.

## Fiksno okno (najpreprosteje)

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

Pristop **fiksnega okna**: atomski števec za (uporabnika, časovno-okno) s TTL — povečaj pri vsakem zahtevku, zavrni, če je presežena omejitev. Preprost in učinkovit, izkoriščajoč atomsko `INCR` in samodejno potekanje.

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

## Drsljivo okno (gladkeje)

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

## Žetoni (dovoljeni nadzorovani porivi)

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

## Zakaj je Redis idealen za 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.
```

## Zakaj je to pomembno

Implementacija omejevanja stopnje zahtevkov z Redisom je pogosta, praktična uporaba, zato je razumevanje tega dragoceno znanje — omejevanje stopnje zahtevkov (zaščita API-jev in storitev pred zlorabami, zagotavljanje poštenega uporabe, preprečevanje preobremenitve) je skoraj univerzalna potreba, Redis pa je standardno orodje za to.

Razumevanje **zakaj je Redis idealen** je ključno: njegovi **atomski števci** (`INCR`) naredijo štetje stopnje zahtevkov pravilno pod sočasnostjo (brez stanja tekmovanja/izgubljenih števcev), njegova **hitrost** (v pomnilniku) doda minimalno zakasnitev vsakemu zahtevku, **TTL** avtomatično očistijo okno, in ključno je, da je **deljen med strežniki** — omogoča **porazdeljeno omejevanje stopnje zahtevkov**, kjer vsi aplikacijski strežniki uveljavljajo eno skladno omejitev (nujno v implementacijah z več strežniki, kjer omejitve v pomnilniku za vsak strežnik ne bi delovale).

Razumevanje **algoritmov** in njihovih kompromisov te pusti izbrati primerno: **fiksno okno** (najpreprosteje — atomski števec na časovno okno s TTL, vendar dovoljuje porivi na meji), **drsljivo okno** (gladkeje in natančnejše z uporabo sortiranega niza časovnih žigov zahtevkov, s težo večjih stroškov pomnilnika), in **žetoni** (dovoljeni nadzorovani porivi ob omejevanju povprečne stopnje zahtevkov, pogosto prek Lua scenarija za atomskost).

Znanje, kako implementirati te (posebej preprost, pogost vzorec fiksnega okna z `INCR` + `EXPIRE`) je praktičnim, uporabna veščina.

Ker je omejevanje stopnje zahtevkov pogost zahtevek za zaščito storitev, in ker je Redis (s svojimi atomskimi števci, hitrostjo, TTL in delitvijo med strežniki) standardno, idealno orodje za porazdeljeno omejevanje stopnje zahtevkov, je razumevanje, kako ga implementirati z Redisom — algoritme, njihove kompromise in zakaj se Redis tako dobro prilega — dragoceno, pogosto uporabljivo znanje za gradnjo robustnih, zaščitenih storitev, ena najbolj pogostih praktičnih aplikacij Redisa poleg hranjenja v predpomnilniku.