كيف تنفذ rate limiting باستخدام Redis؟

Question

Accepted Answer

**Rate limiting** (تقييد عدد الطلبات/الإجراءات المسموحة في نافذة زمنية) هي حالة استخدام شائعة لـ Redis — العدادات الذرية السريعة في Redis و TTLs تجعلها مثالية. توجد عدة خوارزميات (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**: عداد ذري لكل (مستخدم، نافذة زمنية) مع TTL — زيادة لكل طلب، رفض عند تجاوز الحد. بسيط وفعال، يستفيد من `INCR` الذري والانتهاء التلقائي.

```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 (يسمح بـ 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
```

## لماذا 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 (حماية APIs والخدمات من الإساءة، ضمان الاستخدام العادل، منع الإرهاق) هي حاجة عالمية تقريباً، و Redis هي الأداة القياسية لها.
هم **لماذا Redis مثالي** هو المفتاح: **العدادات الذرية** (`INCR`) تجعل عد rate صحيحاً تحت التزامن (لا توجد race conditions/عدادات مفقودة)، **السرعة** (في الذاكرة) تضيف زمن كمون ضئيل لكل طلب، **TTLs** تتعامل مع تنظيف النافذة تلقائياً، والأهم أنها **مشتركة عبر الخوادم** — تمكين **distributed rate limiting** حيث تفرض جميع خوادم التطبيق حد واحد متسق (ضروري في النشرات متعددة الخوادم، حيث أن الحدود في الذاكرة لكل خادم لن تعمل).

فهم **الخوارزميات** و مقابلاتها يتيح لك الاختيار بشكل مناسب: **fixed window** (الأبسط — عداد ذري لكل نافذة زمنية مع TTL، لكن يسمح ببurst على الحدود)، **sliding window** (أكثر سلاسة ودقة باستخدام sorted set من الطلبات بالطوابع الزمنية، بتكلفة ذاكرة أعلى)، و **token bucket** (يسمح ببurst محكومة مع تحديد متوسط المعدل، غالباً عبر Lua script من أجل الذرية).

معرفة كيفية تنفيذ هذه (خاصة نمط fixed-window البسيط الشائع مع `INCR` + `EXPIRE`) هي مهارة عملية قابلة للتطبيق.

بما أن rate limiting متطلب شائع لحماية الخدمات، وبما أن Redis (مع عدادات ذرية، سرعة، TTLs، ومشاركة عبر الخوادم) هي الأداة القياسية والمثالية لـ distributed rate limiting، فهم كيفية تنفيذها مع Redis — الخوارزميات، مقابلاتها، ولماذا تناسب Redis — معرفة قيمة وقابلة للتطبيق بكثرة لبناء خدمات قوية ومحمية، واحدة من أكثر تطبيقات Redis العملية الشائعة خارج caching.