Wie implementierst du Rate Limiting mit Redis?

Question

IT Interview Practice · Accepted Answer

**Rate Limiting** (Einschränkung der Anzahl von Anfragen/Aktionen innerhalb eines Zeitfensters) ist ein häufiger Redis-Anwendungsfall — Redisʼ schnelle atomare Zähler und TTLs machen es ideal. Es gibt mehrere Algorithmen (Fixed Window, Sliding Window, Token Bucket), jeder mit Vor- und Nachteilen.

## Fixed Window (am einfachsten)

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

Der **Fixed-Window**-Ansatz: ein atomarer Zähler pro (Benutzer, Zeitfenster) mit einer TTL — Inkrementierung pro Anfrage, Ablehnung bei Überschreitung des Limits. Einfach und effizient, nutzt atomare `INCR` und automatisches Ablaufen.

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

## Sliding Window (glatter)

```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 (ermöglicht kontrollierte Bursts)

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

## Warum Redis ideal dafür ist

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

## Warum es wichtig ist

Rate Limiting mit Redis zu implementieren ist ein häufiger, praktischer Anwendungsfall, daher ist das Verständnis dafür wertvoll — Rate Limiting (Schutz von APIs und Services vor Missbrauch, Gewährleistung fairer Nutzung, Verhinderung von Überlastung) ist ein nahezu universales Bedürfnis, und Redis ist das Standard-Tool dafür.

Das Verständnis **warum Redis ideal ist**, ist wichtig: Seine **atomaren Zähler** (`INCR`) machen die Rate-Counting korrekt unter Concurrency (keine Race Conditions/verlorenen Counts), seine **Geschwindigkeit** (In-Memory) fügt minimale Latenz pro Anfrage hinzu, **TTLs** handhaben Fenster-Cleanup automatisch, und entscheidend ist, dass es **über Server verteilt** ist — ermöglicht **verteiltes Rate Limiting**, bei dem alle Application Server ein konsistentes Limit durchsetzen (essentiell in Multi-Server-Deployments, wo Pro-Server In-Memory Limits nicht funktionieren würden).

Das Verständnis der **Algorithmen** und ihrer Vor- und Nachteile ermöglicht es dir, angemessen zu wählen: **Fixed Window** (am einfachsten — ein atomarer Zähler pro Zeitfenster mit TTL, erlaubt aber Boundary Bursts), **Sliding Window** (glatter und präziser mit einem Sorted Set von Timestamp-Anfragen, mit höherem Memory-Overhead), und **Token Bucket** (ermöglicht kontrollierte Bursts bei Begrenzung der durchschnittlichen Rate, oft über ein Lua-Skript für Atomarität).

Zu wissen, wie man diese implementiert (besonders das einfache, häufige Fixed-Window-Pattern mit `INCR` + `EXPIRE`), ist praktische, anwendbare Fähigkeit.

Da Rate Limiting eine häufige Anforderung zum Schutz von Services ist, und da Redis (mit seinen atomaren Zählern, Geschwindigkeit, TTLs und Cross-Server-Sharing) das Standard-, ideale Tool für verteiltes Rate Limiting ist, ist das Verständnis, wie man es mit Redis implementiert — die Algorithmen, ihre Vor- und Nachteile, und warum Redis so gut passt — wertvoll, häufig anwendbares Wissen für den Aufbau robuster, geschützter Services, einer der häufigsten praktischen Redis-Anwendungen jenseits von Caching.

Fixed Window (am einfachsten)

Sliding Window (glatter)

Token Bucket (ermöglicht kontrollierte Bursts)

Warum Redis ideal dafür ist

Warum es wichtig ist

Ähnliche Fragen