Wie verhinderst du Deadlocks bei Tausenden gleichzeitiger Transaktionen?

Question

IT Interview Practice · Accepted Answer

**Erwirb Locks in einer konsistenten globalen Reihenfolge, halte Transaktionen kurz, senke die Isolation dort, wo es sicher ist, und wiederhole den Verlierer, wenn dennoch ein Deadlock auftritt.** Ein Deadlock ist ein Zyklus: Transaktion A hält Row 1 und wartet auf Row 2, während B Row 2 hält und auf Row 1 wartet - keine kann fortfahren, also killt die DB eine.

## Der Zyklus, den du brechen musst

```text
   Tx A                              Tx B
   holds row 1  ──── waits ────▶ row 2 (held by B)
        ▲                              │
        │ waits                        │ holds
        └────────── row 1 ◀────────────┘
                (cycle = deadlock; DB aborts one victim)
```

## Strategien

- **Konsistente Lock-Reihenfolge.** Wenn jede Transaktion Rows immer in derselben Reihenfolge lockt (z. B. aufsteigender Primary Key), ist ein Zyklus unmöglich - A und B greifen beide zuerst Row 1, sodass eine einfach wartet. Das ist der größte einzelne Hebel. Ein klassischer Bug: eine Geldüberweisung, die Konten in `(from, to)`-Reihenfolge lockt, deadlockt mit der umgekehrten Überweisung; locke immer nach `min(id), max(id)`.
- **Kurze Transaktionen.** Halte Locks so kurz wie möglich - mache Validierung, Netzwerkaufrufe und Reads **vor** `BEGIN`, dann locke, schreibe und `COMMIT` schnell. Lange Transaktionen weiten das Fenster für Zyklen und Lock-Waits.
- **Isolation senken, wo sicher.** `SERIALIZABLE` nimmt mehr/Range-Locks und deadlockt öfter; `READ COMMITTED` (Postgres-Default) lockt weniger. Nutze die schwächste Isolation, die noch die Korrektheit erfüllt.
- **Retry bei Deadlock.** Deadlocks sind transient. Fange den Deadlock-Fehler (Postgres `40P01`, MySQL `1213`) und wiederhole die ganze Transaktion mit kleinem Backoff. Etwas Contention ist bei Skalierung unvermeidbar, also ist Retry ein Sicherheitsnetz, kein Ersatz für Ordering.

## Interview-Perspektive

Der Interviewer prüft, ob du weißt, dass Deadlocks **durch Design verhindert werden, nicht nur gefangen**. Allein "Retry" zu benennen ist eine schwache Antwort - die hervorragende Antwort führt mit **konsistenter Lock-Reihenfolge** und **kurzen Transaktionen** und ergänzt dann Retry für den Rest. Eine häufige Falle: anzunehmen, die App müsse Deadlocks erkennen; in der Praxis **erkennt die DB den Zyklus und bricht ein Opfer ab** für dich - deine Aufgabe ist Ordering plus eine Retry-Schleife.

**Trade-offs:** Strikte Reihenfolge kann schwer sein, wenn Zugriffsmuster dynamisch sind oder über Tabellen spannen; niedrigere Isolation riskiert Anomalien (Non-repeatable Reads), über die du nachdenken musst. Retry-Schleifen müssen **idempotent** und gedeckelt sein, sonst wird aus einem heißen Konflikt ein Retry-Sturm. Deadlock-Prävention ist eigentlich Lock-Disziplin plus ein begrenztes Retry, keine einzelne Wunderwaffe.

Der Zyklus, den du brechen musst

Strategien

Interview-Perspektive

Ähnliche Fragen