Kaip veikia paskirstyti užrakinimas su Redis?

Question

Accepted Answer

A **paskirstytas užrakinimas** koordinuoja prieigą prie bendro ištekliaus keliuose procesų/serveriuose taip, kad vienas metas jį draudžiamą. Redis dažniausiai naudojamas šiam tikslui per atominį nustatymą-jei-neegzistuoja su TTL — nors teisingam diegimui reikalingas dėmesys (ir suprasti apribojimus).

## Pagrindinis Redis užrakinimas (SET NX su 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);
  }
}
```

Užrakinimas naudoja **`SET key value NX EX`**: atomiškai nustatyti raktą tik jei jo nėra (todėl tik vienas klientas pasiseka) su **TTL** (todėl užrakinimas automatiškai atleidžiamas, jei turėtojas nutrūksta, vengiant aklavietės).

## Du kritiniai teisingos veiklos detalės

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

## Apribojimai ir 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.
```

## Kodėl tai svarbu

Suprasti paskirstytą užrakinimą su Redis yra vertinga **koordinuojant prieigą prie bendro ištekliaus** keliose sistemose, todėl tai naudinga žinia — ir suprasti teisingumo spąstus ypač svarbu.

Paskirstyti užrakinai išsprendžia realią problemą: užtikrinti, kad tik vienas procesas/serveris atliks kritinį veiksmą vienu metu (prevencinėmis pasikartojančio apdorojimo, lenktynių sąlygų dėl bendro ištekliaus arba konfliktinių operacijų) kelių serverių sistemose, o Redis yra dažnas šio įrankis.

Suprasti **pagrindinį mechanizmą** — `SET key value NX EX` (atomiškas nustatymas-jei-neegzistuoja su TTL) taip, kad tik vienas klientas įgyja užrakinimą ir jis automatiškai atleidžiamas nutrūkus — yra pagrindinis metodas.

Kritiškai, suprasti **du teisingos veiklos detalės** yra būtina: **visada naudoti TTL** (taip nutrūkęs turėtojas užrakinimas automatiškai baigiasi, vengiant nuolatinės aklavietės) ir **naudoti unikalų žetoną su sutampančiu atleimimu** (taip nesuklysti per atsitiktį neatleisite kito kliento užrakinimo, jei jūsų TTL baigėsi — su atominiu tikrinimu-tada-triniu per Lua scenarijų).

Šios detalės yra vietos, kuriose kvailos realizacijos turi subtilūs, pavojingus klaidas.

Taip pat svarbu suprasti **apribojimus**: vieno Redis užrakinimas nėra visiškai saugus (TTL pabaiga viduryje darbo arba persigrupavimy gali leisti dviem klientams jį turėti), vedant prie **Redlock** algoritmo (įsigijimas keliuose Redis mazguose) stipresnėms garantijoms — ir žinant, kad svarbioms teisingoms veikloms, aptvėrimo žetonai arba sutarimo sistemos (ZooKeeper/etcd) gali būti reikalingi.

Šitas įmonės žinojimas apie sumaišymą ir apribojimus atspindi subrendusį supratimą.

Nes koordinavimas bendro ištekliaus prieigos paskirstytose sistemose yra tikra poreikis, ir nuo tada Redis paskirstyti užrakinai yra plačiai naudojami, bet reikalingas atsargus teisingas diegimas (TTL, unikalus žetonas, atomiškas atleidimas) ir teisingos veiklos apribojimų žinojimas (Redlock, persigrupavimy rizikos), suprasti paskirstytą užrakinimą su Redis — mechanizmą, teisingos veiklos detales ir apribojimus — yra vertinga, praktiškai aktuali žinia paskirstytos koordinacijos, tema kurioje supratimas spąstų ir sumaišymo yra toks pat svarbus, kaip ir pagrindinis metodas.