Kuinka toteutat rate limitingin Redisilla?

Question

Accepted Answer

**Rate limiting** (kuinka monta pyyntöä/toimintoa on sallittu aikaikkunassa) on yleinen Redis-käyttötapaus — Redisissa olevat nopeat atomiset laskurit ja TTL-arvot tekevät siitä ihanteellisen. Useita algoritmeja on olemassa (fixed window, sliding window, token bucket), joista jokaisella on omat kompromissit.

## Fixed window (yksinkertaisin)

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

**Fixed window** -lähestymistapa: atomiset laskurit per (käyttäjä, aika-ikkuna) TTL:llä — lisää jokaisella pyynnöllä, hylkää kun raja ylittyy. Yksinkertainen ja tehokas, hyödyntäen atomiset `INCR`-komennot ja automaattista vanhentumista.

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

## Sliding window (pehmeämpi)

```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 (sallii hallitut purkaukset)

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

## Miksi Redis on ihanteellinen tähän

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

## Miksi sillä on merkitystä

Rate limitingin toteuttaminen Redisilla on yleinen, käytännöllinen käyttötapaus, joten sen ymmärtäminen on arvokasta tietoa — rate limiting (API:den ja palveluiden suojaaminen väärinkäytöltä, reilun käytön varmistaminen, ylikuormituksen estäminen) on lähes universaalinen tarve, ja Redis on sen vakiotyökalu.

Ymmärtäminen **miksi Redis on ihanteellinen** on avainasemassa: sen **atomiset laskurit** (`INCR`) tekevät rate laskemisen oikeaksi samanaikaisuudessa (ei kilpailu-olosuhteita/menetettyjä laskuja), sen **nopeus** (muistissa) lisää minimaalista viivettä jokaiselle pyynnölle, **TTL-arvot** hoitavat ikkunan puhdistuksen automaattisesti, ja oleellisesti se on **jaettu palvelimien kesken** — mahdollistaen **hajautetun rate limitingin** jossa kaikki sovelluspalvelimet pakottavat yhden johdonmukaisen rajan (välttämätön monesti palvelimissa, joissa palvelimen sisäiset muistilimitit eivät toimisi).

Ymmärtäminen **algoritmeista** ja niiden kompromisseista antaa sinulle mahdollisuuden valita asianmukaisesti: **fixed window** (yksinkertaisin — atomiset laskurit aika-ikkunaa kohti TTL:llä, mutta sallien rajan ylittävät purkaukset), **sliding window** (pehmeämpi ja tarkempi käyttäen leimattuja pyyntöjä sorted setissa, korkeammalla muistikustannuksella), ja **token bucket** (sallii hallitut purkaukset samalla kun rajaa keskimääräisen nopeuden, usein Lua-skriptillä atomaarisuuden vuoksi).

Tieto näiden toteuttamisesta (erityisesti yksinkertainen, yleinen fixed-window malli `INCR` + `EXPIRE` kanssa) on käytännöllinen, sovellettava taito.

Koska rate limiting on yleinen vaatimus palveluiden suojaamisen kannalta, ja koska Redis (atomiset laskureiden, nopeuden, TTL-arvojen ja palvelimien ylittävän jakamisen kanssa) on vakio, ihanteellinen työkalu hajautetulle rate limitingille, ymmärtäminen kuinka toteuttaa se Redisilla — algoritmit, niiden kompromissit ja miksi Redis sopii niin hyvin — on arvokasta, usein sovellettavaa tietoa kestävien, suojattujen palvelujen rakentamiseen, yksi yleisimmistä käytännön Redis-sovelluksista välimuistin lisäksi.