Jak fungují distribuované zámky s Redisem?

Question

Accepted Answer

**Distribuovaný zámek** koordinuje přístup ke sdílenému prostředku mezi více procesy/servery tak, aby jej v jednom okamžiku držel pouze jeden. Redis se pro tento účel běžně používá prostřednictvím atomické operace set-if-not-exists s TTL — správná implementace však vyžaduje pozornost (a pochopení omezení).

## Základní Redis zámek (SET NX s 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);
  }
}
```

Zámek používá **`SET key value NX EX`**: atomicky nastaví klíč pouze pokud neexistuje (takže zámek získá pouze jeden klient) s **TTL** (zámek se tak automaticky uvolní, pokud by držitel spadl, čímž se zabrání zablokování).

## Dva kritické detaily korektnosti

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

## Omezení a 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.
```

## Proč je to důležité

Pochopení distribuovaných zámků s Redisem je cenné pro **koordinaci přístupu ke sdíleným prostředkům** v distribuovaných systémech, takže jde o užitečné znalosti — a pochopení chybových scénářů je obzvláště důležité.

Distribuované zámky řeší skutečnou potřebu: zajistit, aby pouze jeden proces/server provedl kritickou akci najednou (zabránit duplikátnímu zpracování, race conditions na sdílených prostředcích nebo konfliktním operacím) v multi-serverových systémech, a Redis je pro tento účel běžně používaným nástrojem.

Pochopení **základního mechanismu** — `SET key value NX EX` (atomické set-if-not-exists s TTL), takže zámek získá pouze jeden klient a automaticky se uvolní při pádu — je základní technika.

Kriticky je nezbytné pochopit **dva detaily korektnosti**: **vždy používat TTL** (aby zámek pádu držitele automaticky vypršel a zabránilo se trvalému zablokování) a **používat jedinečný token se spárovaným uvolněním** (abyste nechtěně neuvolnili zámek jiného klienta, pokud vám vypršela TTL — pomocí atomické operace check-then-delete přes Lua skript).

V těchto detailech se skrývají jemné a nebezpečné chyby v naivních implementacích.

Ekvivalentně důležité je pochopení **omezení**: single-Redis zámek není dokonale bezpečný (vypršení TTL uprostřed práce nebo failover mohou umožnit dvěma klientům jeho držení), což vede k algoritmu **Redlock** (získání zámku přes více Redis uzlů) pro silnější záruky — a vědomí, že pro kritickou korektnost mohou být potřeba fencing tokeny nebo systémy konsenzu (ZooKeeper/etcd).

Tato povědomost o trade-offs a omezeních odráží zralé pochopení.

Jelikož koordinace přístupu ke sdíleným prostředkům v distribuovaných systémech je skutečná potřeba, a jelikož distribuované zámky s Redisem jsou běžné, ale vyžadují pečlivou správnou implementaci (TTL, jedinečný token, atomické uvolnění) a povědomí o jejich omezeních (Redlock, failover rizika), je pochopení distribuovaných zámků s Redisem — mechanismu, detailů korektnosti a omezení — cenné, prakticky relevantní znalosti pro distribuovanou koordinaci, oblast, kde je pochopení chybových scénářů a trade-offs stejně důležité jako samotná základní technika.