Hur förhindrar du deadlocks med tusentals samtidiga transaktioner?

Question

IT Interview Practice · Accepted Answer

**Ta lås i en konsekvent global ordning, håll transaktioner korta, sänk isolering där det är säkert, och omförsök förloraren när en deadlock ändå inträffar.** En deadlock är en cykel: transaktion A håller rad 1 och väntar på rad 2, medan B håller rad 2 och väntar på rad 1 — ingen kan gå vidare, så DB:n dödar den ena.

## Cykeln du måste bryta

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

## Strategier

- **Konsekvent låsordning.** Om varje transaktion alltid låser rader i samma ordning (t.ex. stigande primärnyckel) är en cykel omöjlig — A och B tar båda rad 1 först, så en väntar helt enkelt. Detta är den enskilt största hävstången. En klassisk bugg: en penningöverföring som låser konton i `(from, to)`-ordning deadlockar med den omvända överföringen; lås alltid på `min(id), max(id)`.
- **Korta transaktioner.** Håll lås så kort tid som möjligt — gör validering, nätverksanrop och läsningar **före** `BEGIN`, lås sedan, skriv, och `COMMIT` snabbt. Långa transaktioner vidgar fönstret för cykler och låsväntningar.
- **Sänk isolering där det är säkert.** `SERIALIZABLE` tar fler/range-lås och deadlockar mer; `READ COMMITTED` (Postgres standard) låser mindre. Använd den svagaste isolering som fortfarande uppfyller korrekthet.
- **Omförsök vid deadlock.** Deadlocks är transienta. Fånga deadlock-felet (Postgres `40P01`, MySQL `1213`) och omförsök hela transaktionen med liten backoff. En del contention är oundviklig i skala, så omförsök är ett skyddsnät, inte en ersättning för ordning.

## Intervjuperspektiv

Intervjuaren kontrollerar om du vet att deadlocks **förhindras genom design, inte bara fångas**. Att namnge "omförsök" ensamt är ett svagt svar — det utmärkta svaret leder med **konsekvent låsordning** och **korta transaktioner**, och lägger sedan till omförsök för resten. En vanlig fälla: att anta att appen måste upptäcka deadlocks; i praktiken **upptäcker DB:n cykeln och avbryter ett offer** åt dig — ditt jobb är ordning plus en omförsöksloop.

**Avvägningar:** strikt ordning kan vara svår när åtkomstmönster är dynamiska eller spänner över tabeller; lägre isolering riskerar anomalier (non-repeatable reads) du måste resonera om. Omförsöksloopar måste vara **idempotenta** och tak-begränsade, annars förvandlas en het konflikt till en omförsöksstorm. Deadlock-förebyggande är egentligen lås-disciplin plus ett begränsat omförsök, inte en enda silverkula.

Cykeln du måste bryta

Strategier

Intervjuperspektiv

Relaterade frågor