Hvordan fungerer distribuerede låse med Redis?

Question

Accepted Answer

En **distribueret lås** koordinerer adgang til en delt ressource på tværs af flere processer/servere, så kun én holder låsen ad gangen. Redis bruges almindeligt til dette via atomisk set-if-not-exists med en TTL — selvom det kræver omhu at gøre det korrekt (og forståelse af begrænsningerne).

## En grundlæggende 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åsen bruger **`SET key value NX EX`**: atomisk indstilling af nøglen kun hvis absent (så kun én klient lykkes) med en **TTL** (så låsen frigives automatisk hvis holderen går ned, hvilket undgår deadlock).

## To kritiske korrekthedskriterier

```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ænsninger og 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.
```

## Hvorfor det betyder noget

Forståelse af distribuerede låse med Redis er værdifuld for **at koordinere adgang til delte ressourcer** på tværs af distribuerede systemer, så det er nyttig viden — og forståelse af korrekthedsfaldgruber er især vigtig.

Distribuerede låse løser et reelt behov: sikre at kun én proces/server udfører en kritisk handling ad gangen (forhindring af duplikeret behandling, race conditions på delte ressourcer eller modstridende operationer) i systemer med flere servere, og Redis er et almindeligt værktøj til dette.

Forståelse af **grundmekanismen** — `SET key value NX EX` (atomisk set-if-not-exists med en TTL) så kun én klient erhverver låsen og den frigives automatisk ved nedbrud — er den grundlæggende teknik.

Kritisk er forståelsen af **de to korrekthedskriterier** væsentlig: **altid bruge en TTL** (så en nedstyret holders lås udløber automatisk, hvilket undgår permanent deadlock) og **bruge en unik token med matchet frigivelse** (så du ikke frigiver en anden klients lås ved et uheld, hvis din TTL udløb — med atomisk check-then-delete via et Lua-script).

Disse detaljer er der, hvor naive implementeringer har subtile, farlige fejl.

Essentielt vigtigt er også at forstå **begrænsningerne**: en enkelt Redis-lås er ikke fuldstændig sikker (TTL-udløb midt i arbejdet eller failover kan lade to klienter holde den), hvilket fører til **Redlock**-algoritmen (erhvervelse på tværs af flere Redis-noder) for stærkere garantier — og at vide, at for kritisk korrekthed kan fencing-tokens eller konsensussystemer (ZooKeeper/etcd) være nødvendige.

Denne bevidsthed om afvejninger og begrænsninger afspejler moden forståelse.

Da koordinering af delt-ressource-adgang i distribuerede systemer er et reelt behov, og da Redis distribuerede låse er almindelige, men kræver omhyggelig korrekt implementering (TTL, unik token, atomisk frigivelse) og bevidsthed om deres begrænsninger (Redlock, failover-risici), er forståelse af distribuerede låse med Redis — mekanismen, korrekthedskriteriet og begrænsningerne — værdifuld, praktisk relevant viden for distribueret koordinering, et emne hvor forståelse af faldgruber og afvejninger er lige så vigtig som den grundlæggende teknik.