ਤੁਸੀਂ Redis ਨਾਲ ਰੇਟ ਲਿਮਿਟਿੰਗ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਦੇ ਹੋ?

Question

Accepted Answer

**Rate limiting** (ਇੱਕ ਸਮਾਂ ਵਿੰਡੋ ਵਿੱਚ ਕਿੰਨੀਆਂ ਰੀਕਵੈਸਟਾਂ/ਕ੍ਰਿਆਵਾਂ ਦੀ ਆਗਿਆ ਹੈ ਇਸ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ) ਇੱਕ ਆਮ Redis ਵਰਤੋਂ ਦਾ ਕੇਸ ਹੈ — Redis ਦੇ ਤੇਜ਼ ਪਰਮਾਣੂ ਕਾਉਂਟਰ ਅਤੇ TTLs ਇਸਨੂੰ ਆਦਰਸ਼ ਬਣਾਉਂਦੇ ਹਨ। ਕਈ ਐਲਗੋਰਿਦਮ ਮੌਜੂਦ ਹਨ (ਸਥਿਰ ਵਿੰਡੋ, ਸਲਾਈਡਿੰਗ ਵਿੰਡੋ, ਟੋਕਨ ਬਾਲਟੀ), ਹਰ ਇੱਕ ਦੇ trade-offs ਹਨ।

## ਸਥਿਰ ਵਿੰਡੋ (ਸਭ ਤੋਂ ਸਰਲ)

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

**ਸਥਿਰ ਵਿੰਡੋ** ਦਾ ਤਰੀਕਾ: ਇੱਕ TTL ਦੇ ਨਾਲ (ਯੂਜ਼ਰ, ਸਮਾਂ-ਵਿੰਡੋ) ਪ্ਰਤੀ ਪਰਮਾਣੂ ਕਾਉਂਟਰ — ਪ੍ਰਤੀ ਰੀਕਵੈਸਟ ਨੂੰ ਵਧਾਓ, ਸੀਮਾ ਨੂੰ ਪਾਰ ਕਰਨ ਤੇ ਰੱਦ ਕਰੋ। ਸਧਾਰਨ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ, ਪਰਮਾਣੂ `INCR` ਅਤੇ ਸਵੈ-ਰੂpharancy ਨੂੰ ਲਿਵਰੇਜ ਕਰਦੇ ਹਨ।

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

## ਸਲਾਈਡਿੰਗ ਵਿੰਡੋ (ਵਧੇਰੇ ਮਸ਼ਲੰਗ)

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

## ਟੋਕਨ ਬਾਲਟੀ (ਨਿਯੰਤ੍ਰਿਤ ਬਰਸਟਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ)

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

## ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

Redis ਦੇ ਨਾਲ rate limiting ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਇੱਕ ਆਮ, ਵਿਹਾਰਕ ਵਰਤੋਂ ਦਾ ਕੇਸ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਸਮਝਣਾ ਮੁੱਲਵਾਨ ਗਿਆਨ ਹੈ — rate limiting (APIs ਅਤੇ ਸੇਵਾਵਾਂ ਨੂੰ ਦੁਰਵਿਵਹਾਰ ਤੋਂ ਬਚਾਉਣਾ, ਨਿਰਪੱਖ ਵਰਤੋਂ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ, ਓਵਰਲੋਡ ਨੂੰ ਰੋਕਣਾ) ਲਗਭਗ ਸਰਵ-ਵਿਆਪੀ ਲੋੜ ਹੈ, ਅਤੇ Redis ਇਸ ਲਈ ਮਾਨਕ ਸਾਧਨ ਹੈ।

**Redis ਕਿਉਂ ਆਦਰਸ਼ ਹੈ** ਇਹ ਸਮਝਣਾ ਮੁੱਖ ਹੈ: ਇਸਦੇ **ਪਰਮਾਣੂ ਕਾਉਂਟਰ** (`INCR`) ਸਮਰੂਪਤਾ ਦੇ ਅਧੀਨ rate counting ਨੂੰ ਸਹੀ ਬਣਾਉਂਦੇ ਹਨ (ਕੋਈ ਦੌੜ ਦੀਆਂ ਸਥਿਤੀਆਂ/ਗਵਾਈ ਗਈ ਗਿਣਤੀ ਨਹੀਂ), ਇਸਦੀ **ਗਤੀ** (ਮੈਮੋਰੀ ਵਿੱਚ) ਹਰ ਰੀਕਵੈਸਟ ਨੂੰ ਘੱਟ ਤਾਖ ਜੋੜਦੀ ਹੈ, **TTLs** ਵਿੰਡੋ ਸਫਾਈ ਆਪਣੇ ਆਪ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ, ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਤੌਰ ਤੇ ਇਹ **ਸਰਵਰਾਂ ਵਿੱਚ ਸਾਂਝਾ** ਹੈ — **ਵਿਤ੍ਰਿਤ rate limiting** ਨੂੰ ਸਮਰਥ ਬਣਾਉਂਦੇ ਹਨ ਜਿੱਥੇ ਸਾਰੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਇੱਕ ਸਥਿਰ ਸੀਮਾ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ (ਮਲਟੀ-ਸਰਵਰ ਤਾਇਨਾਤੀਆਂ ਵਿੱਚ ਜ਼ਰੂਰੀ, ਜਿੱਥੇ ਪ੍ਰਤੀ-ਸਰਵਰ ਇਨ-ਮੈਮੋਰੀ ਸੀਮਾਵਾਂ ਕੰਮ ਨਹੀਂ ਕਰੂੰਗੀਆਂ)।

**ਐਲਗੋਰਿਦਮ** ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ trade-offs ਨੂੰ ਸਮਝਣਾ ਤੁਹਾਨੂੰ ਉੱਚਿਤ ਤਰੀਕੇ ਨਾਲ ਚੁਣਨ ਦਿੰਦਾ ਹੈ: **ਸਥਿਰ ਵਿੰਡੋ** (ਸਭ ਤੋਂ ਸਰਲ — ਇੱਕ ਸਮਾਂ-ਵਿੰਡੋ ਪ੍ਰਤੀ ਪਰਮਾਣੂ ਕਾਉਂਟਰ ਇੱਕ TTL ਦੇ ਨਾਲ, ਪਰ ਸੀਮਾ ਤੇ ਬਰਸਟਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ), **ਸਲਾਈਡਿੰਗ ਵਿੰਡੋ** (ਸਮਾਂ-ਸਟਾਂਪ ਰੀਕਵੈਸਟਾਂ ਦੇ ਇੱਕ ਛਾਂਟੇ ਹੋਏ ਸੈਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਮਲਾ ਅਤੇ ਵਧੇਰੇ ਸਹੀ, ਵਧੇਰੇ ਮੈਮੋਰੀ ਖਰਚ ਤੇ), ਅਤੇ **ਟੋਕਨ ਬਾਲਟੀ** (ਨਿਯੰਤ੍ਰਿਤ ਬਰਸਟਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ ਜਦੋਂਕਿ ਔਸਤ ਦਰ ਨੂੰ ਸੀਮਿਤ ਕਰਦੇ ਹਨ, ਅਕਸਰ ਪਰਮਾਣੂਤਾ ਲਈ Lua ਸਕ੍ਰਿਪਟ ਦੁਆਰਾ)।

ਇਹ ਜਾਣਨਾ ਕਿ ਇਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ (ਖਾਸ ਤੌਰ ਤੇ ਸਧਾਰਨ, ਆਮ ਸਥਿਰ-ਵਿੰਡੋ ਪੈਟਰਨ `INCR` + `EXPIRE` ਦੇ ਨਾਲ) ਵਿਹਾਰਕ, ਲਾਗੂ ਕਰਨ ਯੋਗ ਹੁਨਰ ਹੈ।

ਕਿਉਂਕਿ rate limiting ਸੇਵਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਦੇਣ ਲਈ ਇੱਕ ਆਮ ਲੋੜ ਹੈ, ਅਤੇ ਕਿਉਂਕਿ Redis (ਇਸਦੇ ਪਰਮਾਣੂ ਕਾਉਂਟਰਾਂ, ਗਤੀ, TTLs, ਅਤੇ ਕ੍ਰਾਸ-ਸਰਵਰ ਸਾਂਝੇ ਨਾਲ) ਵਿਤ੍ਰਿਤ rate limiting ਲਈ ਮਾਨਕ, ਆਦਰਸ਼ ਸਾਧਨ ਹੈ, ਇਹ ਸਮਝਣਾ ਕਿ Redis ਨਾਲ ਇਸ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ — ਐਲਗੋਰਿਦਮ, ਉਨ੍ਹਾਂ ਦੇ trade-offs, ਅਤੇ Redis ਕਿਉਂ ਫਿੱਟ ਹੈ — ਮਜ਼ਬੂਤ, ਸੁਰੱਖਿਤ ਸੇਵਾਵਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਮੁੱਲਵਾਨ, ਅਕਸਰ-ਲਾਗੂ ਗਿਆਨ ਹੈ, caching ਤੋਂ ਪਰੇ ਸਭ ਤੋਂ ਆਮ ਵਿਹਾਰਕ Redis ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚੋਂ ਇੱਕ।