Hur fungerar distribuerade lås med Redis?

Question

Accepted Answer

Ett **distribuerat lås** samordnar åtkomst till en delad resurs över flera processer/servrar så att endast en innehar låset åt gången. Redis används vanligtvis för detta via atomär set-if-not-exists med en TTL — men att göra det korrekt kräver omsorg (och förståelse för begränsningarna).

## Ett grundläggande Redis-lås (SET NX med 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);
  }
}
```

Låset använder **`SET key value NX EX`**: atomärt ställ in nyckeln endast om den inte finns (så endast en klient lyckas) med en **TTL** (så låset frigörs automatiskt om innehavaren kraschar, vilket undviker deadlock).

## Två kritiska korrektnesdetaljer

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

## Begränsningar och 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.
```

## Varför det är viktigt

Att förstå distribuerade lås med Redis är värdefullt för **att samordna åtkomst till delade resurser** över distribuerade system, så det är användbar kunskap — och att förstå korrekthetsfällorna är särskilt viktigt.

Distribuerade lås löser ett verkligt behov: att säkerställa att endast en process/server utför en kritisk åtgärd åt gången (vilket förhindrar duplicerad bearbetning, race conditions på delade resurser eller motstridiga operationer) i multi-server-system, och Redis är ett vanligt verktyg för detta.

Att förstå **den grundläggande mekanismen** — `SET key value NX EX` (atomär set-if-not-exists med en TTL) så att endast en klient förvärvar låset och det frigörs automatiskt vid krascher — är den grundläggande tekniken.

Kritiskt är det att förstå **de två korrektnesdetaljerna**: **använd alltid en TTL** (så ett krascht innehavarelås upphör automatiskt, vilket undviker permanent deadlock) och **använd en unik token med matchad frigivning** (så du inte av misstag frigör en annan klients lås om din TTL upphörde — med atomär check-then-delete via ett Lua-skript).

Dessa detaljer är där naiva implementeringar har subtila, farliga buggar.

Lika viktig är att förstå **begränsningarna**: ett enkelt Redis-lås är inte perfekt säkert (TTL-upphörande under arbete eller failover kan låta två klienter inneha det), vilket leder till **Redlock**-algoritmen (förvärv över flera Redis-noder) för starkare garantier — och att veta att för kritisk korrekthet kan fencing tokens eller konsensussystem (ZooKeeper/etcd) behövas.

Den här medvetenheten om avvägningarna och begränsningarna återspeglar mogen förståelse.

Eftersom samordning av delad-resursåtkomst i distribuerade system är ett verkligt behov, och eftersom distribuerade Redis-lås är vanliga men kräver noggrann korrekt implementering (TTL, unik token, atomär frigivning) och medvetenhet om deras begränsningar (Redlock, failover-risker), är förståelse för distribuerade lås med Redis — mekanismen, korrektnesdetaljerna och begränsningarna — värdefull, praktiskt relevant kunskap för distribuerad samordning, ett område där förståelse för fallgroparna och avvägningarna är lika viktig som den grundläggande tekniken.