Jak zapobiegać deadlockom przy tysiącach współbieżnych transakcji?

Question

IT Interview Practice · Accepted Answer

**Nabywaj blokady w spójnej globalnej kolejności, trzymaj transakcje krótkie, obniżaj izolację tam, gdzie to bezpieczne, i ponawiaj przegranego, gdy deadlock i tak wystąpi.** Deadlock to cykl: transakcja A trzyma wiersz 1 i czeka na wiersz 2, podczas gdy B trzyma wiersz 2 i czeka na wiersz 1 — żadna nie może ruszyć, więc DB zabija jedną.

## Cykl, który musisz przełamać

```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

- **Spójna kolejność blokad.** Jeśli każda transakcja zawsze blokuje wiersze w tej samej kolejności (np. rosnący klucz główny), cykl jest niemożliwy — A i B obie chwytają najpierw wiersz 1, więc jedna po prostu czeka. To pojedynczo największa dźwignia. Klasyczny błąd: przelew, który blokuje konta w kolejności `(from, to)`, deadlockuje z przelewem odwrotnym; zawsze blokuj po `min(id), max(id)`.
- **Krótkie transakcje.** Trzymaj blokady jak najkrócej — rób walidację, wywołania sieciowe i odczyty **przed** `BEGIN`, potem blokuj, zapisuj i `COMMIT` szybko. Długie transakcje poszerzają okno na cykle i oczekiwanie na blokady.
- **Obniżaj izolację tam, gdzie bezpiecznie.** `SERIALIZABLE` bierze więcej blokad/blokad zakresowych i częściej deadlockuje; `READ COMMITTED` (domyślny w Postgres) blokuje mniej. Użyj najsłabszej izolacji, która wciąż spełnia poprawność.
- **Ponawiaj przy deadlocku.** Deadlocki są przejściowe. Przechwyć błąd deadlocka (Postgres `40P01`, MySQL `1213`) i ponów całą transakcję z małym backoffem. Pewnej rywalizacji nie da się uniknąć w skali, więc ponowienie jest siatką bezpieczeństwa, a nie substytutem kolejności.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca sprawdza, czy wiesz, że deadlocki są **zapobiegane przez projekt, nie tylko wychwytywane**. Nazwanie samego „ponowienia" to słaba odpowiedź — świetna zaczyna od **spójnej kolejności blokad** i **krótkich transakcji**, potem dodaje ponowienie dla reszty. Częsta pułapka: zakładanie, że aplikacja musi wykrywać deadlocki; w praktyce **DB wykrywa cykl i przerywa ofiarę** za ciebie — twoim zadaniem jest kolejność plus pętla ponowień.

**Kompromisy:** ścisła kolejność bywa trudna, gdy wzorce dostępu są dynamiczne lub obejmują wiele tabel; niższa izolacja ryzykuje anomalie (non-repeatable reads), które musisz przemyśleć. Pętle ponowień muszą być **idempotentne** i ograniczone, inaczej gorący konflikt zamienia się w burzę ponowień. Zapobieganie deadlockom to naprawdę dyscyplina blokad plus ograniczone ponowienie, a nie pojedynczy srebrny pocisk.

Cykl, który musisz przełamać

Strategie

Perspektywa rozmowy kwalifikacyjnej

Powiązane pytania