Wie funktionieren Redis-Transaktionen?

Question

Accepted Answer

Redis **Transaktionen** (via `MULTI`/`EXEC`) fassen mehrere Befehle zusammen, um sie **atomar** auszuführen — alle zusammen ohne Verschachtelung durch andere Befehle. In Kombination mit `WATCH` für optimistische Sperrung behandeln sie Szenarien, die mehrere konsistente Operationen erfordern. Redis-Transaktionen unterscheiden sich in wichtigen Punkten von SQL-Transaktionen.

## MULTI / EXEC — Queuing und atomare Ausführung

```bash
MULTI                  # start a transaction (begin queuing commands)
SET account:1 100      # QUEUED (not executed yet)
SET account:2 200      # QUEUED
INCR counter           # QUEUED
EXEC                   # execute ALL queued commands atomically (as one unit)
# → all commands run together, with NO other client's commands in between
```

`MULTI` startet das Queuing von Befehlen; `EXEC` führt sie alle atomar aus (keine Verschachtelung von anderen Clients). `DISCARD` bricht eine warteschlangige Transaktion ab.

## WATCH — optimistische Sperrung (Check-and-Set)

```bash
# WATCH a key; if it CHANGES before EXEC, the transaction ABORTS (returns nil)
WATCH balance
val = GET balance              # read the current value
MULTI
SET balance (val - 100)        # modify based on what we read
EXEC                           # → if "balance" changed since WATCH, EXEC fails (returns nil)
# → retry the whole thing if it failed (optimistic concurrency control)
```

`WATCH` bietet **optimistische Sperrung**: Wenn ein überwachter Schlüssel vor `EXEC` von einem anderen Client modifiziert wird, bricht die Transaktion ab — was es dir ermöglicht, sicher Check-then-Set-Operationen durchzuführen (bei Konflikt erneut versuchen).

## Wie sich Redis-Transaktionen von SQL UNTERSCHEIDEN

```text
⚠️ Redis transactions are NOT like SQL transactions:
  ✗ NO ROLLBACK — if a command fails at EXEC time, OTHER commands still execute
    (errors don't roll back the transaction; Redis doesn't undo). Only syntax errors
    before EXEC abort the whole thing.
  ✓ Atomicity = commands run together without interleaving (isolation), NOT all-or-nothing
    with rollback on error.
→ Often Lua SCRIPTS are used instead for complex atomic logic (a script runs atomically).
```

## Warum es wichtig ist

Das Verständnis von Redis-Transaktionen ist wertvoll für **die konsistente Ausführung mehrerer Operationen**, daher ist es nützliches Wissen — und das Verständnis, wie sie sich von SQL-Transaktionen unterscheiden, ist besonders wichtig, um falsche Annahmen zu vermeiden.

Die Kernfunktion — `MULTI`/`EXEC` gruppiert Befehle für **atomare Ausführung** (alle zusammen, ohne dass Befehle von anderen Clients verschachtelt werden) — adressiert Szenarien, in denen mehrere Operationen als konsistente Einheit erfolgen müssen.

Der **`WATCH`**-Mechanismus bietet **optimistische Sperrung** (Check-and-Set): Die Transaktion wird abgebrochen, wenn sich ein überwachter Schlüssel vor `EXEC` geändert hat, was sichere Check-then-Modify-Operationen ermöglicht (wie das Verringern eines Guthaben basierend auf seinem aktuellen Wert) mit Wiederholung bei Konflikt — wichtig für korrekte nebenläufige Operationen.

Der **kritischste Punkt** ist das Verständnis, wie sich Redis-Transaktionen **von SQL-Transaktionen unterscheiden**: Redis hat **kein Rollback** — wenn ein Befehl bei `EXEC` fehlschlägt, führen die anderen Befehle trotzdem aus (Redis macht nichts rückgängig), daher bedeutet „Atomarität