Hogyan előzöd meg a deadlockokat többezer konkurens tranzakcióval?

Question

IT Interview Practice · Accepted Answer

**Szerezz meg lockokat egy konzisztens globális sorrendben, tartsd rövidnek a tranzakciókat, csökkentsd az izolációt, ahol biztonságos, és próbáld újra a vesztest, amikor egy deadlock mégis megtörténik.** Egy deadlock egy ciklus: az A tranzakció tartja az 1-es sort és a 2-esre vár, míg a B tartja a 2-es sort és az 1-esre vár — egyik sem tud haladni, ezért a DB megöli az egyiket.

## A ciklus, amit meg kell törnöd

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

## Stratégiák

- **Konzisztens lock sorrend.** Ha minden tranzakció mindig ugyanabban a sorrendben lockolja a sorokat (pl. növekvő elsődleges kulcs), egy ciklus lehetetlen — A és B is előbb ragadja meg az 1-es sort, így az egyik egyszerűen vár. Ez az egyetlen legnagyobb kar. Egy klasszikus bug: egy pénzutalás, amely `(from, to)` sorrendben lockol számlákat, deadlockol a fordított utalással; mindig lockolj `min(id), max(id)` szerint.
- **Rövid tranzakciók.** Tartsd a lockokat a lehető legrövidebb ideig — végezz validációt, hálózati hívásokat és olvasásokat a `BEGIN` **előtt**, majd lockolj, írj és `COMMIT`-olj gyorsan. A hosszú tranzakciók kiszélesítik az ablakot a ciklusokra és lock várakozásokra.
- **Csökkentsd az izolációt, ahol biztonságos.** A `SERIALIZABLE` több/tartomány lockot vesz és többet deadlockol; a `READ COMMITTED` (Postgres default) kevesebbet lockol. Használd a leggyengébb izolációt, ami még kielégíti a helyességet.
- **Retry deadlockon.** A deadlockok átmenetiek. Kapd el a deadlock hibát (Postgres `40P01`, MySQL `1213`) és próbáld újra az egész tranzakciót kis backoffal. Némi versengés elkerülhetetlen méretben, ezért a retry egy biztonsági háló, nem a sorrend helyettesítője.

## Interjú szemszög

Az interjúztató azt ellenőrzi, tudod-e, hogy a deadlockok **tervezéssel megelőzhetők, nem csak elkaphatók**. Csak a "retry" megnevezése gyenge válasz — a kiváló válasz a **konzisztens lock sorrenddel** és a **rövid tranzakciókkal** vezet, majd hozzáadja a retryt a maradékhoz. Gyakori csapda: azt feltételezni, hogy az appnak kell detektálnia a deadlockokat; a gyakorlatban a **DB detektálja a ciklust és megszakít egy áldozatot** helyetted — a te dolgod a sorrend plusz egy retry ciklus.

**Kompromisszumok:** a szigorú sorrend nehéz lehet, amikor a hozzáférési minták dinamikusak vagy táblákat ölelnek át; az alacsonyabb izoláció anomáliákat kockáztat (non-repeatable read), amiket át kell gondolnod. A retry ciklusoknak **idempotenseknek** és korlátozottaknak kell lenniük, különben egy forró konfliktus retry viharrá válik. A deadlock-megelőzés valójában lock-fegyelem plusz egy korlátozott retry, nem egyetlen ezüstgolyó.

A ciklus, amit meg kell törnöd

Stratégiák

Interjú szemszög

Kapcsolódó kérdések