0Pricing
Coding Interview Prep · Leçon

Interblocages, verrous et MVCC

Comment les bases de données évitent les conflits et les compromis entre verrous et instantanés

Interblocages, verrous et MVCC est une leçon Coding Interview Prep gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Coding Interview Prep, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Coding Interview Prep comprend 4 leçons au total.

Comment les bases de données imposent réellement l'isolation

Les niveaux d'isolation sont la promesse ; le verrouillage et MVCC sont les mécanismes qui la tiennent. Les recruteurs posent des questions à leur sujet pour vérifier que vous comprenez ce qui se passe en interne lorsque des transactions entrent en collision.

Il existe deux grandes stratégies :

  • Pessimiste (verrouillage) : bloquer les accès conflictuels jusqu'à la libération d'un verrou.
  • Optimiste / MVCC : laisser tout le monde lire un instantané cohérent et détecter les conflits lors de la validation.

Cette leçon traite des verrous, des interblocages et de MVCC, ainsi que de leurs compromis respectifs.

Verrous partagés ou exclusifs

Le verrouillage classique utilise deux modes principaux :

  • Verrou partagé (S) pour les lectures. Plusieurs transactions peuvent détenir simultanément un verrou partagé sur la même ligne.
  • Verrou exclusif (X) pour les écritures. Une seule transaction peut le détenir, et il bloque tous les autres verrous sur cette ligne.

La règle est la suivante : S est compatible avec S, mais X n'est compatible avec rien. Une transaction qui écrit doit attendre tous les lecteurs, et les lecteurs doivent attendre une transaction qui écrit.

Verrouillage explicite avec SELECT FOR UPDATE

Vous pouvez demander un verrou d'écriture sur des lignes que vous ne faites que lire, afin d'empêcher d'autres transactions de les modifier avant que vous n'agissiez. C'est la méthode standard pour éviter les mises à jour perdues dans un cycle de lecture-modification-écriture.

SELECT ... FOR UPDATE prend des verrous de ligne exclusifs ; les lignes restent verrouillées jusqu'à ce que vous exécutiez COMMIT ou ROLLBACK.

BEGIN;
-- lock the row so no one else can modify it concurrently
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;  -- lock released here

Qu'est-ce qu'un interblocage ?

Un interblocage se produit lorsque deux transactions ou plus détiennent chacune un verrou dont l'autre a besoin, formant un cycle dans lequel aucune ne peut progresser.

Le cas classique est le suivant : T1 verrouille la ligne A, puis demande la ligne B ; T2 verrouille la ligne B, puis demande la ligne A. Chacune attend indéfiniment l'autre.

Les bases de données détectent cela à l'aide d'un graphe d'attente. Lorsqu'un cycle est trouvé, le moteur choisit une victime et l'interrompt, en renvoyant une erreur d'interblocage afin que les autres puissent continuer.

Interblocage : chronologie

Observez le croisement dans l'ordre des verrous. T1 prend la ligne 1, puis demande la ligne 2 ; T2 prend la ligne 2, puis demande la ligne 1. Aucune ne libère son verrou, alors le moteur en interrompt une.

La transaction interrompue reçoit une erreur telle que deadlock detected et doit réessayer. La transaction survivante valide normalement.

-- T1                                  | -- T2
BEGIN;                                 | BEGIN;
UPDATE accounts SET balance=balance-10  | UPDATE accounts SET balance=balance-10
  WHERE id=1;  -- locks row 1          |   WHERE id=2;  -- locks row 2
UPDATE accounts SET balance=balance+10  | UPDATE accounts SET balance=balance+10
  WHERE id=2;  -- waits for T2         |   WHERE id=1;  -- waits for T1 -> CYCLE
-- one transaction is chosen as victim and rolled back

Prévenir les interblocages

Vous ne pouvez pas éliminer complètement les interblocages, mais vous pouvez les rendre rares. Réponses classiques en entretien :

  • Ordre de verrouillage cohérent : acquérir toujours les lignes dans le même ordre (par exemple, selon un id croissant). Cela brise le cycle.
  • Garder les transactions courtes : conserver les verrous le moins longtemps possible.
  • Réduire l'isolation lorsque c'est sûr : moins de verrous, donc moins de conflits.
  • Ajouter une logique de nouvelle tentative : les transactions victimes d'un interblocage doivent réessayer automatiquement.

L'ordre cohérent est la correction la plus efficace et celle que les recruteurs veulent entendre en premier.

Granularité des verrous

Les verrous peuvent être pris à différentes portées, ce qui implique un compromis entre concurrence et surcoût :

  • Les verrous au niveau des lignes permettent une forte concurrence, mais coûtent davantage à gérer.
  • Les verrous au niveau des pages ou des tables sont moins coûteux à suivre, mais bloquent davantage de transactions.

Certains moteurs passent des verrous de ligne aux verrous de table lorsqu'une transaction touche trop de lignes (escalade des verrous). Cela explique pourquoi un grand UPDATE en masse peut soudainement bloquer tout le monde.

MVCC : l'approche par instantané

MVCC (contrôle de la concurrence multiversion) est le mécanisme grâce auquel Postgres, Oracle et InnoDB évitent la plupart des verrous de lecture. Au lieu de verrouiller, la base de données conserve plusieurs versions de chaque ligne.

Son principal avantage, et une formule souvent appréciée en entretien, est le suivant : les lecteurs ne bloquent pas les transactions qui écrivent, et les transactions qui écrivent ne bloquent pas les lecteurs.

Chaque transaction voit un instantané cohérent à un instant donné, tandis que les transactions qui écrivent créent de nouvelles versions des lignes au lieu de les écraser sur place.

Comment fonctionne MVCC en interne

Lorsqu'une ligne est mise à jour, MVCC écrit une nouvelle version et conserve l'ancienne. Chaque version contient des métadonnées d'identifiant de transaction (xmin et xmax dans Postgres) indiquant quand elle est devenue visible et quand elle a été remplacée.

L'instantané d'une transaction détermine la version qu'elle voit. Les anciennes versions qu'aucune transaction ne peut encore voir deviennent des tuples obsolètes, récupérés plus tard par un processus de nettoyage. Dans Postgres, ce processus est VACUUM ; ne pas l'exécuter provoque le gonflement des tables, une question de suivi fréquente.

Verrouillage ou MVCC : le compromis

Résumons clairement la comparaison :

  • Verrouillage pur : correction simple, mais les lecteurs et les transactions qui écrivent se bloquent mutuellement, ce qui réduit la concurrence.
  • MVCC : excellente concurrence en lecture, aucun verrou de lecture, mais une contrepartie en stockage des versions et en nettoyage (VACUUM, gonflement des tables), et des verrous toujours nécessaires pour les conflits entre écritures.

Même les moteurs MVCC utilisent des verrous pour les écritures : deux transactions qui mettent à jour la même ligne doivent être sérialisées. MVCC supprime la contention entre lecteurs et transactions qui écrivent, mais pas celle entre transactions qui écrivent.

Verrouillage optimiste et colonnes de version

En plus du MVCC au niveau du moteur, les applications ajoutent souvent un verrouillage optimiste pour les opérations de lecture-modification-écriture réparties sur de longues sessions utilisateur. Vous ajoutez une colonne version, vous la lisez et, lors de la mise à jour, vous exigez que la version corresponde avant de l'incrémenter.

Si une autre transaction a mis à jour la ligne en premier, la version ne correspond plus, aucune ligne n'est affectée et votre code sait qu'il doit recharger les données et réessayer. Aucun verrou n'est conservé pendant que l'utilisateur réfléchit, donc la concurrence reste élevée. Les recruteurs apprécient cette solution pour répondre à la question : « Comment gérez-vous deux utilisateurs qui modifient le même enregistrement ? »

-- read: SELECT id, data, version FROM items WHERE id = 1;  -- version = 7
UPDATE items
  SET data = 'new value', version = version + 1
  WHERE id = 1 AND version = 7;
-- if rows affected = 0, someone else changed it: reload and retry

Vérification rapide

Vérifiez la formule clé de MVCC.

Récapitulatif : verrous, interblocages et MVCC

Vous pouvez maintenant expliquer les mécanismes qui se cachent derrière l'isolation :

  • Les verrous partagés et exclusifs coordonnent les accès ; SELECT FOR UPDATE prend explicitement des verrous d'écriture.
  • Les interblocages sont des cycles de verrous ; le moteur interrompt une victime, et un ordre de verrouillage cohérent en empêche la plupart.
  • MVCC conserve plusieurs versions des lignes afin que les lecteurs et les transactions qui écrivent ne se bloquent pas, au prix d'un nettoyage (VACUUM, gonflement des tables).

En associant ces mécanismes aux niveaux d'isolation et aux anomalies étudiés précédemment, vous pouvez traiter un entretien complet sur la concurrence, du début à la fin.

Questions Fréquemment Posées

La leçon « Interblocages, verrous et MVCC » est-elle gratuite ?

Oui — le texte complet de « Interblocages, verrous et MVCC » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Coding Interview Prep, passe à CoddyKit PRO. Le cours Coding Interview Prep comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Interblocages, verrous et MVCC » ?

Comment les bases de données évitent les conflits et les compromis entre verrous et instantanés Tu pratiques Coding Interview Prep avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Coding Interview Prep ?

Aucune expérience préalable n'est requise. Coding Interview Prep sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Interblocages, verrous et MVCC » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Coding Interview Prep ?

Oui. Chaque leçon Coding Interview Prep inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Les propriétés ACID expliquées
  2. Les quatre niveaux d’isolation
  3. Lectures sales, non répétables et fantômes
  4. Interblocages, verrous et MVCC
← Retour à Coding Interview Prep