Kako preprečite mrtve zanke (deadlocks) pri tisočih sočasnih transakcij?

Question

IT Interview Practice · Accepted Answer

**Pridobivajte locke v konsistentnem globalnem vrstnem redu, ohranjajte transakcije kratke, znižajte izolacijo, kjer je varno, in ponovite poraženca, ko do deadlocka vseeno pride.** Deadlock je cikel: transakcija A drži vrstico 1 in čaka na vrstico 2, medtem ko B drži vrstico 2 in čaka na vrstico 1 — nobena ne more napredovati, zato DB ubije eno.

## Cikel, ki ga morate prekiniti

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

## Strategije

- **Konsistenten vrstni red zaklepanja.** Če vsaka transakcija vedno zaklepa vrstice v istem vrstnem redu (npr. naraščajoč primarni ključ), je cikel nemogoč — A in B obe najprej zgrabita vrstico 1, tako da ena preprosto čaka. To je največji posamezni vzvod. Klasična napaka: denarni prenos, ki zaklepa račune v vrstnem redu `(from, to)`, deadlocka z obratnim prenosom; vedno zaklepajte po `min(id), max(id)`.
- **Kratke transakcije.** Držite locke kar najkrajši čas — opravite validacijo, mrežne klice in branja **pred** `BEGIN`, nato zaklenite, zapišite in hitro `COMMIT`-ajte. Dolge transakcije širijo okno za cikle in čakanja na locke.
- **Znižajte izolacijo, kjer je varno.** `SERIALIZABLE` jemlje več/obsegovne (range) locke in bolj deadlocka; `READ COMMITTED` (Postgres privzeto) zaklepa manj. Uporabite najšibkejšo izolacijo, ki še ustreza pravilnosti.
- **Ponovni poskus ob deadlocku.** Deadlocki so prehodni. Ujemite napako deadlocka (Postgres `40P01`, MySQL `1213`) in ponovite celotno transakcijo z majhnim odmikom (backoff). Nekaj tekmovanja je v obsegu neizogibnega, zato je ponovni poskus varnostna mreža, ne nadomestek za urejanje.

## Pogled s stališča razgovora

Izpraševalec preverja, ali veste, da se deadlocki **preprečujejo z zasnovo, ne le lovijo**. Poimenovanje samo "ponovni poskus" je šibek odgovor — odličen odgovor vodi s **konsistentnim vrstnim redom zaklepanja** in **kratkimi transakcijami**, nato doda ponovni poskus za preostanek. Pogosta past: domneva, da mora aplikacija zaznati deadlocke; v praksi **DB zazna cikel in prekine žrtev** namesto vas — vaše delo je urejanje plus zanka ponovnih poskusov.

**Kompromisi:** strogo urejanje je lahko težko, ko so vzorci dostopa dinamični ali se raztezajo čez tabele; nižja izolacija tvega anomalije (neponovljiva branja), o katerih morate sklepati. Zanke ponovnih poskusov morajo biti **idempotentne** in omejene, sicer vroč konflikt postane nevihta ponovnih poskusov. Preprečevanje deadlockov je v resnici disciplina zaklepanja plus omejen ponovni poskus, ne ena sama srebrna krogla.

Cikel, ki ga morate prekiniti

Strategije

Pogled s stališča razgovora

Povezana vprašanja