Section VIII — Systèmes, réseaux, bases de données et distribué

Espace mémoire : Un processus dispose d’un espace d’adressage virtuel isolé et protégé par le noyau. Il contient son propre code exécutable, ses données globales, sa pile (stack), son tas (heap), ses variables d’environnement et ses descripteurs de fichiers. Aucun autre processus ne peut accéder directement à cette mémoire sans mécanisme explicite de communication inter-processus (IPC). Un thread partage l’espace mémoire de son processus parent. Il accède directement au code, aux données globales et au tas de tous les autres threads du même processus. Chaque thread conserve néanmoins sa propre pile d’exécution, ses registres CPU et son compteur programme, ce qui lui permet de suivre son exécution indépendamment. Ordonnancement : Le processus est l’unité fondamentale d’ordonnancement par le noyau. Il possède un identifiant unique (PID), un contexte d’exécution complet et un état propre (en exécution, prêt, en attente, terminé). Le changement de contexte entre processus est coûteux car il implique la mise à jour de la table des pages, la vidange des registres et la modification des structures du noyau. Le thread est l’unité d’exécution effective. L’ordonnanceur peut basculer d’un thread à un autre plus rapidement qu’entre processus, car le contexte partagé (espace d’adressage, descripteurs de fichiers) n’est pas rechargé. Plusieurs threads d’un même processus peuvent s’exécuter en parallèle sur des cœurs CPU distincts, tandis qu’un processus ne peut utiliser qu’un seul thread à la fois par cœur. Synthèse comparative : | Critère | Processus | Thread | | Espace mémoire | Isolé, protégé, indépendant | Partagé (code, données, heap), piles et registres privés | | Unité d’ordonnancement | Oui (PID, contexte complet) | Oui (TID, contexte partiel) | | Coût de basculement | Élevé (changement d’espace d’adressage) | Faible (contexte léger) | | Communication | Requiert IPC (sockets, pipes, mémoire partagée) | Directe via variables/mémoire partagée (risque de race condition) |

1. Exclusion mutuelle : Au moins une ressource doit être détenue de manière exclusive. Une ressource ne peut être attribuée à un seul processus à la fois ; les autres processus qui la demandent doivent attendre jusqu'à ce qu'elle soit libérée. 2. Maintien et attente : Un processus doit détenir au moins une ressource tout en attendant en même temps d'en acquérir d'autres qui sont actuellement détenues par d'autres processus. 3. Absence de préemption : Les ressources ne peuvent être retirées de force à un processus. Elles ne sont libérées que volontairement, après achèvement de la tâche ou demande explicite du processus qui les détient. 4. Attente circulaire : Il doit exister une chaîne cyclique de processus [P1, P2, ..., Pn] tels que P1 attend une ressource détenue par P2, P2 attend une ressource détenue par P3, ..., et Pn attend une ressource détenue par P1. Ces quatre conditions, appelées conditions de Coffman, doivent être réunies simultanément pour qu'un interblocage se produise. La rupture de l'une d'elles suffit à prévenir la situation.

Le protocole TCP (Transmission Control Protocol) et le protocole UDP (User Datagram Protocol) sont deux protocoles de la couche transport du modèle OSI. Ils diffèrent fondamentalement par leur gestion de la connexion, leur fiabilité et leur surcharge réseau. TCP est un protocole orienté connexion. Il établit un canal fiable entre l'émetteur et le récepteur via une poignée de main en trois temps. Il garantit l'ordre de réception, la livraison intégrale et la correction des erreurs grâce à des accusés de réception et des retransmissions automatiques. Il intègre des mécanismes de contrôle de flux et de congestion, ce qui augmente sa latence et sa consommation de bande passante. UDP est un protocole sans connexion. Il envoie des datagrammes indépendants sans établir de session préalable. Il ne garantit ni l'ordre ni la livraison, et ne dispose ni de contrôle de flux ni de contrôle de congestion. Sa surcharge est minimale, ce qui le rend très rapide et à faible latence. Tableau comparatif : Caractéristique | TCP | UDP Orientation | Connexion | Sans connexion Fiabilité | Livraison et ordre garantis | Aucun garant, pertes possibles Contrôle de flux/congestion | Présent | Absent Surcharge | Élevée | Minimale Latence | Plus élevée | Plus faible Cas d'usage approprié pour TCP : Le transfert de fichiers via le protocole FTP ou la navigation web HTTP/HTTPS. Dans ces scénarios, l'intégrité et la reconstitution exacte du flux de données sont prioritaires, car toute perte ou tout désordre rendrait le contenu corrompu ou inutilisable. Cas d'usage approprié pour UDP : La visioconférence en temps réel ou le streaming vidéo en direct. Ces applications tolèrent quelques pertes de paquets mais exigent une latence minimale ; le retransmettre des données dont le délai d'expiration est dépassé serait contre-productif pour la fluidité de l'expérience utilisateur.

Le DNS (Domain Name System) est un protocole de résolution de noms hiérarchique et distribué. En conception native (RFC 1035), il ne fournit aucune garantie cryptographique. Son architecture est optimisée pour la performance, la scalabilité et la décentralisation, pas pour la sécurité. Ce que le DNS garantit : 1. Résolution de noms : conversion déterministe d'un identifiant textuel (domaine) en une adresse réseau (IP) ou enregistrement de service. 2. Scalabilité et décentralisation : répartition de la charge et de l'autorité sur plusieurs niveaux (racines, TLD, serveurs autoritaires). 3. Disponibilité théorique : redondance géographique des serveurs racines et TLD permettant une continuité de service en cas de défaillance locale ou de panne réseau. Ce que le DNS natif ne garantit pas : 1. Confidentialité : requêtes et réponses transitent en clair sur le port 53 (UDP ou TCP). Tout observateur réseau peut lire les domaines consultés, les adresses IP sources et les métadonnées associées. 2. Intégrité : aucune vérification cryptographique des données. Une réponse peut être altérée en transit sans détection. 3. Authentification : impossibilité de vérifier l'origine des réponses. Un attaquant peut se faire passer pour un serveur DNS légitime. 4. Protection contre les attaques spécifiques : le protocole natif est vulnérable au spoofing, à l'empoisonnement de cache, aux interceptions (MITM), aux attaques par amplification DDoS, à la résiliation de session et à la collecte passive de métadonnées. Apport et limites des extensions modernes : - DNSSEC (RFC 4033 à 4035) garantit l'authenticité et l'intégrité des données DNS via une chaîne de signatures cryptographiques signées par les zones parentes. Il ne garantit ni la confidentialité ni la disponibilité. Il ne protège pas contre les attaques par déni de service ni contre la collecte de métadonnées de requêtes. - DoT (RFC 7858), DoH (RFC 8484) et DoQ (RFC 9230) garantissent la confidentialité et l'intégrité du canal de transport entre le client résolveur et le serveur DNS. Ils ne garantissent pas l'authenticité des données DNS, ni la protection contre les serveurs autoritaires malveillants, ni la validation des signatures DNSSEC. Tableau synthétique des garanties : | Garantie | DNS natif | DNSSEC | DoT/DoH/DoQ | |---|---|---|---| | Confidentialité des requêtes | Non | Non | Oui | | Intégrité des données DNS | Non | Oui | Non (seulement transport) | | Authentification des réponses | Non | Oui | Non | | Disponibilité face au DDoS | Théorique | Non | Non | Conclusion technique : le DNS natif est fondamentalement non sécurisé. Une protection complète nécessite le déploiement conjoint de DNSSEC pour l'intégrité et l'authenticité des données, et de DoT ou DoH pour la confidentialité du transport. Aucune solution unique ne couvre l'ensemble des vecteurs de menace, et la sécurité finale dépend de la configuration des résolveurs, des zones autoritaires et des politiques de validation côté client.

Un index B-tree composite sur `(customer_id, created_at)` est physiquement trié selon l'ordre lexicographique des deux colonnes, la première ayant la priorité. Le planificateur de requêtes applique la règle du préfixe gauche pour déterminer si l'index peut être parcouru efficacement. **Requêtes exploitant efficacement l'index** Les conditions suivantes permettent un index seek (recherche directe dans l'arbre) et un parcours ordonné des feuilles : - Filtre exact sur la première colonne + filtre exact sur la seconde : `WHERE customer_id = ? AND created_at = ?` - Filtre exact sur la première colonne + intervalle sur la seconde : `WHERE customer_id = ? AND created_at >= ? AND created_at <= ?` (ou opérateurs `>`, `<`, `BETWEEN`) - Tri sur la seconde colonne après filtre exact sur la première : `WHERE customer_id = ? ORDER BY created_at ASC` ou `DESC` - Regroupement et tri combinés respectant l'ordre de l'index : `GROUP BY customer_id, created_at` ou `ORDER BY customer_id, created_at` - Filtre unique sur la première colonne : `WHERE customer_id = ?` ou `WHERE customer_id BETWEEN ? AND ?`. L'index sert au filtrage, mais dès que la première colonne passe en intervalle, le tri physique sur `created_at` n'est plus garanti et un opération de tri supplémentaire peut être nécessaire. - Requêtes de couverture (index covering) : `SELECT customer_id, created_at FROM table WHERE customer_id = ?` Le moteur satisfait la requête sans accéder à la table, car toutes les colonnes demandées et filtrées sont dans l'index. **Requêtes ne pouvant pas exploiter l'index efficacement** - Filtre ou tri sur `created_at` seul sans `customer_id` : `WHERE created_at > ?` ou `ORDER BY created_at`. L'index est ignoré car il ne respecte pas le préfixe gauche. - Conditions sur `customer_id` qui brisent l'ordre ou l'égalité : `WHERE customer_id IN (?, ?)` peut être optimisé selon le moteur, mais `WHERE UPPER(customer_id) = ?` ou `WHERE customer_id LIKE '%X'` force un index scan complet ou un parcours table. - Disjonctions sans respect du préfixe : `WHERE customer_id = ? OR created_at > ?` oblige généralement le planificateur à choisir un parcours table ou un index scan partiel. - Fonctions ou expressions sur les colonnes indexées : `WHERE DATE(created_at) = ?` ou `WHERE customer_id + 0 = ?` invalide l'usage de l'index. **Mécanisme d'optimisation** Un index B-tree composite autorise un seek tant que les conditions correspondent à un préfixe contigu et trié depuis la première colonne. Si la première colonne est recherchée par égalité, l'index garantit un tri naturel sur la seconde colonne. Si la première colonne est recherchée par intervalle, l'index sert au filtrage mais perd sa propriété de tri sur les colonnes suivantes. Le planificateur choisit l'index uniquement si le coût de recherche est inférieur au coût d'un parcours table, ce qui est systématique pour des sélectivités modérées à élevées sur `customer_id`. **Vérification technique** - Complexité de recherche : O(log N) pour le seek, puis parcours séquentiel des feuilles pour les résultats. - Couverture : possible uniquement si toutes les colonnes de la clause `SELECT` et des clauses `WHERE`/`ORDER BY` sont incluses dans l'index. - Limites du B-tree : ne gère pas nativement les recherches plein texte, les géospatiales ou les intervalles multidimensionnels sans extensions spécifiques.

Le théorème CAP, formulé par Eric Brewer en 2000 et démontré formellement par Gilbert et Lynch en 2002, énonce qu'il est impossible pour un système distribué de garantir simultanément les trois propriétés suivantes lors d'un événement réseau : - Consistance : chaque lecture reçoit l'écriture la plus récente ou une erreur. - Disponibilité : chaque requête reçoit une réponse sans erreur, sans garantir qu'elle contient la donnée la plus récente. - Tolérance aux partitions réseau : le système continue de fonctionner malgré la perte ou le retard arbitraire de messages entre nœuds. L'interprétation « choisir deux sur trois de façon permanente » est une simplification conceptuelle incorrecte. Le théorème ne prescrit pas un compromis statique, mais décrit une contrainte conditionnelle. La tolérance aux partitions est une exigence structurelle dans tout environnement réel, car les réseaux sont intrinsèquement peu fiables. Le système doit donc pouvoir gérer les coupures, mais il est mathématiquement impossible de préserver simultanément la consistance et la disponibilité *lorsqu'une partition se produit*. Le compromis s'applique uniquement pendant la durée de la coupure réseau, pas en fonctionnement nominal. Les architectures distribuées modernes dépassent cette lecture binaire permanente en adoptant des mécanismes dynamiques : - Basculement conditionnel : le système opère en mode CA en temps normal et passe en mode CP ou AP dès qu'une partition est détectée, puis revient automatiquement à son état nominal après résolution. - Consistances ajustables : les systèmes utilisent des quorums, une consistance éventuelle ou des niveaux de consistance configurables par requête, permettant de moduler en temps réel le rapport entre C et A selon la criticité des données et le contexte réseau. - Modèles de cohérence hybrides : au lieu d'un choix fixe, les bases distribuées offrent un spectre de garanties (lecture de ses propres écritures, cohérence causale, linéarisabilité partielle, quorums read/write) qui se déclenchent selon la topologie réseau et les exigences métier. En résumé, le théorème CAP décrit une impossibilité structurelle pendant une coupure réseau, non une règle de conception figée. Il impose d'expliciter les garanties attendues par service ou par requête, et de concevoir des mécanismes de reprise automatique après la résolution de la partition, plutôt que de figer un compromis permanent entre les trois propriétés.

La réplication synchrone et la réplication asynchrone désignent deux stratégies de propagation des écritures vers des nœuds secondaires dans un système distribué. Leur différence fondamentale réside dans le moment de la confirmation client et dans l'impact sur la cohérence et la durabilité des données. Réplication synchrone Le nœud primaire écrit les données, attend que les réplicas (ou un quorum défini) confirment leur persistance sur disque, puis renvoie le succès au client. Cette approche garantit une cohérence forte et une durabilité maximale. En cas de panne du primaire, aucune donnée n'est perdue tant qu'au moins un réplica a confirmé l'écriture. Le compromis est une latence élevée, car le temps de réponse client correspond au temps d'aller retour réseau le plus long plus le temps de persistance sur chaque nœud. Si un réplica est lent ou hors ligne, le système peut se bloquer ou rejeter les écritures. Réplication asynchrone Le nœud primaire écrit les données, les persiste localement, et confirme immédiatement le succès au client sans attendre les réplicas. La propagation vers les secondaires s'effectue en tâche de fond. Cette stratégie minimise la latence perçue par l'application et assure une haute disponibilité continue. Le compromis est une durabilité réduite : en cas de panne du primaire avant la réplication, les écritures non encore propagées sont perdues. L'objectif de point de récupération (RPO) est strictement supérieur à 0. Analyse du compromis latence / durabilité - Latence : synchrone est élevée (dépend du round-trip le plus lent) ; asynchrone est faible (confirmée localement). - Durabilité : synchrone est maximale (RPO ≈ 0) ; asynchrone est conditionnelle (RPO > 0, dépend du délai de propagation). - Cohérence : synchrone est forte (les lecteurs voient toujours l'état le plus récent) ; asynchrone est éventuelle (les lecteurs peuvent voir des données obsolètes pendant la propagation). - Tolérance aux pannes réseau : synchrone est vulnérable (un nœud lent bloque l'écriture) ; asynchrone est résiliente (l'écriture continue même si la réplication est retardée). Tableau comparatif | Critère | Synchrone | Asynchrone | |---|---|---| | Confirmation client | Après persistance sur réplicas | Après persistance locale | | Latence client | Élevée (multi-nœud) | Faible (local) | | RPO (Recovery Point Objective) | ≈ 0 | > 0 | | Cohérence | Forte | Éventuelle | | Impact panne primaire | Aucune perte de données | Perte possible des dernières écritures | | Disponibilité en cas de réseau dégradé | Risque de blocage | Maintien des écritures | Ce compromis s'inscrit dans le théorème CAP : la réplication synchrone privilégie la cohérence et la durabilité au détriment de la disponibilité en cas de partition réseau, tandis que la réplication asynchrone privilégie la disponibilité et la faible latence au prix d'une cohérence et d'une durabilité relâchées. Des mécanismes hybrides (réplication semi synchrone ou basée sur quorum) permettent d'ajuster le degré de confirmation en fonction du RPO acceptable et de la tolérance à la latence de l'application.

Pour garantir l’idempotence dans un système distribué soumis à des retries, vous devez implémenter un mécanisme basé sur une clé d’idempotence unique, couplé à une vérification atomique et à un stockage tolérant aux pannes. Voici le dispositif robuste à déployer. 1. Principe fondamental Chaque commande reçoit une clé d’idempotence unique, générée côté client (UUIDv4, ULID ou Snowflake). Le serveur rejoue l’opération uniquement si cette clé n’a jamais été traitée. Si la clé existe déjà, le serveur retourne immédiatement la réponse initiale sans réexécuter la logique métier. 2. Architecture du mécanisme a) Couche API : le client envoie un en-tête Idempotency-Key ou un champ idempotency_key dans le payload. La méthode HTTP doit être PUT ou PATCH si possible, ou un POST explicitement marqué comme idempotent. b) Couche traitement : avant d’exécuter la logique, le serveur interroge un support de déduplication. Si la clé est absente, il procède à l’écriture atomique (INSERT ON CONFLICT DO NOTHING ou transaction avec verrou exclusif). En cas de succès, il exécute la commande et enregistre la clé. En cas d’échec, il retourne l’erreur correspondante. Si la clé est déjà présente, il retourne immédiatement le résultat précédemment stocké. c) Couche données : la clé est indexée UNIQUEMENT en base de données et en cache distribué (Redis ou Memcached) avec une expiration TTL adaptée au cycle de vie de la commande (24 heures à 7 jours). 3. Support de stockage et intégrité Base de données relationnelle : table idempotency_keys avec les colonnes key (UNIQUE), status, response_payload, created_at, expires_at. L’insertion se fait dans la même transaction que l’opération métier, ou via un mécanisme d’outbox pour garantir la consistance. Cache : entrée idemp:{key} -> response. Le cache sert uniquement à accélérer les retours de doublons, jamais comme source de vérité. Vérification atomique : INSERT INTO idempotency_keys (key, ...) VALUES (...) RETURNING id; ou INSERT ... ON CONFLICT (key) DO UPDATE SET ... Le retour de la requête indique si c’est le premier traitement ou un doublon. 4. Gestion des cas limites Timeout partiel : si le serveur a exécuté la commande mais n’a pas reçu d’ACK, le retry doit retourner la réponse initiale. Le stockage de la réponse (ou un hash) permet cela. Concurrency : utiliser des transactions de niveau SERIALIZABLE ou des verrous optimistes (version) pour éviter les race conditions entre deux retries simultanés. Purge : processus cron ou TTL automatique pour libérer les clés traitées. Ne pas conserver indéfiniment. 5. Risques résiduels et atténuations Collision de clé : probabilité négligeable avec UUIDv4 ou ULID, mais possible. Utiliser un hash cryptographique (SHA-256) si les clés sont dérivées de données métier, et vérifier les collisions en test. Perte de cache : le cache n’est pas persistant. La base de données reste la source de vérité. Toujours vérifier la BDD avant de lire le cache. Surcharge E/S : les vérifications idempotentes ajoutent une lecture et une écriture supplémentaires. Mettre en place un cache local (Caffeine ou Guava) côté service pour réduire la latence. Incohérence métier : si la commande modifie un état externe (API tierce, file d’attente), l’idempotence côté client ne suffit pas. Implémenter un pattern Exactly-Once ou un mécanisme de compensation (Saga) avec journalisation. 6. Format de requête et réponse POST /commandes Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000 Content-Type: application/json { "action": "creer_facture", "montant": 150.00, "devise": "EUR" } Réponse serveur (premier passage) : 201 Created { "id": "cmd_9f8e7d", "status": "traite", "message": "Commande exécutée" } Réponse serveur (retry) : 201 Created { "id": "cmd_9f8e7d", "status": "traite", "message": "Commande exécutée" } Ce mécanisme garantit l’idempotence au niveau applicatif et système. Il doit être couplé à une conception sans état des services et à une journalisation structurée pour le traçage.

La cohérence forte et la cohérence éventuelle sont deux modèles de cohérence des données dans les systèmes distribués. Leur différence fondamentale porte sur le moment où les lectures voient les écritures et sur le mécanisme de synchronisation entre nœuds. **Cohérence forte** (ou linéarisabilité) garantit que toute lecture retourne la valeur la plus récente écrite. Toute opération de lecture effectuée après une écriture voit immédiatement ce résultat sur tous les nœuds. La coordination est synchrone : le système attend la confirmation de plusieurs nœuds avant de valider l'écriture, ce qui introduit de la latence et peut réduire la disponibilité en cas de partition réseau. **Cohérence éventuelle** (ou cohérence à terme) garantit qu'en l'absence de nouvelles écritures, toutes les lectures finiront par retourner la dernière valeur écrite. La propagation des mises à jour entre nœuds est asynchrone. Les lectures peuvent temporairement renvoyer des données obsolètes. Ce modèle privilégie la disponibilité et la tolérance aux partitions, au détriment de la visibilité immédiate. | Critère | Cohérence forte | Cohérence éventuelle | |---|---|---| | Visibilité des écritures | Immédiate sur tous les nœuds | Différée, propagation asynchrone | | Garantie de lecture | Retourne toujours la dernière valeur | Retourne potentiellement une valeur ancienne, mais converge vers la dernière | | Synchronisation | Stricte, coordination nécessaire | Asynchrone, sans attente bloquante | | Impact sur la latence | Plus élevée (attente de confirmation) | Plus faible (écriture locale immédiate) | | Position dans le théorème CAP | Favorise la cohérence (C) | Favorise la disponibilité (A) et la tolérance aux partitions (P) | | Cas d'usage typique | Systèmes bancaires, transactions critiques | Réseaux sociaux, caches, bases NoSQL distribuées | La différence structurelle réside dans le compromis cohérence / disponibilité. La cohérence forte impose une coordination synchrone qui peut bloquer le service en cas de défaillance réseau, tandis que la cohérence éventuelle accepte un état intermédiaire incohérent pour garantir la continuité du service. Le choix dépend des exigences métier : intégrité immédiate des données ou disponibilité permanente avec convergence asynchrone.

Un quorum de lecture et d'écriture est un mécanisme de cohérence configurable dans les systèmes de stockage répliqué. Il repose sur trois paramètres entiers : N (nombre total de réplicas), W (seuil d'acquets pour une écriture) et R (seuil de réponses pour une lecture). Principe mathématique et condition de cohérence Le système impose R + W > N. Cette inégalité garantit une intersection non vide entre l'ensemble des nœuds interrogés pour une lecture et l'ensemble des nœuds ayant acquitté la dernière écriture validée. Si R + W > N, alors au moins un nœud commun existera obligatoirement. Ce nœud commun contient la version la plus récente des données, ce qui assure que toute lecture retourne au minimum la valeur validée par le dernier quorum d'écriture, sans nécessiter de verrous globaux ni de synchronisation temps réel entre tous les nœuds. Mécanisme d'écriture Le client soumet une donnée au coordonnateur. Le coordonnateur distribue l'opération aux N réplicas. Chaque réplica acquitte individuellement après persistance locale. L'écriture est considérée comme validée dès réception de W acquits. La latence d'écriture correspond au temps du W-ième nœud le plus rapide à répondre. Le système tolère jusqu'à N - W pannes simultanées sans perdre la donnée validée. Mécanisme de lecture Le client interroge R réplicas. Chaque réplica renvoie sa version locale accompagnée d'un horodatage, d'un numéro de version ou d'une horloge vectorielle. Le coordonnateur compare les R réponses et renvoie au client la version la plus récente. La latence correspond au temps du R-ième nœud le plus rapide à répondre. Grâce à l'intersection garantie par R + W > N, cette lecture ne peut pas retourner de donnée obsolète par rapport à une écriture validée par W réplicas. Compromis de configurabilité Les valeurs de R et W sont ajustables selon la charge et les exigences de cohérence. Exemples avec N = 3 : - W = 3, R = 1 : écritures fortement cohérentes, lectures rapides mais potentiellement obsolètes en cas de partition réseau. - W = 1, R = 3 : lectures fortement cohérentes, écritures rapides mais risque de perte de données validées en cas de panne. - W = 2, R = 2 : équilibre classique, tolère 1 panne tout en maintenant la cohérence via l'intersection obligatoire. La disponibilité diminue lorsque W et R augmentent, car il faut attendre plus d'acquets ou de réponses. La cohérence augmente également, mais au prix d'une latence plus élevée et d'une sensibilité accrue aux nœuds lents. Lien avec le théorème CAP Dans un réseau distribué, une partition empêche certains réplicas de communiquer. Un quorum bien configuré permet au système de continuer à opérer sur le sous-ensemble disponible tant qu'il peut former un quorum. Si R + W > N, le système privilégie la cohérence en refusant les opérations qui ne peuvent garantir l'intersection. Si les seuils sont abaissés, le système privilégie la disponibilité au risque de retourner des versions divergentes, nécessitant une réconciliation asynchrone ultérieure. Limites et mécanismes de réparation Un quorum seul ne suffit pas à maintenir la cohérence parfaite en cas de pannes multiples ou de conflits d'écriture simultanés. Les systèmes implémentent des mécanismes complémentaires : read repair (correction détectée lors de la lecture), anti-entropy (réplication de fond basée sur des arbres de Merkle ou des comparaisons de versions), et des résolveurs de conflits (last writer wins, vector clocks, CRDTs). Si le nombre de nœuds défaillants dépasse N - W ou N - R, le quorum ne peut plus être formé, et le cluster devient indisponible pour les opérations concernées. Exemples d'implémentation Ce modèle est au cœur des architectures de type Dynamo (Amazon), Apache Cassandra, Riak, et des systèmes de coordination comme etcd ou ZooKeeper, qui appliquent un quorum de votes sur un protocole d'accord distribué (Raft ou Zab) pour garantir la cohérence des états et des métadonnées.

**1. Vérification et collecte des données initiales** - Confirmer la saturation : `top` (tri par `%CPU`), `htop`, `vmstat 1`, `mpstat -P ALL 1` - Distinguer CPU physique vs logique : vérifier le nombre de cœurs/logical CPUs avec `lscpu` ; 100 % sur un seul cœur vs répartition sur tous les cœurs oriente le diagnostic - Valider la faible latence réseau : `ping -c 10 <gateway>`, `mtr -r -c 100 <gateway>`, `ss -i` pour observer RTT et retransmissions - Noter le contexte : heure de début, déploiements récents, mises à jour OS/logs, pics de charge connus, changements de configuration réseau ou applicatif **2. Découpage de l'utilisation CPU** - Analyser la répartition via `mpstat -P ALL 1` ou `sar -u 1` : - `%user` élevé → charge applicative - `%system` élevé → appels système intensifs, verrous noyau, gestion de fichiers/réseaux - `%softirq`/`%irq` élevés → traitement des interruptions réseau ou blocs de stockage - `%iowait` faible → confirme l'absence de goulot disque/E/S (cohérent avec latence réseau faible) - `%steal` élevé → hyperviseur surchargé (contexte cloud/VM) - Interprétation : une latence réseau faible exclut un goulot réseau. La saturation est donc purement calcul ou traitement noyau. **3. Identification des consommateurs** - Processus principaux : `ps -eo pid,ppid,user,%cpu,cmd --sort=-%cpu | head -20` - Threads : `top -H -p <PID_cible>` ou `pidstat -t -p <PID_cible> 1` - Vérifier si : - Un thread unique consomme >80 % → boucle serrée, algorithme inefficace, polling intensif - Charge distribuée sur plusieurs threads/processus → gestionnaire de connexions, worker pool, thread pool, ou softirq distribué - Corrélation avec le réseau : `nethogs`, `iftop`, `ss -s` pour exclure un débit massif masquant le problème (si le débit est faible, le CPU n'est pas sollicité par le réseau) **4. Analyse des causes probables (corrélation 100 % CPU / latence faible)** | Signal observé | Cause probable | Vérification complémentaire | |----------------|----------------|------------------------------| | `%user` élevé, processus connu | Charge applicative (calcul, compression, chiffrement, requêtes DB, parsing) | Profilage applicatif, logs, temps de réponse | | `ksoftirqd`, `kworker` ou `%softirq` élevé | Traitement réseau noyau (GRO/GSO, checksum, iptables/nftables, conntrack, TUN/TAP) | `cat /proc/softirqs`, `nft list ruleset`, `sysctl net.ipv4.netfilter.*` | | `%system` élevé, nombreux `syscall` | Verrous, allocations mémoire, gestion de fichiers, polling | `strace -p <PID> -c` (avec prudence), `perf stat -e syscalls:sys_enter_*` | | Context switching massif (`cs` élevé dans `vmstat`) | Lock contention, thread thrashing, configuration thread pool inadaptée | `pidstat -w 1`, logs applicatifs, analyse des synchronisations | | Processus inconnu, consommation constante, trafic sortant anormal | Compromission (cryptojacking, botnet) | `ps auxf`, `netstat -tunp`, vérification des checksums binaires, isolation | **5. Profilage et validation** - `perf top` ou `perf record --call-graph dwarf -p <PID>` pour identifier les fonctions hot - `perf stat -e cache-misses,cycles,instructions,context-switches -p <PID>` pour détecter les inefficacités matérielles - `bpftrace` ou eBPF : tracer les appels système, les locks, les interruptions sans impacter la production - Corréler avec les logs applicatifs et les métriques de performance (files d'attente, temps de réponse, taux de cache) - Simuler la charge en environnement de test pour reproduire le scénario et isoler le facteur déclenchant **6. Actions correctives et prévention** - Isolation immédiate : limiter les ressources du processus coupable (`cpulimit`, `systemd RuntimeMaxCPU=`, cgroups v2 `cpu.max`), redémarrer le service si possible - Optimisation technique : - Désactiver les fonctionnalités réseau noyau inutiles si CPU bind : `sysctl -w net.core.gro_enabled=0`, `sysctl -w net.ipv4.tcp_checksum=0` (si matériel prend en charge) - Ajuster les pools de threads, affinité CPU (`taskset`, `numactl --cpunodebind`), désactiver l'hyperthreading si le workload est sensible au cache - Optimiser le code, les requêtes DB, ou le schéma de cache - Monitoring et alertes : exporter `%CPU par process/thread`, `softirq`, `context-switches` vers Prometheus/Grafana ; seuils d'alerte précoce (ex. >80 % sustained >5 min) - Documentation : playbook de diagnostic, runbook de rollback, tests de charge réguliers, revue des configurations post-déploiement La faible latence réseau confirme que le goulot n'est pas réseau ni E/S. Le diagnostic doit prioritairement orienter vers le traitement applicatif, le traitement noyau des paquets, ou la gestion des interruptions/verrous. La méthode ci-dessus permet d'isoler la couche exacte, de valider la cause, et d'appliquer une correction ciblée sans impact non maîtrisé sur la disponibilité.

La pagination OFFSET/LIMIT et la pagination par curseur (keyset pagination) reposent sur des mécanismes d'exécution radicalement différents, ce qui impacte directement les performances et la cohérence sur une table de grande taille. Mécanisme OFFSET/LIMIT La clause OFFSET/LIMIT ordonne au SGBD de compter et d'ignorer un nombre fixe de lignes avant de commencer la lecture. La requête typique est : SELECT * FROM table ORDER by id LIMIT 20 OFFSET 40. Le moteur doit physiquement parcourir les 40 premières lignes, les compter, puis charger les 20 suivantes. Sur une table de plusieurs millions d'entrées, la complexité augmente linéairement avec la valeur de l'offset. Plus on avance dans les pages, plus le SGBD perd de temps en I/O et en CPU à scanner et jeter des lignes inutilisées. De plus, si des lignes sont insérées ou supprimées entre deux appels, le compteur se décale, ce qui provoque des doublons ou des données manquantes. Mécanisme par curseur (Keyset) La pagination par curseur utilise la valeur d'une colonne indexée (ou un tuple de colonnes) du dernier enregistrement de la page précédente comme point de départ. La requête typique est : SELECT * FROM table WHERE id > 40 ORDER BY id LIMIT 20. Le SGBD effectue une recherche directe dans l'index B-tree pour atteindre la position exacte, puis lit les 20 lignes suivantes sans compter les précédentes. La complexité est logarithmique par rapport à la taille de la table plus le nombre de lignes retournées, ce qui reste constant et rapide quel que soit le nombre de pages parcourues. Ce mécanisme est insensible aux insertions ou suppressions intermédiaires, car il se base sur une position physique indexée et non sur un compteur abstrait. Tableau comparatif Critère | OFFSET/LIMIT | Curseur (Keyset) Performance sur grand offset | Se dégrade linéairement avec la valeur de l'offset | Stable, indépendante du nombre de pages parcourues Résistance aux modifications concurrentes | Faible, les résultats peuvent se décaler ou dupliquer | Forte, le flux reste cohérent malgré les écritures Saut direct vers une page arbitraire | Possible (ex: page 100) | Impossible, le parcours doit être séquentiel Complexité de mise en œuvre | Très faible, syntaxe standard | Moyenne, nécessite de stocker et encoder le dernier curseur côté client Prérequis technique | Aucun index spécifique obligatoire | Exige un index unique ou ordonné sur la colonne de tri Recommandation technique Pour une application web standard avec un nombre limité de pages et des données relativement statiques, OFFSET/LIMIT suffit. Pour une grande table, un flux infini, un chargement en temps réel ou une cohérence stricte, la pagination par curseur est indispensable. Elle exige une colonne indexée monotone (comme une clé primaire ou un timestamp précis) et une gestion séquentielle côté client du curseur suivant.

Le WAL (Write-Ahead Logging) est un protocole de gestion des transactions dont le rôle central est de garantir la cohérence et la durabilité des données tout en optimisant les performances d'écriture sur disque. Rôles principaux : 1. Récupération après panne (Crash Recovery) : En cas d'interruption brutale, le WAL conserve l'historique séquentiel de toutes les opérations. Au redémarrage, le moteur de base de données rejoue les transactions validées (Redo) ou annule les transactions partielles (Undo) pour restaurer un état cohérent et conforme aux règles métier. 2. Respect de la durabilité (Propriété D de l'ACID) : Le protocole impose qu'aucune modification des pages de données sur le disque ne soit validée tant que les enregistrements correspondants n'ont pas été physiquement inscrits dans le journal persistant. Une transaction validée est donc irréversible. 3. Optimisation des performances d'E/S : Les écritures synchrones sont limitées au journal WAL, qui s'écrit de manière séquentielle et rapide. Les pages de données modifiées en mémoire (dirty pages) sont vidées sur disque de manière asynchrone et groupée, réduisant fortement la latence des opérations de validation. 4. Support des sauvegardes et de la réplication : Le WAL fournit un registre chronologique continu. Il permet des sauvegardes physiques cohérentes sans interruption du service, le Point-in-Time Recovery (PITR) et la réplication synchrone ou asynchrone entre nœuds. Mécanisme technique : - Les entrées du journal contiennent des métadonnées de transaction et des images avant (avant modification) et/ou après (après modification) des données. - Un mécanisme de checkpoint écrit périodiquement les pages sales en mémoire vers le disque et marque un point de référence dans le journal. - Après un crash, le système scanne le WAL depuis le dernier checkpoint connu pour reconstruire l'état exact de la base au moment de la panne. Ce mécanisme est implémenté nativement dans les principaux SGBD modernes, notamment PostgreSQL, Oracle, Microsoft SQL Server et MySQL (moteur InnoDB).

Une horloge murale mesure le temps physique, mais elle ne suffit pas à ordonner de manière fiable les événements dans un système distribué pour quatre raisons fondamentales : 1. Latence réseau variable et imprévisible. Lorsqu'un nœud émet un événement et qu'un autre nœud le reçoit, le délai de transmission dépend de la charge du réseau, de la topologie et de la distance. Même avec des horloges parfaitement synchronisées, un événement émis plus tôt peut arriver après un événement émis plus tard. Le temps physique ne reflète donc pas l'ordre de délivrance ni l'ordre de traitement effectif. 2. Dérive et incertitude de synchronisation. Les oscillateurs des différents nœuds ne battent pas à la même fréquence. Les protocoles de synchronisation (NTP, PTP) corrigent les écarts, mais une marge d'erreur résiduelle (de l'ordre de la microseconde à la milliseconde) persiste. Cette imprécision rend impossible la comparaison directe des timestamps pour établir un ordre global strict et reproductible. 3. Absence de lien direct avec la causalité. L'ordre chronologique imposé par le temps physique ne garantit pas l'ordre de cause à effet. Si l'horloge d'un émetteur est en retard par rapport à celle du récepteur, un message Y peut recevoir un timestamp inférieur à celui d'un événement Z qui en dépend causalement. Le temps physique ne capture pas la relation de dépendance logique entre les événements. 4. Conséquence sur la cohérence des systèmes. Pour ordonner les événements de manière fiable, les systèmes distribués utilisent des horloges logiques (timestamps de Lamport) ou des horloges vectorielles. Ces mécanismes incrémentent un compteur local à chaque événement et fusionnent les états lors des communications, en capturant explicitement la relation « s'est produit avant ». Ils garantissent que si un événement A influence B, A sera toujours ordonné avant B, indépendamment de la synchronisation matérielle. En résumé, le temps physique est insuffisant car il est vulnérable aux délais réseau, aux dérives matérielles et à l'absence de garantie causale. L'ordonnancement distribué fiable repose sur des modèles logiques ou vectoriels qui reconstruisent l'ordre de dépendance sans s'appuyer sur une référence temporelle globale.

Les mutex, sémaphores et variables de condition sont des primitives de synchronisation concurrente fondamentales. Elles diffèrent par leur sémantique, leur mécanisme interne et leur cas d'usage. Voici une comparaison rigoureuse. Tableau comparatif | Critère | Mutex | Sémaphore | Variable de condition | | Rôle principal | Exclusion mutuelle pour sections critiques | Synchronisation et gestion de ressources limitées ou signalisation | Attente qu'une condition logique sur les données soit vérifiée | | Mécanisme | Verrou binaire (acquis libéré) | Compteur entier avec opérations wait (P) et signal (V) | File d'attente de threads bloqués, toujours couplée à un mutex | | Propriété du verrou | Oui, seul le thread lockeur peut le relâcher | Non, n'importe quel thread peut incrémenter le compteur | Non, le réveil est déclenché par n'importe quel thread détectant la condition | | Comptage | Binaire (1 ou 0) | Binaire (0 ou 1) ou compteur (N ressources) | Inexistant, repose sur un prédicat booléen | | Usage typique | Protection de données partagées, accès séquentiel | Contrôle d'accès concurrent à N instances, barrières, signalisation inter processus | Modèles producteur consommateur, attente d'événements, polling évité | | Pièges classiques | Oubli d'unlock, dead par inversion de hiérarchie | Famine, dépassement de compteur, signaux perdus si non atomiques | Condition non testée dans une boucle while, signaux émis avant wait | Analyse détaillée Mutex Le mutex garantit qu'un seul thread exécute une section critique à la fois. Il possède une sémantique de propriété stricte : le thread qui acquiert le verrou est le seul autorisé à le libérer. Cette propriété permet de détecter des bugs de programmation (tentative d'unlock par un autre thread) et facilite la gestion des deadlocks via des conventions d'acquisition hiérarchique. Il est idéal pour protéger des invariants de données partagées. Sémaphore Un sémaphore maintient un compteur entier. L'opération wait décrémente le compteur ; si la valeur devient négative, le thread est bloqué et placé dans une file d'attente. L'opération signal incrmente le compteur et réveille un thread en attente. Contrairement au mutex, il n'y a pas de propriété : n'importe quel thread peut effectuer un signal. Il existe en version binaire (équivalent à un mutex sans propriété) et en version compteur, permettant de limiter strictement le nombre de threads accédant simultanément à une ressource (par exemple, un pool de connexions base de données). Variable de condition Une variable de condition sert à attendre qu'un prédicat logique sur l'état des données devienne vrai. Elle ne fonctionne jamais seule : elle doit être associée à un mutex qui protège les données et l'invariant. L'opération wait relâche le mutex, bloque le thread, et le réveille uniquement lorsque le mutex est de nouveau acquis. Les opérations signal et broadcast réveillent respectivement un ou tous les threads en attente. Ce mécanisme élimine le polling actif et permet une synchronisation fine basée sur les données. Convergence et divergence Point de convergence : les trois primitives reposent sur des files d'attente gérées par le système d'exploitation ou la bibliothèque de concurrence pour bloquer et réveiller des threads sans consommer de CPU (attente passive). Point de divergence majeur : le mutex et le sémaphore gèrent l'accès à une ressource ou un compteur, tandis que la variable de condition gère un état logique. Le mutex impose une propriété stricte, le sémaphore en est dépourvu, et la variable de condition dépend entièrement du mutex pour protéger les données avant wait et signal. Usage combiné : dans un modèle producteur consommateur, le mutex protège la file d'échange, le sémaphore ou la variable de condition signale la disponibilité des données, et la variable de condition attend spécifiquement le remplissage ou le vidage de la file. Synthèse Choisir une primitive dépend de l'objectif : exclusion mutuelle stricte avec propriété -> mutex. Limitation du nombre de connexions concurrentes ou signalisation simple -> sémaphore. Attente réactive d'un changement d'état des données -> variable de condition. Une implémentation robuste combine souvent ces primitives, en veillant à protéger les invariants par un mutex et à tester systématiquement les conditions dans une boucle while pour éviter les signaux perdus.

**Anomalie de lecture non répétable** Une lecture non répétable se produit lorsqu'une transaction lit une ligne de données, qu'une autre transaction modifie ou supprime cette même ligne et valide, puis que la première transaction relit la ligne et constate que sa valeur a changé ou qu'elle a disparu. La transaction ne peut pas « répéter » sa lecture initiale avec le même résultat. Exemple : la transaction T1 lit le solde du compte A100 et obtient 1 000 €. La transaction T2 met à jour ce solde à 1 500 € et valide. Lorsque T1 relit A100, elle obtient 1 500 € au lieu des 1 000 € lus précédemment. **Anomalie de lecture de fantôme (phantom read)** Une lecture de fantôme survient lorsqu'une transaction exécute une requête portant sur un ensemble de lignes (généralement avec une condition de plage), qu'une autre transaction insère une nouvelle ligne correspondant à cette condition et valide, puis que la première transaction réexécute la même requête et découvre soudain la nouvelle ligne. Cette ligne n'existait pas lors de la première exécution, d'où le terme « fantôme ». Exemple : la transaction T1 exécute `SELECT * FROM commandes WHERE montant > 500` et obtient 3 lignes. La transaction T2 insère une nouvelle commande avec un montant de 600 € et valide. Lorsque T1 réexécute la même requête, elle obtient 4 lignes. La quatrième ligne est un fantôme. **Différence fondamentale** La lecture non répétable affecte la cohérence au niveau d'une ligne spécifique déjà identifiée (mise à jour ou suppression). Le phantom read affecte la cohérence au niveau d'un ensemble de résultats retournés par une requête à plage (insertion d'une nouvelle ligne correspondant à la condition). **Prise en compte par les niveaux d'isolation SQL (standard ANSI/ISO)** | Niveau d'isolation | Lecture non répétable | Phantom read | |---|---|---| | Read Committed | Autorisée | Autorisée | | Repeatable Read | Bloquée | Autorisée | | Serializable | Bloquée | Bloquée | Note technique : certaines implémentations (comme InnoDB sous MySQL) étendent Repeatable Read pour bloquer également les fantômes via des verrous de plage (next-key locking), mais cela s'écarte du standard SQL strict qui ne garantit l'absence de fantômes qu'au niveau Serializable.

Un cache stocke une copie temporaire de données pour réduire la latence d'accès et la charge sur la source de vérité. Il introduit des données périmées parce qu'il n'assure pas de synchronisation automatique avec cette source. Lorsque la donnée originale est modifiée, le cache conserve l'ancienne version tant qu'un mécanisme de mise à jour ou de suppression n'est pas déclenché. Ce décalage temporel entre la modification source et la propagation au cache crée une incohérence d'état, couramment appelée problème de cohérence du cache. Deux stratégies d'invalidation courantes : 1. Expiration par durée (TTL) : chaque entrée du cache est associée à un temps de vie maximal. À l'expiration de ce délai, l'entrée est automatiquement considérée comme invalide et supprimée ou marquée comme périmée. Le prochain accès nécessite un rechargement depuis la source. Cette stratégie est simple à implémenter mais peut laisser persister des données obsolètes pendant la durée résiduelle du TTL, ce qui peut être inacceptable pour des données critiques. 2. Invalidation événementielle : un système de messagerie ou un mécanisme de hooks est utilisé pour notifier le cache dès qu'une modification est détectée sur la source de vérité. Lorsqu'un événement de mise à jour ou de suppression est émis, le cache supprime ou actualise immédiatement les clés concernées. Cette approche garantit une cohérence quasi immédiate mais nécessite une architecture de communication fiable (file de messages, webhooks, CDC) et une gestion des erreurs pour éviter les pertes de notifications.

Le circuit breaker est un patron de conception logiciel inspiré des disjoncteurs électriques. Son rôle principal est d’empêcher qu’une dégradation ou une panne d’un service distant ne provoque une cascade de défaillances sur le service appelant, et d’éviter de surcharger un service déjà en difficulté. Dans le cas d’un service A dépendant d’un service B instable, le circuit breaker fonctionne comme un interrupteur à trois états : - État fermé : le trafic passe normalement. Le circuit breaker compte les échecs (exceptions, timeouts, codes HTTP d’erreur) sur une fenêtre temporelle glissante. - État ouvert : lorsque le nombre d’échecs dépasse un seuil configuré, le circuit se déclenche. Les appels suivants vers le service B sont immédiatement refusés sans exécution. Le service A retourne une erreur contrôlée ou applique une stratégie de repli (fallback). Cela libère les threads, les connexions réseau et réduit la charge sur le service B. - État demi-ouvert : après un délai d’attente configuré, le circuit breaker autorise un nombre limité de requêtes de sondage. Si ces requêtes réussissent, il passe à l’état fermé. Sinon, il repasse à l’état ouvert. Rôles opérationnels : - Isoler la défaillance et empêcher la propagation en cascade - Garantir des temps de réponse prévisibles (échec rapide plutôt qu’attente longue) - Permettre au service instable de se rétablir sans être submergé - S’intégrer avec des mécanismes de repli (cache, donnée de secours, réponse par défaut) et de retry exponentiel Paramètres d’implémentation : seuil d’échecs, taille de la fenêtre de mesure, durée avant passage en demi-ouvert, taux d’erreur acceptable, stratégie de fallback. Les bibliothèques modernes (Resilience4j, Polly, Sentinel) exposent ces réglages et fournissent des métriques pour le monitoring et l’ajustement dynamique. Le circuit breaker ne répare pas le service instable ; il contient les dégâts, préserve la disponibilité du service appelant et fournit une base observable pour la résolution de l’instabilité sous-jacente.

Un load balancer (répartiteur de charge) assure la distribution du trafic réseau vers un pool de serveurs backend. La différence fondamentale entre les versions couche 4 et couche 7 réside dans le niveau d’inspection du flux et les critères de décision utilisés. **Principe d’un load balancer L4 (couche Transport)** - Il opère aux adresses IP et aux ports (TCP ou UDP) sans décoder le payload. - Il maintient des tables de connexions, effectue de la translation d’adresses (DNAT/SNAT) ou du routage par modification d’en-tête (Direct Routing, Tunneling). - La décision de répartition s’appuie sur des critères statiques ou simples : algorithme round robin, nombre de connexions actives (least connections), hachage de l’adresse source (source IP hash), ou poids des backend. - Avantages : latence minimale, empreinte CPU/mémoire réduite, capacité à gérer des milliers de connexions simultanées. - Limites : aucune compréhension du protocole applicatif, impossibilité de router selon le contenu, les cookies ou les URL. - Cas d’usage typiques : bases de données relationnelles, réplication UDP, IoT, jeux en temps réel, trafic DNS ou QUIC. **Principe d’un load balancer L7 (couche Application)** - Il opère au niveau du protocole applicatif (HTTP, HTTPS, SMTP, FTP, gRPC, etc.). - Il décode intégralement le flux, analyse les en-têtes, les cookies, les chemins URL, les méthodes HTTP, et peut inspecter le corps de la requête. - La décision de répartition s’appuie sur des critères contextuels : nom d’hôte (host-based), préfixe de chemin (path-based), valeurs de cookies, en-têtes personnalisés, ou état de santé applicatif. - Fonctionnalités avancées : terminaison et ré-encapsulation TLS, mise en cache de réponses, compression, transformation de requêtes/réponses, intégration de règles WAF, persistance de session, réessai intelligent avec backoff. - Avantages : granularité fine du routage, adaptation aux architectures microservices et API, optimisation du trafic, isolation des erreurs applicatives. - Limites : latence supérieure due au parsing complet, consommation de ressources plus élevée, complexité de configuration accrue. - Cas d’usage typiques : sites web, APIs REST/GraphQL, e-commerce, applications SaaS, chargement de fichiers, routage canari. **Tableau synthétique** | Critère | L4 | L7 | |---|---|---| | Couche OSI | Transport (TCP/UDP) | Application (HTTP/HTTPS, etc.) | | Critères de routage | IP source/destination + port | En-têtes HTTP, cookies, URL, méthode, contenu | | Latence | Très faible | Modérée à élevée | | Consommation ressources | Faible | Élevée (CPU, mémoire, sockets) | | Fonctionnalités clés | Round robin, least conn, source hash, NAT | Terminaison TLS, cache, WAF, routage contextuel, persistance session | | Modèle de déploiement | Souvent matériel ou vSwitch léger | Généralement logiciel (HAProxy, NGINX, Envoy, F5 BIG-IP) | Les architectures modernes combinent souvent les deux niveaux : un équilibreur L4 en front-end pour la performance brute et la résilience réseau, couplé à un équilibreur L7 en back-end pour le routage applicatif fin et les politiques de sécurité avancées.

Le exactly-once (traitement exact d’un événement) est difficile à garantir dans les systèmes distribués en raison des limitations fondamentales des réseaux et des machines autonomes. En pratique, il est abordé via des compromis architecturaux combinant idempotence, transactions internes et gestion d’état. Difficultés fondamentales - Nature non fiable des réseaux : les paquets peuvent être perdus, dupliqués, réordonnés ou subir une latence variable. Un timeout peut déclencher une renvoyée alors que le traitement initial a déjà eu lieu. - Indiscernabilité latence / panne : sans horloge parfaitement synchronisée, un nœud lent est interprété comme un nœud mort. Un retry peut arriver soit après le traitement, soit avant, créant un risque de double exécution ou de perte. - Théorème CAP / PACELC : garantir le exactly-once exige une cohérence forte, ce qui implique de bloquer les ressources ou de refuser les requêtes en cas de partition réseau. La disponibilité et la latence en sont dégradées. - Transactions distribuées classiques (2PC, 3PC) : le consensus en plusieurs phases nécessite des locks distribués, bloque les nœuds en attente de confirmation, et est sensible aux timeouts. Le coût en performance les rend inadaptées au streaming ou au traitement haute fréquence. - Gestion de l’état et des points de contrôle : un crash entre le traitement et la validation nécessite un rejouable atomique. Si le rejouage n’est pas contrôlé, le système produit des duplicatas ou des incohérences de sortie. Approches pratiques - Idempotence + déduplication : chaque événement reçoit un identifiant unique. Le consommateur conserve un journal des IDs traités (en mémoire, cache ou base). Un duplicata est systématiquement ignoré. C’est la méthode la plus répandue car elle déplace la complexité du réseau vers l’application, tout en restant performante. - Transactions atomiques end-to-end : les frameworks de traitement (Flink, Kafka Streams, Spark) utilisent des journaux de transactions internes. Les données sont écrites dans un WAL avant d’être rendues visibles. Les offsets ne sont validés qu’après confirmation de l’écriture dans le système de destination. Cette approche garantit le exactly-once strict au niveau du pipeline, mais exige que la destination soit transactionnelle ou idempotente. - Validation différée des offsets : le consommiteur traite les données, écrit le résultat, puis valide l’offset de manière atomique ou via un commit transactionnel. Si un crash survient avant le commit, le message est retraité. La garantie réelle repose sur l’idempotence du système de sortie. - Sagas et transactions compensatrices : pour les processus longs ou multi-systèmes, on remplace l’atomicité ACID par une séquence d’étapes compensables. En cas d’échec, on exécute des opérations inverses. Cela évite les locks distribués mais augmente la complexité de la logique métier et la surface d’erreur. - Compromis réels d’ingénierie : la plupart des brokers (Kafka, Pulsar, RabbitMQ) offrent des garanties exactly-once au niveau du broker, mais ne les garantissent réellement que si l’application utilise des transactions ou de l’idempotence. Le exactly-once strict est souvent remplacé par at-least-once + idempotence, car le coût opérationnel (latence, complexité, risque de blocage) est prohibitif pour les systèmes à haut débit. Tableau récapitulatif des mécanismes Mécanisme | Garantie réelle | Coût | Usage typique Idempotence + déduplication | Exactly-once applicatif | Faible | Files de messages, bases NoSQL, API REST Transactions atomiques (2PC/3PC) | Exactly-once strict | Élevé (latence, blocage) | Bases relationnelles distribuées, orchestrateurs Validation différée d'offsets | Exactly-once avec idempotence externe | Moyen | Kafka Streams, Flink, Spark Structured Streaming Sagas / compensation | Exactly-once au niveau métier | Moyen/Élevé (complexité) | Microservices, pipelines longue durée En résumé, le exactly-once n'est pas un paramètre activable, mais un résultat architectural. Il s'obtient en combinant la traçabilité des événements, l'atomicité des validations, et l'idempotence des opérations de sortie. Les systèmes modernes privilégient at-least-once + idempotence pour le débit, et réservent le exactly-once strict aux cas où la duplication est inacceptable et où le coût en latence est justifié.

Le split-brain (ou « cerveau scindé ») est une situation critique qui survient dans un cluster informatique lorsque la communication entre les nœuds est interrompue, amenant chaque partie à croire qu'elle est la seule à rester opérationnelle. ### 1. Mécanisme Dans un cluster à haute disponibilité, les nœuds s'échangent en permanence des signaux de « heartbeat » (battement de cœur) pour vérifier l'état des autres machines. En cas de perte du lien réseau (coupure de câbles, switch défaillant) ou de latence excessive : * Le nœud A ne reçoit plus les signaux du nœud B et conclut que ce dernier est mort. * Inversement, le nœud B ne reçoit plus les signaux du nœud A et conclut la même chose. * Si le cluster est conçu pour basculer automatiquement les services (failover), chaque nœud va tenter de prendre le contrôle des ressources partagées (disques, adresses IP) simultanément. ### 2. Conséquences * **Corruption des données :** C'est le risque majeur. Si deux nœuds écrivent simultanément sur le même système de fichiers ou la même base de données, l'intégrité des données est irrémédiablement compromise. * **Incohérence des services :** Des services peuvent être démarrés deux fois avec des états différents, rendant le service global inutilisable ou imprévisible. ### 3. Prévention et Solutions Pour éviter ce scénario, les clusters utilisent des mécanismes stricts : * **Le Quorum :** Un nœud ne peut prendre le contrôle des ressources que s'il détient la majorité des voix (plus de 50 % des nœuds). Dans un cluster à 2 nœuds, une coupure réseau entraîne généralement l'arrêt de *tous* les nœuds (ou la mise hors ligne de la minorité) car aucun n'atteint le quorum. * **Le Fencing (ou STONITH - Shoot The Other Node In The Head) :** Avant qu'un nœud ne prenne le contrôle, le cluster doit s'assurer physiquement que l'autre nœud est éteint ou déconnecté du stockage partagé. Cela se fait souvent via des contrôleurs de management (IPMI, iLO, DRAC). * **Liens redondants :** Utilisation de plusieurs cartes réseaux et chemins de communication distincts pour limiter le risque de coupure totale. En résumé, le split-brain est l'incapacité d'un cluster à distinguer une panne réseau d'une panne matérielle, nécessitant des mécanismes de « fencing » et de quorum pour garantir la cohérence des données. 🔏 Sceau AXIOM : reponse scellee au journal probatoire, certification non atteinte (1 source pour environ 16 affirmations), verifiez les points non sources.

**Sauvegarde (Backup)** Copie planifiée ou ponctuelle de données vers un support de stockage distinct (local, cloud, bande, objet). Son rôle est de préserver l'intégrité des données face à la suppression accidentelle, la corruption, les ransomwares ou un sinistre physique. La restauration est généralement initiée manuellement ou semi-automatisée. - RTO : élevé (heures à plusieurs jours selon le volume et la méthode de restauration) - RPO : variable, dépend de la fréquence des copies (quotidienne = perte possible de 24h) - Usage typique : conformité réglementaire, archivage, reprise après sinistre (PRA), protection contre la perte de données **Réplication** Copie continue ou quasi-continue des données et des transactions d'un environnement primaire vers un environnement secondaire. Elle synchronise l'état des données en temps réel ou avec un délai très court. Elle ne garantit pas à elle seule la continuité du service ; elle fournit un miroir de données prêt à être promu en cas de besoin. - RTO : réduit (minutes à heures, selon le mécanisme de basculement mis en place) - RPO : très faible à nul (synchrone = 0 ; asynchrone = quelques secondes à minutes) - Usage typique : reprise après sinistre géographique, distribution de données, migration sans interruption, mise à jour de bases **Haute Disponibilité (HA)** Architecture conçue pour éliminer les points de défaillance uniques (SPOF) grâce à la redondance des composants et au basculement automatique et transparent entre nœuds ou clusters. Le service reste opérationnel même lors de pannes matérielles, logicielles ou de maintenance planifiée. - RTO : proche de zéro (secondes ou moins) - RPO : nul (pas de perte de données lors du basculement, grâce à la synchronisation synchrone et au partage d'état) - Usage typique : services critiques en ligne (transactions financières, e-commerce, systèmes de santé, bases de données en production) **Comparaison structurée** | Critère | Sauvegarde | Réplication | Haute Disponibilité | |---|---|---|---| | Objectif principal | Protection et archivage des données | Synchronisation continue des données | Continuité et transparence du service | | RTO (temps de reprise) | Élevé (heures à jours) | Réduit (minutes à heures) | Proche de zéro (secondes) | | RPO (perte de données) | Variable (fréquence des copies) | Faible à nul (selon synchrone/asynchrone) | Nul | | Automatisation | Restauration généralement manuelle | Synchronisation automatique, basculement variable | Basculement 100 % automatique et transparent | | Complexité et coût | Faible à moyen | Moyen à élevé | Élevé (redondance, clustering, tests de failover) | | Défaillance couverte | Perte/corruption de données, sinistre | Perte du site primaire, migration | Panne de nœud, de réseau, de stockage, maintenance | **Différences fondamentales** - La sauvegarde protège contre la perte de données mais ne maintient pas le service actif ; elle répond à un besoin de récupération point-in-time. - La réplication maintient un miroir de données à jour ; elle réduit le RPO et accélère la reprise, mais exige un mécanisme de basculement pour garantir la continuité. - La haute disponibilité garantit que le service reste accessible en permanence ; elle supprime les temps d'arrêt grâce à la redondance et au basculement automatique, sans intervention humaine. En pratique, une architecture résiliente combine les trois : la sauvegarde protège contre les erreurs logiques et les ransomwares, la réplication permet une reprise géographique ou une migration contrôlée, et la haute disponibilité assure la continuité du service au quotidien.

Dans un système à sémantique at-least-once, l’acquittement (ack) est le seul signal qui informe le broker que le traitement est terminé et que le message peut être supprimé. Si le consommateur plante avant d’envoyer l’ack, les événements suivants se produisent : 1. Le broker ne reçoit pas l’ack. Il considère le message comme non traité ou en attente de confirmation. 2. Après expiration du délai de visibilité (visibility timeout) ou selon la politique de retry, le message redevient disponible et est redistribué, soit au même consommateur après son redémarrage, soit à un autre consommateur du groupe. 3. Le message est donc traité au moins deux fois. La garantie at-least-once assure qu’aucun message n’est perdu, mais elle n’empêche pas les doublons. 4. Si le traitement comporte des effets de bord non atomiques, un plantage avant l’ack peut laisser le système dans un état intermédiaire : le message n’est pas acquitté et sera retraité, ce qui peut générer des doublons destructeurs ou des incohérences de données. 5. L’ordre de traitement peut être perturbé si le message redistribué est consigné après d’autres messages initialement placés derrière lui dans la file. Pour maintenir la cohérence dans ce contexte, l’implémentation doit impérativement : - Garantir l’idempotence des traitements (vérification par clé unique, requêtes INSERT ou UPDATE avec conditions, ou journalisation immuable). - Utiliser des transactions ou des mécanismes de checkpoint pour que l’ack ne soit envoyé qu’après confirmation de la persistance du résultat. - Prévoir des mécanismes de compensation ou de reprise sur incident en cas d’état corrompu. La sémantique at-least-once déplace donc la responsabilité de la gestion des doublons du broker vers l’application consommateur.

### Stratégie Expand & Contract pour ajout NOT NULL sans interruption #### 1. Principe fondamental Ajouter une colonne `NOT NULL` sur une table volumineuse déclenche généralement une réécriture complète (table rewrite) qui verrouille la table ou dégrade fortement les performances. La stratégie sans interruption repose sur le pattern **Expand & Contract** (double écriture) couplé à un **backfill par lots**. L'idée est de décaler la contrainte d'intégrité au profit du code applicatif pendant la phase de remplissage, puis de rétroactiver la contrainte une fois que toutes les lignes existantes sont satisfaites. #### 2. Étapes détaillées | Phase | Action technique | Impact sur la base | État applicatif | |---|---|---|---| | 1 | `ALTER TABLE t ADD COLUMN c TYPE DEFAULT NULL;` | Ajout metadata, réécriture légère ou nulle selon le SGBD | Accepte NULL, lit/écrit `c` | | 2 | Backfill par lots de lignes existantes | Transactions courtes, locks limités, logs maîtrisés | Continue d'écrire `c` (défaut ou calculé) | | 3 | `ALTER TABLE t ALTER COLUMN c SET NOT NULL;` | Validation rapide de la contrainte (aucune réécriture si toutes les lignes sont remplies) | N'écrit plus jamais NULL | | 4 | (Optionnel) Nettoyage code | Suppression des fallbacks applicatifs | Aucun | #### 3. Dimensionnement du backfill (calculs) Le backfill doit être calibré pour équilibrer temps d'exécution, impact I/O et risque de contention. Voici un modèle de calcul générique : ```python # Données d'exemple N_lignes = 80_000_000 taille_lot = 50_000 temps_tx = 0.04 # secondes par transaction (inclut commit) temps_pause = 0.08 # secondes de pause entre lots pour laisser le système respirer nb_lots = (N_lignes + taille_lot - 1) // taille_lot duree_totale_s = nb_lots * (temps_tx + temps_pause) duree_totale_min = duree_totale_s / 60 # Impact sur les logs (estimation) estimation_log_MB = nb_lots * 0.12 # ~120 Ko par lot selon le SGBD et le type de colonne print(f"Nombre de lots: {nb_lots}") print(f"Durée estimée: {duree_totale_s:.1f} s ({duree_totale_min:.2f} min)") print(f"Log estimé: {estimation_log_MB:.1f} Mo") ``` **Sortie Python :** ``` Nombre de lots: 1600 Durée estimée: 192.0 s (3.20 min) Log estimé: 192.0 Mo ``` Règles de dimensionnement : - `taille_lot` : 10 000 à 100 000 lignes selon la charge I/O et la latence réseau. - `temps_pause` : ajuster selon le `checkpoint` du SGBD et la charge concurrente. - Toujours exécuter le backfill dans une transaction unique par lot pour garantir l'atomicité et simplifier la reprise sur échec. #### 4. Implémentation technique (pseudo-SQL / PostgreSQL & MySQL) **Migration 1 (nullable) :** ```sql ALTER TABLE articles ADD COLUMN metadata_hash VARCHAR(64) DEFAULT NULL; ``` **Script de backfill (idempotent, par lot) :** ```sql -- Exemple PostgreSQL avec LIMIT/OFFSET ou clé primaire DO $$ DECLARE offset_val BIGINT := 0; batch_size BIGINT := 50000; rows_affected BIGINT; BEGIN LOOP UPDATE articles SET metadata_hash = md5(random()::text) -- valeur déterministe ou calculée depuis d'autres colonnes WHERE id >= offset_val ORDER BY id LIMIT batch_size; GET DIAGNOSTICS rows_affected = ROW_COUNT; EXIT WHEN rows_affected = 0; offset_val := offset_val + batch_size; COMMIT; PERFORM pg_sleep(0.08); -- pause contrôlée END LOOP; END $$; ``` *Note : MySQL utilise `LIMIT` seul ou `WHERE id BETWEEN ... AND ...` selon la version. Privilégier un index sur la colonne de pagination (ex. `id`).* **Migration 2 (contrainte NOT NULL) :** ```sql ALTER TABLE articles ALTER COLUMN metadata_hash SET NOT NULL; ``` #### 5. Gestion des risques et rollback | Risque | Atténuation | Plan de rollback | |---|---|---| | Verrous longs ou dégradation de performance | Backfill par lots, pause contrôlée, exécution hors heures de pointe ou en lecture seule temporaire | Arrêter le backfill, `ALTER TABLE ... DROP COLUMN` (coûteux mais faisable), revenir à la version code 1 | | Dérive de données (double write échoue) | Code 2 écrit systématiquement la valeur par défaut ; code 1 peut être rétroactif en cas de rollback | Le code 1 conserve la logique de fallback ; rollback vers code 1 sans perte fonctionnelle | | Explosion des logs de transaction | Limiter `batch_size`, activer le `wal_compression` (PG) ou `innodb_flush_log_at_trx_commit=2` (MySQL), monitorer l'espace disque | Augmenter temporairement l'espace disque, réduire `batch_size`, pause plus longue | | Échec partiel du backfill | Script idempotent, checkpoint par `id` ou `ctid`, reprise automatique sur erreur | Reprendre le backfill au dernier offset ; la contrainte NOT NULL ne sera pas appliquée tant que le backfill n'est pas complet | **Prérequis opérationnels :** - Sauvegarde complète avant Migration 1. - Scripts idempotents et versionnés (migrations réversibles). - Monitoring : latence des requêtes, locks actifs, espace disque/logs, taux d'erreur backfill. - Test en environnement de préproduction avec un jeu de données représentatif (même distribution, même volume). #### 6. Points d'attention techniques - **SGBD** : PostgreSQL réécrit la table pour `NOT NULL` si la colonne est ajoutée directement avec contrainte ; MySQL/InnoDB peut ajouter la colonne en metadata si `ALGORITHM=INPLACE` est supporté. Le backfill par lots contourne ce problème. - **Défaut déterministe** : La valeur par défaut doit être reproductible (ex. hash de colonnes existantes, timestamp de création, ou valeur de configuration). Éviter `NOW()` ou `UUID()` dans le backfill, car ils brisent la reproductibilité et compliquent le rollback. - **Concurrence** : Pendant le backfill, les écritures applicatives doivent continuer. Le code 2 doit écrire la colonne à chaque INSERT/UPDATE. Si une ligne est mise à jour après son passage dans le backfill, la valeur est écrasée correctement par le code applicatif. - **Validation post-migration** : `SELECT COUNT(*) - COUNT(colonne_x) FROM table;` doit retourner `0` avant d'appliquer `NOT NULL`. Cette stratégie garantit la continuité de service, limite l'impact sur les performances, et fournit un rollback traçable et testé.

La normalisation et la dénormalisation constituent deux orientations opposées de conception de schéma relationnel. Leur compromis repose sur l'arbitrage entre la cohérence des données, la vitesse d'exécution des requêtes et la complexité de maintenance. Normalisation Objectif : éliminer les redondances et les anomalies de mise à jour en respectant les formes normales (1NF à BCNF). Chaque fait est modélisé une seule fois. Avantages : intégrité référentielle garantie, mises à jour centralisées, économie d'espace disque, schéma évolutif et conforme aux principes ACID. Limites : multiplication des jointures, complexité croissante des requêtes analytiques, latence accrue lors de lectures intensives ou de rapports complexes. Dénormalisation Objectif : introduire volontairement des redondances pour réduire le nombre de jointures et accélérer les parcours de données. Avantages : performances de lecture optimisées, requêtes simplifiées, adaptation aux charges orientées lecture, temps réel ou analytique. Limites : risques d'incohérence, mises à jour en cascade, surcoût en stockage, complexité de validation et de synchronisation. Compromis fondamental Le choix dépend du profil de charge et des contraintes métier. L'arbitrage s'évalue sur trois axes principaux : - Ratio lecture/écriture : une charge dominée par les écritures (OLTP) justifie la normalisation. Une charge dominée par les lectures (OLAP, reporting, dashboards) justifie la dénormalisation. - Contraintes d'intégrité : les systèmes critiques (finance, santé, logistique) exigent une normalisation stricte ou des mécanismes de validation explicite (contraintes, triggers, transactions atomiques) si la redondance est introduite. - Coût infrastructure : le prix du stockage disque est généralement inférieur au coût CPU et I/O généré par des jointures multiples ou des scans complets. La dénormalisation échange de l'espace contre de la vitesse. Stratégies hybrides modernes La pratique courante isole les charges de travail et utilise des mécanismes de synchronisation explicite : - Normalisation de la base transactionnelle pour garantir la vérité unique et la sécurité des écritures. - Dénormalisation ciblée via des vues matérialisées, des tables de lecture dédiées, des colonnes calculées ou des caches applicatifs. - Architecture CQRS (Command Query Responsibility Segregation) pour séparer les modèles d'écriture et de lecture, permettant à chaque côté d'adopter le schéma le plus adapté. - Synchronisation asynchrone ou event-driven pour maintenir la cohérence éventuelle entre données normalisées et données dénormalisées, avec des mécanismes de retry et de contrôle d'intégrité. Synthèse Aucune approche n'est universelle. La normalisation garantit la cohérence mais pénalise les lectures. La dénormalisation optimise la vitesse mais complexifie la maintenance. Le compromis optimal s'obtient en alignant le schéma sur le profil de requêtes, en isolant les charges transactionnelles des charges analytiques, et en implémentant des contrôles d'intégrité explicites chaque fois que la redondance est introduite.