Bạn triển khai rate limiting với Redis như thế nào?

Question

Accepted Answer

**Rate limiting** (giới hạn số request/hành động được phép trong một khung thời gian) là một use case Redis phổ biến — counter nguyên tử nhanh và TTL của Redis khiến nó lý tưởng. Có nhiều thuật toán (fixed window, sliding window, token bucket), mỗi cái có đánh đổi riêng.

## Fixed window (đơn giản nhất)

```js
// cho phép N request mỗi khung thời gian dùng counter nguyên tử với 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);     // tăng nguyên tử
  if (count === 1) await redis.expire(key, windowSec);  // đặt TTL ở request đầu tiên
  return count <= limit;                    // được phép nếu dưới giới hạn
}
// → INCR là nguyên tử (đúng khi đồng thời); key tự hết hạn mỗi window
```

Phương pháp **fixed window**: một counter nguyên tử cho mỗi (user, khung thời gian) với TTL — tăng theo mỗi request, từ chối khi vượt giới hạn. Đơn giản và hiệu quả, tận dụng `INCR` nguyên tử và tự hết hạn.

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

## Sliding window (mượt hơn)

```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 (cho phép burst có kiểm soát)

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

## Tại sao Redis lý tưởng cho việc này

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

## Tại sao điều này quan trọng

Triển khai rate limiting với Redis là một use case phổ biến, thực hành, nên hiểu nó là kiến thức giá trị — rate limiting (bảo vệ API và service khỏi lạm dụng, đảm bảo sử dụng công bằng, ngăn quá tải) là nhu cầu gần như phổ quát, và Redis là công cụ tiêu chuẩn cho nó.

Hiểu **tại sao Redis lý tưởng** là then chốt: **counter nguyên tử** (`INCR`) khiến việc đếm rate đúng khi đồng thời (không có race condition/mất đếm), **tốc độ** (in-memory) thêm độ trễ tối thiểu vào mỗi request, **TTL** xử lý dọn dẹp window tự động, và quan trọng là nó **dùng chung giữa các server** — cho phép **rate limiting phân tán** nơi tất cả server ứng dụng thực thi một giới hạn nhất quán (thiết yếu trong triển khai nhiều server, nơi giới hạn in-memory theo từng server sẽ không hoạt động).

Hiểu các **thuật toán** và đánh đổi của chúng cho phép bạn chọn đúng: **fixed window** (đơn giản nhất — một counter nguyên tử cho mỗi khung thời gian với TTL, nhưng cho phép burst ở ranh giới), **sliding window** (mượt hơn và chính xác hơn dùng một sorted set của các request có timestamp, với chi phí bộ nhớ cao hơn), và **token bucket** (cho phép burst có kiểm soát trong khi giới hạn rate trung bình, thường qua một Lua script để đảm bảo nguyên tử).

Biết cách triển khai chúng (đặc biệt là pattern fixed-window đơn giản, phổ biến với `INCR` + `EXPIRE`) là kỹ năng thực hành, có thể áp dụng.

Vì rate limiting là yêu cầu phổ biến để bảo vệ service, và vì Redis (với counter nguyên tử, tốc độ, TTL, và dùng chung giữa server) là công cụ tiêu chuẩn, lý tưởng cho rate limiting phân tán, hiểu cách triển khai nó với Redis — các thuật toán, đánh đổi của chúng, và tại sao Redis phù hợp đến vậy — là kiến thức giá trị, thường xuyên có thể áp dụng để xây các service vững chắc, được bảo vệ, một trong những ứng dụng Redis thực hành phổ biến nhất ngoài caching.