Hvordan forhindrer du deadlocks med tusindvis af samtidige transactions?

Question

IT Interview Practice · Accepted Answer

**Erhverv locks i en konsistent global rækkefølge, hold transactions korte, sænk isolation hvor det er sikkert, og genforsøg taberen når en deadlock alligevel sker.** En deadlock er en cyklus: transaction A holder row 1 og venter på row 2, mens B holder row 2 og venter på row 1 — ingen kan fortsætte, så DB'en dræber en.

## Cyklen du skal bryde

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

- **Konsistent lock-rækkefølge.** Hvis hver transaction altid locker rows i samme rækkefølge (fx stigende primærnøgle), er en cyklus umulig — A og B griber begge row 1 først, så en venter simpelthen. Dette er den enkeltstørste greb. En klassisk bug: en pengeoverførsel der locker konti i `(from, to)`-rækkefølge deadlocker med den omvendte overførsel; lock altid efter `min(id), max(id)`.
- **Korte transactions.** Hold locks så kort tid som muligt — udfør validering, netværkskald og reads **før** `BEGIN`, lock derefter, skriv, og `COMMIT` hurtigt. Lange transactions udvider vinduet for cykler og lock-ventetider.
- **Sænk isolation hvor det er sikkert.** `SERIALIZABLE` tager flere/range locks og deadlocker mere; `READ COMMITTED` (Postgres default) locker mindre. Brug den svageste isolation der stadig møder korrekthed.
- **Genforsøg ved deadlock.** Deadlocks er forbigående. Fang deadlock-fejlen (Postgres `40P01`, MySQL `1213`) og genforsøg hele transactionen med lille backoff. Noget kontention er uundgåelig i skala, så retry er et sikkerhedsnet, ikke en erstatning for ordering.

## Interview-perspektiv

Intervieweren tjekker, om du ved, at deadlocks **forhindres ved design, ikke bare fanges**. At navngive "retry" alene er et svagt svar — det fremragende svar leder med **konsistent lock-rækkefølge** og **korte transactions**, tilføjer derefter retry for resten. En almindelig fælde: at antage, at appen skal detektere deadlocks; i praksis **detekterer DB'en cyklen og aborterer et offer** for dig — dit job er ordering plus et retry-loop.

**Trade-offs:** streng rækkefølge kan være svær, når access patterns er dynamiske eller spænder tabeller; lavere isolation risikerer anomalier (non-repeatable reads) du skal ræsonnere om. Retry-loops skal være **idempotente** og begrænsede, ellers bliver en hot konflikt til en retry-storm. Deadlock-forebyggelse er reelt lock-disciplin plus en afgrænset retry, ikke en enkelt sølvkugle.

Cyklen du skal bryde

Strategier

Interview-perspektiv

Relaterede spørgsmål