Jak předejdete deadlockům při tisících souběžných transakcí?

Question

IT Interview Practice · Accepted Answer

**Získávejte zámky v konzistentním globálním pořadí, držte transakce krátké, snižte isolation tam, kde je to bezpečné, a retryujte poraženého, když deadlock přesto nastane.** Deadlock je cyklus: transakce A drží řádek 1 a čeká na řádek 2, zatímco B drží řádek 2 a čeká na řádek 1 — ani jedna nemůže pokračovat, takže DB jednu zabije.

## Cyklus, který musíte přerušit

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

## Strategie

- **Konzistentní pořadí zámků.** Pokud každá transakce vždy zamyká řádky ve stejném pořadí (např. vzestupně podle primárního klíče), cyklus je nemožný — A i B nejdřív chytnou řádek 1, takže jedna prostě čeká. To je jediná největší páka. Klasický bug: převod peněz, který zamyká účty v pořadí `(from, to)`, deadlockuje s opačným převodem; vždy zamykejte podle `min(id), max(id)`.
- **Krátké transakce.** Držte zámky co nejkratší dobu — validaci, síťová volání a čtení dělejte **před** `BEGIN`, pak rychle zamkněte, zapište a `COMMIT`. Dlouhé transakce rozšiřují okno pro cykly a lock waity.
- **Snižte isolation tam, kde je to bezpečné.** `SERIALIZABLE` bere víc/range zámků a deadlockuje víc; `READ COMMITTED` (Postgres default) zamyká méně. Použijte nejslabší isolation, který stále splňuje správnost.
- **Retry při deadlocku.** Deadlocky jsou přechodné. Zachyťte deadlock chybu (Postgres `40P01`, MySQL `1213`) a retryujte celou transakci s malým backoffem. Nějaká contention je při měřítku nevyhnutelná, takže retry je záchranná síť, ne náhrada za pořadí.

## Pohled z pohovoru

Tazatel ověřuje, zda víte, že deadlockům se **předchází designem, nejen se chytají**. Pojmenovat jen „retry“ je slabá odpověď — skvělá odpověď vede **konzistentním pořadím zámků** a **krátkými transakcemi**, pak přidá retry na zbytek. Častá past: předpokládat, že aplikace musí detekovat deadlocky; v praxi **DB detekuje cyklus a zruší oběť** za vás — vaší úlohou je pořadí plus retry smyčka.

**Kompromisy:** striktní pořadí může být těžké, když jsou přístupové vzory dynamické nebo klenou tabulky; nižší isolation riskuje anomálie (non-repeatable reads), o kterých musíte uvažovat. Retry smyčky musí být **idempotentní** a omezené, jinak se z hot konfliktu stane retry storm. Prevence deadlocků je vlastně lock-disciplína plus omezený retry, ne jedna stříbrná kulka.

Cyklus, který musíte přerušit

Strategie

Pohled z pohovoru

Související otázky