Si të zbatohet limitimi i shkallës me Redis?

Question

Accepted Answer

**Limitimi i shkallës** (kufizimi i numrit të kërkesave/veprimeve të lejuara në një dritare kohore) është një rast i zakonshëm përdorimi i Redis — numruesit atomikë të shpejtë të Redis dhe TTL-et e bëjnë ideale. Ekzistojnë disa algoritme (dritare fikse, dritare rrëshqitëse, kufa e terapisë), secila me kompromise.

## Dritare fikse (më e thjeshtë)

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

Qasja **dritane fikse**: një numrues atomik për (përdorues, dritane kohore) me një TTL — rritje për çdo kërkesë, refuzim kur tejkalim i limitit. E thjeshtë dhe efikase, duke shfrytëzuar `INCR` atomike dhe skadim automatik.

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

## Dritare rrëshqitëse (më e butë)

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

## Kufa e terapisë (lejon shpërtime të kontrolluar)

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

## Pse Redis është ideale për këtë

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

## Pse ka rëndësi

Zbatimi i limitimit të shkallës me Redis është një rast i zakonshëm, praktik përdorimi, kështu që kuptimi i tij është njohuri me vlerë — limitimi i shkallës (mbrojtja e API-ve dhe shërbimeve nga keqpërdorimi, sigurimi i përdorimit të drejtë, parandalimi i mbingarkesës) është një nevojë pothuajse universale, dhe Redis është mjeti standard për të.

Kuptimi **i arsyes se përse Redis është ideale** është kyç: **numruesit e tij atomikë** (`INCR`) e bëjnë numërimin e normës korrekt nën parakohësi (pa kushte gare/numra të humbur), **shpejtësia e tij** (në memorie) shton latencë minimale për çdo kërkesë, **TTL-et** trajtojnë pastrimin e dritares automatikisht, dhe në mënyrë vendimtare **është ndarë ndërmjet serverave** — duke mundësuar **limitimin e shkallës të shpërndarë** ku të gjithë serverit të aplikacionit zbatojnë një limit konsistent (thelbësor në zbatime me shumë servera, ku limitet në memorie për server nuk do të funksiononte).

Kuptimi i **algoritmeve** dhe kompromiseve të tyre ju lejon të zgjidhni në mënyrë të përshtatshme: **dritane fikse** (më e thjeshtë — një numrues atomik për dritane kohore me një TTL, por duke lejuar shpërtime kufitare), **dritane rrëshqitëse** (më e butë dhe më e saktë duke përdorur një grup të sortuar të kërkesave me kohëstempel, me kostim më të lartë memorie), dhe **kufa e terapisë** (duke lejuar shpërtime të kontrolluar ndërsa limito normën mesatare, shpesh përmes një skenari Lua për atomicitetin).

Dija se si të zbatohen këto (veçanërisht modeli i thjeshtë, i zakonshëm i dritanës fikse me `INCR` + `EXPIRE`) është aftësi praktike, e zbatueshme.

Meqenëse limitimi i shkallës është një kërkesë e zakonshme për mbrojtjen e shërbimeve, dhe meqenëse Redis (me numruesit e tij atomikë, shpejtësinë, TTL-et dhe ndarjen ndërmjet serverave) është mjeti standard, ideal për limitimin e shkallës të shpërndarë, kuptimi se si të zbatohet me Redis — algoritmet, kompromiseve të tyre, dhe pse Redis përshtatet kaq mirë — është njohuri e vlefshme, e zbatueshme shpesh për ndërtimin e shërbimeve të fuqishme, të mbrojtura, një nga aplikimet më të zakonshme praktike të Redis përveç cache-it.