คุณจะใช้งาน rate limiting ด้วย Redis ได้อย่างไร?

Question

Accepted Answer

**Rate limiting** (การจำกัดจำนวนคำขอ/การกระทำที่อนุญาตภายในช่วงเวลาหนึ่ง) เป็นกรณีใช้งาน Redis ที่พบบ่อย — atomic counter ที่รวดเร็วและ TTL ของ Redis ทำให้มันเหมาะอย่างยิ่ง มีหลายอัลกอริทึม (fixed window, sliding window, token bucket) แต่ละแบบมีข้อแลกเปลี่ยนของตัวเอง

## Fixed window (ง่ายที่สุด)

```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**: ใช้ atomic counter ต่อ (user, time-window) พร้อม TTL — เพิ่มค่าทุกคำขอ และปฏิเสธเมื่อเกินขีดจำกัด เรียบง่ายและมีประสิทธิภาพ โดยอาศัย `INCR` แบบ atomic และการหมดอายุอัตโนมัติ

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

## Sliding window (ราบรื่นกว่า)

```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 (อนุญาต burst แบบควบคุมได้)

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

## ทำไม Redis จึงเหมาะกับงานนี้

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

## ทำไมจึงสำคัญ

การใช้งาน rate limiting ด้วย Redis เป็นกรณีใช้งานที่พบบ่อยและใช้ได้จริง ความเข้าใจในเรื่องนี้จึงเป็นความรู้ที่มีค่า — rate limiting (การปกป้อง API และบริการจากการใช้งานในทางที่ผิด การรับประกันการใช้งานที่เป็นธรรม และการป้องกันโอเวอร์โหลด) เป็นความต้องการที่แทบจะมีอยู่ทั่วไป และ Redis คือเครื่องมือมาตรฐานสำหรับงานนี้

การเข้าใจ **ว่าทำไม Redis จึงเหมาะ** เป็นกุญแจสำคัญ: **atomic counter** (`INCR`) ทำให้การนับ rate ถูกต้องภายใต้ concurrency (ไม่มี race condition/การนับที่หายไป), **ความเร็ว** (in-memory) เพิ่ม latency ให้แต่ละคำขอน้อยมาก, **TTL** จัดการการล้างหน้าต่างเวลาให้โดยอัตโนมัติ และที่สำคัญคือมัน **ถูกแชร์ระหว่างเซิร์ฟเวอร์** — ทำให้เกิด **distributed rate limiting** ที่เซิร์ฟเวอร์แอปพลิเคชันทั้งหมดบังคับใช้ขีดจำกัดเดียวที่สอดคล้องกัน (จำเป็นในการ deploy แบบหลายเซิร์ฟเวอร์ ซึ่งขีดจำกัด in-memory แยกต่อเซิร์ฟเวอร์จะใช้ไม่ได้)

การเข้าใจ **อัลกอริทึม** และข้อแลกเปลี่ยนของแต่ละแบบช่วยให้เลือกได้อย่างเหมาะสม: **fixed window** (ง่ายที่สุด — atomic counter ต่อหน้าต่างเวลาพร้อม TTL แต่ยอมให้เกิด burst ที่ขอบหน้าต่าง), **sliding window** (ราบรื่นและแม่นยำกว่าโดยใช้ sorted set ของคำขอที่มี timestamp แต่ใช้หน่วยความจำมากกว่า) และ **token bucket** (ยอมให้เกิด burst แบบควบคุมได้ขณะจำกัดอัตราเฉลี่ย มักทำผ่าน Lua script เพื่อความเป็น atomic)

การรู้วิธีใช้งานสิ่งเหล่านี้ (โดยเฉพาะรูปแบบ fixed-window ที่เรียบง่ายและพบบ่อยด้วย `INCR` + `EXPIRE`) เป็นทักษะที่นำไปใช้ได้จริง

เนื่องจาก rate limiting เป็นความต้องการที่พบบ่อยในการปกป้องบริการ และเนื่องจาก Redis (ด้วย atomic counter, ความเร็ว, TTL และการแชร์ข้ามเซิร์ฟเวอร์) คือเครื่องมือมาตรฐานและเหมาะที่สุดสำหรับ distributed rate limiting การเข้าใจวิธีใช้งานมันด้วย Redis — อัลกอริทึม ข้อแลกเปลี่ยน และเหตุผลที่ Redis เข้ากันได้ดี — จึงเป็นความรู้ที่มีค่าและนำไปใช้ได้บ่อยในการสร้างบริการที่แข็งแกร่งและได้รับการปกป้อง ซึ่งเป็นหนึ่งในการประยุกต์ใช้ Redis ที่พบบ่อยที่สุดนอกเหนือจาก caching