Cum previi deadlock-urile cu mii de tranzacții concurente?

Question

IT Interview Practice · Accepted Answer

**Achiziționează lock-urile într-o ordine globală consistentă, ține tranzacțiile scurte, coboară izolarea unde e sigur și reîncearcă perdantul când un deadlock tot se întâmplă.** Un deadlock este un ciclu: tranzacția A ține rândul 1 și așteaptă rândul 2, în timp ce B ține rândul 2 și așteaptă rândul 1 — niciuna nu poate continua, așa că DB-ul o omoară pe una.

## Ciclul pe care trebuie să-l rupi

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

## Strategii

- **Ordonare consistentă a lock-urilor.** Dacă fiecare tranzacție blochează întotdeauna rândurile în aceeași ordine (de ex. cheia primară crescătoare), un ciclu este imposibil — A și B apucă amândouă întâi rândul 1, deci una pur și simplu așteaptă. Aceasta este cea mai mare pârghie individuală. Un bug clasic: un transfer de bani care blochează conturile în ordinea `(from, to)` face deadlock cu transferul invers; blochează întotdeauna după `min(id), max(id)`.
- **Tranzacții scurte.** Ține lock-urile cât mai puțin timp posibil — fă validarea, apelurile de rețea și citirile **înainte** de `BEGIN`, apoi blochează, scrie și fă `COMMIT` rapid. Tranzacțiile lungi lărgesc fereastra pentru cicluri și așteptări de lock.
- **Coboară izolarea unde e sigur.** `SERIALIZABLE` ia mai multe lock-uri/lock-uri de range și face mai multe deadlock-uri; `READ COMMITTED` (implicit în Postgres) blochează mai puțin. Folosește cea mai slabă izolare care încă îndeplinește corectitudinea.
- **Reîncearcă la deadlock.** Deadlock-urile sunt tranzitorii. Prinde eroarea de deadlock (Postgres `40P01`, MySQL `1213`) și reîncearcă întreaga tranzacție cu un mic backoff. Ceva contenție este inevitabilă la scară, deci reîncercarea este o plasă de siguranță, nu un înlocuitor pentru ordonare.

## Perspectiva de interviu

Intervievatorul verifică dacă știi că deadlock-urile sunt **prevenite prin design, nu doar prinse**. A numi doar "reîncercarea" este un răspuns slab — răspunsul excelent începe cu **ordonare consistentă a lock-urilor** și **tranzacții scurte**, apoi adaugă reîncercarea pentru rest. O capcană obișnuită: a presupune că aplicația trebuie să detecteze deadlock-urile; în practică **DB-ul detectează ciclul și abandonează o victimă** pentru tine — treaba ta este ordonarea plus o buclă de reîncercare.

**Compromisuri:** ordonarea strictă poate fi grea când pattern-urile de acces sunt dinamice sau se întind pe tabele; izolarea mai joasă riscă anomalii (non-repeatable reads) la care trebuie să te gândești. Buclele de reîncercare trebuie să fie **idempotente** și plafonate, altfel un conflict fierbinte se transformă într-o furtună de reîncercări. Prevenirea deadlock-urilor este de fapt disciplină de lock plus o reîncercare delimitată, nu un singur glonț de argint.

Ciclul pe care trebuie să-l rupi

Strategii

Perspectiva de interviu

Întrebări conexe