Systèmes distribués · L3 · Section 3/12
Réplication et cohérence
Progression
#Réplication et cohérence
Répliquer les données sur plusieurs nœuds améliore la tolérance aux pannes, réduit la latence perçue par l’utilisateur et autorise des mises à jour en continu pendant les opérations de maintenance. Mais chaque copie supplémentaire accroît le coût de coordination. Il faut décider quand une écriture devient visible, comment gérer les lectures concurrentes et quelles garanties d’ordre sont nécessaires pour préserver les invariants métiers.
#Pourquoi répliquer ?
- Disponibilité : la panne isolée d’un nœud n’interrompt pas le service ; les clients peuvent continuer à lire et, parfois, à écrire.
- Latence : desservir une région depuis le datacenter le plus proche nécessite des répliques géographiquement distribuées.
- Débit : les lectures peuvent être réparties entre plusieurs nœuds ; certaines architectures autorisent même les écritures concurrentes.
- Maintenance sereine : on peut retirer un nœud pour le mettre à jour sans arrêter la plateforme.
Ces avantages se payent en complexité. Pour les maîtriser, on introduit des modèles de cohérence et des protocoles de diffusion adaptés au besoin fonctionnel.
#Choisir son modèle de cohérence
| Modèle | Garantie | Quand l’utiliser |
|---|---|---|
| Cohérence forte (linéarisable) | Chaque opération paraît s’exécuter instantanément et de façon globale | Invariants critiques (stocks, argent) |
| Cohérence séquentielle | Toutes les répliques partagent le même ordre, mais sans contrainte de temps réel | Flux d’événements ordonnés, journaux |
| Cohérence causale | Les dépendances sont respectées, les événements concurrents peuvent être réordonnés | Réseaux sociaux, collaboration |
| Cohérence éventuelle | Toute mise à jour finira par être visible partout | Caches, profils, méta-données |
Une architecture moderne combine souvent plusieurs modèles : commandes financières linéarisables, mais profils utilisateur servis en cohérence causale via un CDN.
#Quorums R/W — visualisation
Les quorums généralisent les lectures/écritures majoritaires : on choisit deux entiers R et W (nombre de répliques consultées respectivement par les lectures et écritures) tels que R + W > N. Ce recouvrement garantit qu’au moins une réplique retournera la dernière écriture confirmée. Les valeurs courantes R = 2, W = 2 pour N = 3 assurent un équilibre disponibilité/cohérence.
Le client contacte un coordinateur (leader ou nœud choisi). L’écriture est tamponnée localement pour ne pas être perdue.
#Animation : propagation d’une écriture
Leader — eu-west-1
RépliqueLe leader écrit d’abord localement afin de pouvoir rejouer la mutation si nécessaire.
Follower — eu-central-1
RépliqueAucune nouvelle entrée pour l’instant : la mutation doit être diffusée.
Follower — us-east-1
RépliqueLes lectures locales voient #41 comme dernier état stable.
Écriture appendée côté leader
Le leader accepte une nouvelle mutation (#42) et l’appose à la fin de son journal. Tant que la réplication n’a pas atteint le quorum d’écriture, l’entrée reste en attente et n’est pas visible en lecture cohérente.
Cette animation illustre la vie d’une écriture dans un cluster inspiré de Raft : append local, diffusion, quorum, partition puis réparation. Trois points clefs :
- Commit ≠ réplication totale : tant que le quorum est atteint, une réplique en retard peut rattraper plus tard.
- Promotion contrôlée : une région isolée ne doit pas devenir leader si elle ne peut garantir un quorum global ; sinon, des écritures conflictuelles apparaissent.
- Réparation explicite : read-repair, anti-entropy ou streaming de snapshots permettent de réaligner les suffixes journaux.
#Types CRDT et convergence sans coordination
Les CRDT (Conflict-free Replicated Data Types) reposent sur des opérations commutatives, associatives et idempotentes. Chaque réplique peut appliquer localement une mutation puis réconcilier via une fonction de fusion déterministe.
Le compteur PN (Positive/Negative counter) maintient deux vecteurs : un pour les incréments et un pour les décréments. La fusion combine chaque composante via un maximum, garantissant que l’on conserve la contribution la plus récente de chaque réplique. Ce principe s’applique à des structures plus riches (ensembles add-only OR-Set, cartes à versionnage, G-Counters, etc.).
#Stratégies de convergence et patterns d’architecture
- Read-repair : en lecture, si deux répliques retournent des versions différentes, on met la plus fraîche à jour sur-le-champ.
- Anti-entropy : synchronisations périodiques pair-à-pair (gossip) qui comparent des résumés (Merkle trees, vector clocks puissants) pour envoyer seulement les différences.
- Change data capture : capturer les écritures via un journal binaire (binlog) puis les rejouer vers des répliques analytiques ou des caches éventuels.
- Leaderless writes : certains systèmes (Dynamo, Cassandra) autorisent l’écriture sur n’importe quel nœud ; ce sont les mécanismes de quorum et de résolution de conflits qui assurent la convergence.
- Écriture multi-région : utiliser des CRDT ou une enveloppe transactionnelle globale (Spanner, Calvin) selon le budget de latence acceptable.
#Bonnes pratiques opérationnelles
- Qualifier chaque donnée métier : nécessite-t-elle une cohérence forte, causale, ou une simple convergence ? Ajuster le protocole en conséquence.
- Mesurer la staleness : suivre le retard moyen/maximal entre répliques (lag) pour déclencher alertes et actions correctives.
- Automatiser les réparations : scripts d’anti-entropy, promote/demote orchestrés, tests de reprise claire.
- Documenter les scénarios de rollback : comment annuler une écriture confirmée uniquement sur un quorum local ?
- Tester en mode chaos : injecter partitions, latence, gigue pour valider les hypothèses de cohérence.