Comment prévenir les deadlocks avec des milliers de transactions concurrentes ?

Question

IT Interview Practice · Accepted Answer

**Acquérez les verrous dans un ordre global cohérent, gardez les transactions courtes, abaissez l'isolation où c'est sûr, et réessayez le perdant quand un deadlock survient malgré tout.** Un deadlock est un cycle : la transaction A tient la ligne 1 et attend la ligne 2, tandis que B tient la ligne 2 et attend la ligne 1 — aucune ne peut avancer, donc la DB en tue une.

## Le cycle que vous devez briser

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

## Stratégies

- **Ordre de verrouillage cohérent.** Si chaque transaction verrouille toujours les lignes dans le même ordre (par ex. primary key ascendante), un cycle est impossible — A et B saisissent toutes deux la ligne 1 en premier, donc l'une attend simplement. C'est le levier le plus important. Un bug classique : un transfert d'argent qui verrouille les comptes dans l'ordre `(from, to)` deadlocke avec le transfert inverse ; verrouillez toujours par `min(id), max(id)`.
- **Transactions courtes.** Tenez les verrous le moins de temps possible — faites la validation, les appels réseau et les lectures **avant** `BEGIN`, puis verrouillez, écrivez et `COMMIT` rapidement. Les longues transactions élargissent la fenêtre des cycles et des attentes de verrou.
- **Abaisser l'isolation où c'est sûr.** `SERIALIZABLE` prend plus de verrous/range locks et deadlocke davantage ; `READ COMMITTED` (défaut de Postgres) verrouille moins. Utilisez l'isolation la plus faible qui satisfait encore la correction.
- **Réessayer sur deadlock.** Les deadlocks sont transitoires. Attrapez l'erreur de deadlock (Postgres `40P01`, MySQL `1213`) et réessayez toute la transaction avec un petit backoff. Une certaine contention est inévitable à l'échelle, donc le réessai est un filet de sécurité, pas un substitut à l'ordonnancement.

## Perspective d'entretien

L'examinateur vérifie si vous savez que les deadlocks sont **prévenus par conception, pas seulement attrapés**. Nommer « réessai » seul est une réponse faible — l'excellente réponse commence par l'**ordre de verrouillage cohérent** et les **transactions courtes**, puis ajoute le réessai pour le résiduel. Un piège courant : supposer que l'application doit détecter les deadlocks ; en pratique la **DB détecte le cycle et abandonne une victime** pour vous — votre travail est l'ordonnancement plus une boucle de réessai.

**Compromis :** un ordre strict peut être difficile quand les patterns d'accès sont dynamiques ou couvrent plusieurs tables ; une isolation plus basse risque des anomalies (lectures non répétables) que vous devez raisonner. Les boucles de réessai doivent être **idempotentes** et plafonnées, sinon un conflit chaud se transforme en tempête de réessais. La prévention des deadlocks est en réalité de la discipline de verrouillage plus un réessai borné, pas une seule solution miracle.

Le cycle que vous devez briser

Stratégies

Perspective d'entretien

Questions connexes