Si funksionojnë kyçet e shpërndarë me Redis?

Question

Accepted Answer

Një **kyç i shpërndarë** koordinon aksesin në një burim të ndarë në shumë procese/shërbime në mënyrë që vetëm njëri të mbajë kyçin në një kohë. Redis përdoret zakonisht për këtë përmes vendosjes atomike nëse nuk ekziston me një TTL — megjithëse ta bësh atë në mënyrë korrekte kërkon kujdes (dhe kuptim të kufizimeve).

## Një kyç bazik Redis (SET NX me TTL)

```js
// acquire: SET the lock key only if it doesn't exist, with a TTL (auto-release safety)
const token = randomUUID();   // a unique token identifying THIS lock holder
const acquired = await redis.set("lock:resource", token, "NX", "EX", 30);
// NX = set only if not exists (atomic); EX 30 = auto-expire in 30s (avoid deadlock)

if (acquired) {
  try {
    // ... do the work that needs exclusive access ...
  } finally {
    // release ONLY if WE still hold it (check the token) — use a Lua script for atomicity
    await releaseLock("lock:resource", token);
  }
}
```

Kyçi përdor **`SET key value NX EX`**: vendos atomikisht kyçin vetëm nëse nuk ekziston (kështu vetëm një klient arrin të ketë sukses) me një **TTL** (kështu kyçi lirohet automatikisht nëse mbajtësi i tij bie, duke shmangur bllokimin përgjithmonë).

## Dy detaje kritike korrektësie

```text
1. ALWAYS set a TTL → if the lock holder crashes, the lock auto-expires
   (otherwise the resource is locked forever — a deadlock)
2. Use a UNIQUE TOKEN + release only if it matches → so you don't release
   SOMEONE ELSE'S lock (e.g. if your TTL expired and another client acquired it).
   Release must be ATOMIC (check-token-then-delete via a Lua script).
```

```lua
-- safe release: delete only if the value matches our token (atomic via Lua)
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end
```

## Kufizime dhe Redlock

```text
⚠️ A single-Redis lock isn't perfectly safe: if the TTL expires mid-work, or with
   failover (the lock not yet replicated), two clients could both hold it.
→ REDLOCK algorithm → acquire the lock across MULTIPLE independent Redis nodes
   (majority) for stronger guarantees (though even Redlock is debated).
→ For critical correctness, combine with fencing tokens or use a system designed for
   consensus (e.g. ZooKeeper/etcd). Know the trade-offs.
```

## Përse ka rëndësi

Kuptimi i kyçeve të shpërndarë me Redis është i vlefshëm për **koordinimin e aksesit në burime të ndarë** në sistemet e shpërndara, kështu që është njohuri e dobishme — dhe kuptimi i gracave të korrektësisë është veçanërisht i rëndësishëm.

Kyçet e shpërndarë zgjidhin një nevojë reale: të siguroheni që vetëm një proces/shërbim kryen një veprim kritik në një kohë (duke parandaluar përpunimin e dyfishtë, garat në burime të ndarë, ose veprime konfliktuale) në sistemet me shumë shërbime, dhe Redis është një mjet i zakonshëm për këtë.

Kuptimi i **mekanizmit bazik** — `SET key value NX EX` (vendosje atomike nëse nuk ekziston me një TTL) kështu që vetëm një klient përfton kyçin dhe ai lirohet automatikisht në rast rrëzimi — është teknika themelore.

Cështu, kuptimi i **dy detajeve të korrektësisë** është thelbësor: **gjithmonë përdorimi i një TTL** (kështu që kyçi i një mbajtësi që bie bie automatikisht, duke shmangur bllokimin përgjithmonë) dhe **përdorimi i një token unik me lirimin e përputhur** (kështu që nuk liron aksidentalisht kyçin e një klienti tjetër nëse TTL juaj ka përfunduar — me kontroll-pastaj-fshirje atomike përmes skripti Lua).

Këto detaje janë aty ku implementimet naive kanë gabime delikate, të rrezikshme.

Njësoj i rëndësishëm është kuptimi i **kufizimeve**: një kyç i vetëm-Redis nuk është krejtësisht i sigurt (skadimi i TTL në mes të punës ose kalimi mund t'u lejojë dy klientëve ta mbajnë atë), duke çuar në algoritmin **Redlock** (përftimi në shumë nyje Redis) për garansi më të forta — dhe dije se për korrektësinë kritike, token-at rrethimi ose sistemet e konsensusit (ZooKeeper/etcd) mund të jenë të nevojshëm.

Ky kesencim i kompromiseve dhe kufizimeve pasqyron kuptim të pjekur.

Meqenëse koordinimi i aksesit në burime të ndarë në sistemet e shpërndara është një nevojë reale, dhe meqenëse kyçet e shpërndarë Redis janë të zakonshëm por kërkojnë zbatim të korrekt të kujdesit (TTL, token unik, lirimi atomik) dhe kesencim të kufizimeve të tyre (Redlock, rreziqet e kalimit), kuptimi i kyçeve të shpërndarë me Redis — mekanizmi, detajat e korrektësisë, dhe kufizime — është njohuri e vlefshme, praktikisht relevante për koordinimin e shpërndarë, një temë ku kuptimi i gracave dhe kompromiseve është po aq i rëndësishëm sa teknika bazike.