Wie funktionieren verteilte Sperren mit Redis?

Question

Accepted Answer

Eine **verteilte Sperre** koordiniert den Zugriff auf eine gemeinsame Ressource über mehrere Prozesse/Server hinweg, sodass jeweils nur einer die Sperre hält. Redis wird häufig dafür verwendet, indem atomare Set-If-Not-Exists-Operationen mit einer TTL kombiniert werden – die korrekte Implementierung erfordert jedoch Sorgfalt und Verständnis der Einschränkungen.

## Eine einfache Redis-Sperre (SET NX mit 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);
  }
}
```

Die Sperre verwendet **`SET key value NX EX`**: setzt den Schlüssel atomar nur, wenn er nicht vorhanden ist (sodass nur ein Client erfolgreich ist) mit einer **TTL** (sodass die Sperre automatisch freigegeben wird, wenn der Halter abstürzt und einen Deadlock vermeidet).

## Zwei kritische Korrektheit-Details

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

## Einschränkungen und 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.
```

## Warum es wichtig ist

Das Verständnis von verteilten Sperren mit Redis ist wertvoll für die **Koordination des Zugriffs auf gemeinsame Ressourcen** über verteilte Systeme hinweg, daher ist es nützliches Wissen – und das Verständnis der Korrektheitsfallen ist besonders wichtig.

Verteilte Sperren adressieren ein echtes Problem: Sicherstellen, dass nur ein Prozess/Server eine kritische Aktion gleichzeitig durchführt (Vermeidung von doppelter Verarbeitung, Racebedingungen auf gemeinsamen Ressourcen oder widersprüchlichen Operationen) in Multi-Server-Systemen, und Redis ist ein häufiges Werkzeug dafür.

Das Verständnis des **grundlegenden Mechanismus** – `SET key value NX EX` (atomare Set-If-Not-Exists mit einer TTL), sodass nur ein Client die Sperre erwirbt und sie bei einem Absturz automatisch freigegeben wird – ist die fundamentale Technik.

Kritisch ist das Verständnis der **zwei Korrektheit-Details**: **immer eine TTL verwenden** (sodass die Sperre eines abgestürzten Halters automatisch abläuft, was permanente Deadlocks vermeidet) und **ein eindeutiges Token mit angepasster Freigabe verwenden** (sodass Sie versehentlich nicht die Sperre eines anderen Clients freigeben, falls Ihre TTL abgelaufen ist – mit atomarer Check-Then-Delete über ein Lua-Skript).

An diesen Details haben naive Implementierungen subtile, gefährliche Fehler.

Ebenso wichtig ist das Verständnis der **Einschränkungen**: Eine Single-Redis-Sperre ist nicht perfekt sicher (TTL-Ablauf während der Arbeit oder Failover können zwei Clients ermöglichen, die Sperre zu halten), was zum **Redlock**-Algorithmus führt (Akquisition über mehrere Redis-Knoten) für stärkere Garantien – und das Wissen, dass für kritische Korrektheit Fencing-Tokens oder Consensus-Systeme (ZooKeeper/etcd) erforderlich sein können.

Dieses Bewusstsein für Trade-offs und Einschränkungen spiegelt reifes Verständnis wider.

Da die Koordination des Zugriffs auf gemeinsame Ressourcen in verteilten Systemen ein echtes Problem ist und da Redis-Sperren häufig vorkommen, aber eine sorgfältige korrekte Implementierung (TTL, eindeutiges Token, atomare Freigabe) und Bewusstsein für ihre Einschränkungen (Redlock, Failover-Risiken) erfordern, ist das Verständnis von verteilten Sperren mit Redis – der Mechanismus, die Korrektheit-Details und die Einschränkungen – wertvoll und praktisch relevantes Wissen für verteilte Koordination, ein Thema, wo das Verständnis der Fallstricke und Trade-offs genauso wichtig ist wie die grundlegende Technik.