Kif jaħdmu l-locks distribwiti ma' Redis?

Question

Accepted Answer

A **distributed lock** jikkoordina l-aċċess għal risorsa maqsuma fuq prosessi/servers multipli sabiex biss wieħed iġġie jixgħel il-lock f'ħin wieħed. Redis huwa komunement użat għal dan permezz ta' set atomiku-jekk-ma-jeżistix ma' TTL — għalkemm li tgħallem daqq jirrikjedi ħsieb (u fehim tal-limitazzjonijiet).

## A lock bażiku ta' Redis (SET NX ma' 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);
  }
}
```

Il-lock juża **`SET key value NX EX`**: atomikament issettja l-key biss jekk m'hemmx (sabiex biss klient wieħed jirnexxu) ma' **TTL** (sabiex il-lock jiġi liberalizzat awtomatikament jekk il-holder jikraxxa, u evita deadlock).

## Żewġ dettall kritiku tal-korrettezza

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

## Limitazzjonijiet u 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.
```

## Għaliex għandu importanza

Li tifhem distributed locks ma' Redis hija ta' valur għal **jikkoordina l-aċċess għal risorsi maqsuma** fuq sistemi distribwiti, sabiex hija ħaġa ta' għarfien utli — u li tifhem il-pitfalls tal-korrettezza hija partikolarment importanti.

Distributed locks jittrattaw bżonn reali: li jiżguraw biss prosess/server wieħed jwettaq azzjoni kritika f'ħin wieħed (li jipprievieni l-ipprċessar doppju, race conditions fuq risorsi maqsuma, jew operazzjonijiet li jikkonfliktwaw) f'sistemi multi-server, u Redis hija ferramenta komuni għal dan.

Li tifhem il-**mekkaniżmu bażiku** — `SET key value NX EX` (atomic set-if-not-exists ma' TTL) sabiex biss klient wieħed ineħel il-lock u jiġi liberalizzat awtomatikament fuq crash — hija t-teknika fundamentali.
"]}}}}