Bagaimana anda melaksanakan rate limiting dengan Redis?

Question

Accepted Answer

**Rate limiting** (mengehadkan berapa banyak permintaan/tindakan dibenarkan dalam satu tetingkap masa) ialah kes penggunaan Redis yang biasa — kaunter atomik yang pantas dan TTL pada Redis menjadikannya ideal. Beberapa algoritma wujud (fixed window, sliding window, token bucket), masing-masing dengan pertukaran (trade-off) tersendiri.

## Fixed window (paling ringkas)

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

Pendekatan **fixed window**: satu kaunter atomik bagi setiap (pengguna, tetingkap masa) dengan TTL — tambah setiap permintaan, tolak apabila melebihi had. Ringkas dan cekap, memanfaatkan `INCR` atomik dan auto-expiry.

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

## Sliding window (lebih lancar)

```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 (membenarkan burst terkawal)

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

## Mengapa Redis ideal untuk ini

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

## Mengapa ia penting

Melaksanakan rate limiting dengan Redis ialah kes penggunaan yang biasa dan praktikal, jadi memahaminya merupakan pengetahuan yang berharga — rate limiting (melindungi API dan perkhidmatan daripada penyalahgunaan, memastikan penggunaan yang adil, mencegah beban berlebihan) ialah keperluan yang hampir universal, dan Redis ialah alat standard untuknya.

Memahami **mengapa Redis ideal** adalah kunci: **kaunter atomik**nya (`INCR`) menjadikan pengiraan kadar betul di bawah concurrency (tiada race condition/kiraan hilang), **kepantasan**nya (in-memory) menambah kependaman (latency) yang minimum pada setiap permintaan, **TTL** mengendalikan pembersihan tetingkap secara automatik, dan yang paling penting ia **dikongsi merentas pelayan** — membolehkan **distributed rate limiting** di mana semua pelayan aplikasi menguatkuasakan satu had yang konsisten (penting dalam penggunaan berbilang pelayan, di mana had in-memory per-pelayan tidak akan berfungsi).

Memahami **algoritma** dan pertukarannya membolehkan anda memilih dengan sewajarnya: **fixed window** (paling ringkas — satu kaunter atomik bagi setiap tetingkap masa dengan TTL, tetapi membenarkan burst di sempadan), **sliding window** (lebih lancar dan lebih tepat menggunakan sorted set bagi permintaan bertanda masa, dengan kos memori yang lebih tinggi), dan **token bucket** (membenarkan burst terkawal sambil mengehadkan kadar purata, selalunya melalui skrip Lua untuk atomicity).

Mengetahui cara melaksanakan ini (terutamanya corak fixed-window yang ringkas dan biasa dengan `INCR` + `EXPIRE`) ialah kemahiran yang praktikal dan boleh diaplikasikan.

Memandangkan rate limiting ialah keperluan yang biasa untuk melindungi perkhidmatan, dan memandangkan Redis (dengan kaunter atomik, kepantasan, TTL, dan perkongsian merentas pelayan) ialah alat standard yang ideal untuk distributed rate limiting, memahami cara melaksanakannya dengan Redis — algoritma, pertukarannya, dan mengapa Redis begitu sesuai — merupakan pengetahuan yang berharga dan kerap diaplikasikan untuk membina perkhidmatan yang teguh dan terlindung, salah satu aplikasi Redis praktikal yang paling biasa di luar caching.