Miten estät deadlockit tuhansilla samanaikaisilla transaktioilla?

Question

IT Interview Practice · Accepted Answer

**Hanki lukot yhtenäisessä globaalissa järjestyksessä, pidä transaktiot lyhyinä, laske isolaatiotasoa siellä missä se on turvallista, ja yritä häviäjää uudelleen kun deadlock silti tapahtuu.** Deadlock on sykli: transaktio A pitää riviä 1 ja odottaa riviä 2, kun taas B pitää riviä 2 ja odottaa riviä 1 — kumpikaan ei voi edetä, joten DB tappaa toisen.

## Sykli, joka sinun on katkaistava

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

## Strategiat

- **Yhtenäinen lukkojärjestys.** Jos jokainen transaktio lukitsee rivit aina samassa järjestyksessä (esim. nouseva primary key), sykli on mahdoton — A ja B molemmat nappaavat rivin 1 ensin, joten toinen yksinkertaisesti odottaa. Tämä on ainoa suurin vipu. Klassinen bugi: rahansiirto, joka lukitsee tilit `(from, to)`-järjestyksessä, deadlockaa käänteisen siirron kanssa; lukitse aina `min(id), max(id)`:llä.
- **Lyhyet transaktiot.** Pidä lukot niin lyhyen aikaa kuin mahdollista — tee validointi, verkkokutsut ja lukemiset **ennen** `BEGIN`:iä, sitten lukitse, kirjoita ja `COMMIT` nopeasti. Pitkät transaktiot laajentavat ikkunaa sykleille ja lukko-odotuksille.
- **Laske isolaatiota siellä missä turvallista.** `SERIALIZABLE` ottaa enemmän/range-lukkoja ja deadlockaa enemmän; `READ COMMITTED` (Postgresin oletus) lukitsee vähemmän. Käytä heikointa isolaatiota, joka silti täyttää oikeellisuuden.
- **Yritä uudelleen deadlockissa.** Deadlockit ovat ohimeneviä. Ota kiinni deadlock-virhe (Postgres `40P01`, MySQL `1213`) ja yritä koko transaktiota uudelleen pienellä backoffilla. Jonkin verran kilpailua on väistämätöntä mittakaavassa, joten uudelleenyritys on turvaverkko, ei järjestyksen korvike.

## Haastattelunäkökulma

Haastattelija tarkistaa, tiedätkö että deadlockit **estetään suunnittelulla, ei vain napata kiinni**. Pelkän "uudelleenyrityksen" nimeäminen on heikko vastaus — loistava vastaus johtaa **yhtenäisellä lukkojärjestyksellä** ja **lyhyillä transaktioilla**, lisää sitten uudelleenyrityksen jäljelle jäävälle. Yleinen ansa: olettaa että sovelluksen on havaittava deadlockit; käytännössä **DB havaitsee syklin ja abortoi uhrin** puolestasi — sinun tehtäväsi on järjestys plus uudelleenyrityssilmukka.

**Kompromissit:** tiukka järjestys voi olla vaikeaa, kun pääsykuviot ovat dynaamisia tai kattavat useita tauluja; matalampi isolaatio riskeeraa anomalioita (non-repeatable reads), joita sinun on järkeiltävä. Uudelleenyrityssilmukoiden on oltava **idempotentteja** ja rajattuja, tai kuuma konflikti muuttuu uudelleenyritysmyrskyksi. Deadlock-esto on oikeastaan lukkokuria plus rajattu uudelleenyritys, ei yksittäinen hopealuoti.

Sykli, joka sinun on katkaistava

Strategiat

Haastattelunäkökulma

Aiheeseen liittyvät kysymykset