Les systèmes distribués modernes sont une question de compromis. Les performances, la fiabilité, l'évolutivité et la cohérence ont un prix : il faut toujours payer un prix quelque part. C'est là qu'intervient le théorème CAP : c'est le point de départ pour comprendre les compromis inévitables dans la conception distribuée.  Pourquoi le théorème CAP est-il vrai ? Qu'explique-t-il réellement ? Et, plus important encore, est-il suffisant ? Dans cet article, nous explorerons le théorème CAP, ses limites, les critiques auxquelles il a été confronté et la manière dont de nouvelles idées comme PACELC font avancer le débat. Plongeons-nous dans le vif du sujet.  Théorème CAP  La première version du théorème CAP a débuté par un débat entre   . Mais au fil du temps, il a évolué, a obtenu une preuve formelle et est devenu le théorème CAP tel que nous le connaissons aujourd'hui. ACID et BASE  Le théorème CAP stipule qu'un   : système distribué peut satisfaire au plus deux des trois propriétés simultanément   Cohérence   Disponibilité   Tolérance de partition  Cette limitation oblige les ingénieurs à faire des compromis difficiles en fonction des objectifs du système et des réalités de leurs environnements distribués.  Cohérence   La cohérence dans CAP n'est pas la même que la cohérence dans   . Dans le théorème CAP, elle fait référence à   ou   . Cela signifie que   , quel que soit le nœud qui traite la requête. Cela signifie que chaque opération de lecture reflète l'écriture la plus récente, quel que soit le nœud que vous interrogez. les transactions ACID la linéarisation à la cohérence forte tous les nœuds d'un système distribué doivent toujours présenter une vue unique et à jour des données  💡 La cohérence dans ACID, en revanche, vise à garantir qu'une transaction amène la base de données d'un état valide à un autre état valide, en suivant les règles définies par le schéma de la base de données. Il s'agit plutôt d'appliquer des contraintes d'intégrité (comme les clés étrangères, les contraintes uniques, etc.) et de garantir que la base de données ne reste pas dans un état non valide, même en cas de panne.  Disponibilité   La disponibilité dans CAP signifie que   . En d'autres termes, si un nœud sain reçoit une requête, il doit la traiter et y répondre. Cependant, CAP   . Il garantit simplement que le nœud ne tombe pas en panne silencieusement (par exemple, dans   les nœuds peuvent répondre avec des données obsolètes lors d'une partition pour garantir la disponibilité). chaque nœud non défaillant doit renvoyer une réponse pour chaque requête qu'il reçoit, quelles que soient les partitions réseau ne garantit pas que la réponse sera toujours « correcte » ou à jour un système AP,  💡 Eric Brewer (l'auteur original de CAP) a décrit à l'origine cette propriété de manière un peu plus flexible comme suit : « presque toutes les requêtes devraient obtenir une réponse ». Cependant, dans la preuve formelle de CAP, la disponibilité a été rendue plus stricte, exigeant que « chaque requête reçoive une réponse tant que le nœud qui la gère est sain ».  En pratique, la disponibilité n'est pas une garantie absolue : elle dépend souvent de contraintes spécifiques au système, comme le temps que vous êtes prêt à attendre une réponse. Pour les systèmes réels,   joue un rôle essentiel dans la définition de votre SLA (accord de niveau de service), même si le CAP lui-même ne tient pas directement compte de la latence. Plus d'informations à ce sujet dans   . le temps de réponse (ou les délais d'attente) cet article de blog  Tolérance de partition   La tolérance de partitionnement consiste à survivre aux pannes du réseau.   Une partition se produit lorsque les nœuds ne peuvent pas communiquer en raison de paquets abandonnés, de délais d'attente ou de divisions du réseau. Si les nœuds ne peuvent pas communiquer en raison d'une division du réseau (partition), le système doit toujours respecter ses garanties de cohérence ou de disponibilité, en fonction de ses choix de conception.  Les systèmes distribués ne vivent pas dans un monde de conte de fées avec des réseaux parfaits. Des paquets sont perdus, des dépassements de délai se produisent et des pics de latence sont inévitables. Pour cette raison,   : les partitions se produiront tôt ou tard, vous ne pouvez donc pas « choisir » de les ignorer, aussi tentant que cela puisse paraître. la tolérance de partition n'est pas négociable dans tout système distribué  Dans CAP, la tolérance de partition ne signifie pas que le système continue de fonctionner comme si de rien n'était. Cela signifie que le système doit décider s'il doit donner la priorité à la disponibilité (AP) ou à la cohérence (CP) pendant une partition. Si vous deviez ignorer la tolérance de partition, vous construiriez essentiellement un système monolithique non distribué.  Le CAP expliqué  La façon la plus simple de comprendre le CAP est d'envisager une   , une situation dans laquelle deux parties d'un système distribué ne peuvent pas communiquer entre elles. Dans un tel scénario, le système est confronté à trois résultats possibles : partition réseau    tandis que l'autre est isolée, les deux parties auront des états incohérents. Cela entraîne une perte de   . Si une partie du système accepte les mises à jour C (cohérence)    , il doit bloquer les mises à jour dans l'une ou les deux parties de la partition pour garantir un état unifié sur tous les nœuds. Cela entraîne une perte de   car certaines demandes seront refusées ou retardées indéfiniment. Si le système choisit de rester cohérent disponibilité (A),    et cohérent (C) sans tolérer la partition (P), il n'est pas réellement distribué. Cela nécessiterait que les nœuds interagissent et réconcilient l'état, ce qui est impossible lors d'une partition. Si le système choisit de rester disponible (A)  Ainsi,   , le système ne peut satisfaire que   . Une fois la partition résolue (c'est-à-dire que les nœuds interagissent à nouveau), le système peut retrouver les trois propriétés, mais   , des compromis sont inévitables. lors d'une partition deux des trois propriétés (C, A ou P) lors de la partition elle-même  Implications du théorème  Une conséquence du théorème pour les systèmes asynchrones est que seules trois combinaisons de cohérence, de disponibilité et de tolérance de partition sont possibles :  AP (Disponibilité + Tolérance de partition)  Les systèmes de ce type répondent aux requêtes, mais les données renvoyées ne sont pas toujours à jour, les mises à jour des données étant plus lentes mais « toujours » disponibles. DNS, DynamoDB et Cassandra sont des exemples de tels systèmes.  CP (Cohérence + Tolérance de partition)  Les systèmes de ce type renvoient toujours des données à jour, mais certains nœuds, voire tous, du système peuvent ne pas répondre s'ils sont partitionnés. Cela donne des mises à jour atomiques mais peut entraîner des dépassements de délai. Les bases de données NoSQL telles que Google BigTable, MongoDB, HBase et Redis sont toutes des systèmes de ce type.  CA (Cohérence + Disponibilité)  Les systèmes de ce type renvoient toujours des données à jour lorsqu'il n'y a pas de partitions. En raison de cette dernière limitation, ces systèmes ne sont généralement utilisés que sur une seule machine. Les bases de données relationnelles classiques en sont un exemple.  En réalité, nous choisissons entre CP et AP car CA est fondamentalement un monolithe sans partitions. Pour les systèmes à grande échelle, les concepteurs ne peuvent pas abandonner P et ont donc un choix difficile entre C et A.  Dans CA, la défaillance d'un nœud signifie l'indisponibilité totale du service. Mais cela ne désactive pas l'évolutivité, car nous pouvons cloner des monolithes indépendants et répartir la charge sur eux.  Critique du théorème CAP  Le théorème CAP est un concept fondamental dans les systèmes distribués, mais il n'est pas sans limites. Malgré toute sa clarté dans la présentation de l'idée de compromis, le théorème CAP a souvent été critiqué pour avoir trop simplifié des réalités complexes, ce qui a conduit à des malentendus et à des applications erronées.  1. Les compromis ne s'appliquent que pendant les partitions  L'une des critiques les plus courantes est que les compromis du théorème CAP (choix entre   et   ne s'appliquent que lorsqu'une   se produit réellement. En fonctionnement normal, lorsque le réseau est stable et qu'aucune partition n'existe, il n'y a pas de compromis inhérent entre cohérence et disponibilité. cohérence (C) disponibilité (A)) partition du réseau (P)  De plus, ces compromis ne sont pas universels dans l'ensemble du système. Au sein d'un même système distribué :  Différentes parties du système peuvent subir différents compromis en fonction du contexte (comme l’emplacement de l’utilisateur, le type de données).  Certaines opérations peuvent privilégier la cohérence tandis que d’autres privilégient la disponibilité.  Les décisions peuvent varier lors de l’exécution en fonction de facteurs tels que la charge, la latence ou les exigences de l’utilisateur.  Cette nuance est souvent perdue dans les discussions de haut niveau sur le CAP, ce qui conduit à des classifications trop simplifiées des systèmes en « CP » ou « AP » dans leur ensemble.  2. CAP ignore la latence  Une autre critique importante est que le théorème CAP ne tient pas compte de   , même si la latence et le partitionnement sont profondément liés dans la pratique. Par exemple : la latence  Un réseau lent (latence élevée) peut sembler indiscernable d’une partition.  Les délais d'attente, utilisés pour détecter les pannes, sont subjectifs et dépendent fortement de la conception du système et des conditions du réseau. Ce qu'un système définit comme une « partition » peut n'être qu'un délai passager pour un autre.  Dans les systèmes distribués réels, lorsqu'une partition ou une latence élevée se produit, le système doit prendre une décision dans un   : donner la priorité à la disponibilité en renvoyant un résultat potentiellement obsolète, ou donner la priorité à la cohérence en attendant plus longtemps (et en ne répondant potentiellement pas). La vue binaire de CAP ne capture pas la complexité de ces décisions. délai d'attente  3. Les propriétés CAP ne sont pas binaires  Le théorème CAP présente la cohérence, la disponibilité et la tolérance de partition comme des propriétés binaires : soit vous les avez, soit vous ne les avez pas. Mais en pratique,   : ces trois propriétés existent sur un spectre    n'est pas une propriété binaire « on/off » : elle varie de 0 % à 100 %. Par exemple, un système peut garantir une disponibilité de 99,99 %, mais cela permet tout de même de courtes périodes d'indisponibilité. La disponibilité    a différents niveaux, de la cohérence éventuelle à la cohérence causale, en passant par la cohérence forte. Toutes les applications ne nécessitent pas une linéarisabilité complète. La cohérence    en elle-même n'est pas un événement clair et net. Les systèmes peuvent être en désaccord sur l'existence d'une partition (par exemple, un nœud considère un dépassement de délai comme une défaillance, tandis qu'un autre continue de fonctionner normalement). La tolérance de partition  Cette nature continue des propriétés rend le CAP trop simpliste pour modéliser les complexités des systèmes distribués modernes.  Théorème PACELC  Bien que le modèle CAP ait révolutionné notre compréhension des compromis dans les systèmes distribués, il ne s'agit pas du dernier mot sur le sujet.   est considéré comme une approche alternative à la conception de systèmes distribués. Il est basé sur le modèle CAP, mais en plus de la cohérence, de la disponibilité et de la tolérance de partition, il inclut également la latence et l'exclusion logique entre les combinaisons de ces concepts. Le théorème PACELC décrit par Daniel J. Abadi  PACELC introduit deux modes de fonctionnement distincts pour les systèmes distribués :    (   ) : quel compromis le système fait-il lorsqu'un partitionnement se produit ? Nous revisitons ici le compromis classique du CAP entre   et   . Mode de partitionnement PAC disponibilité (A) cohérence (C)    (   ) : quel compromis le système fait-il lorsqu'il n'y a pas de partition et que le réseau fonctionne normalement ? Dans ce mode, le système fait face à un compromis différent : entre   et   .  Mode Else ELC latence (L) cohérence (C)  Le compromis entre latence et cohérence  Bien que les partitions soient inévitables dans les systèmes distribués, elles sont rares par rapport aux défis qui se posent pendant le fonctionnement normal. Dans les systèmes distribués modernes,   constitue souvent un goulot d'étranglement plus important que les partitions réseau, en particulier pour les applications à l'échelle mondiale. C'est là que   se concentre, en abordant les compromis qui se produisent lorsque le système fonctionne sans partitions. Contrairement à CAP, qui se concentre uniquement sur le comportement lors de scénarios de défaillance, PACELC met l'accent sur les décisions que les architectes doivent prendre chaque jour pour équilibrer   et   : la latence PACELC la latence (L) la cohérence (C)    nécessite une coordination et une synchronisation entre les nœuds pour maintenir une vue unifiée des données. Cette surcharge entraîne des retards, ce qui ralentit les temps de réponse. Une cohérence forte    (comme ceux qui adoptent la cohérence à terme) privilégient la vitesse en assouplissant les garanties de cohérence. Ces systèmes répondent plus rapidement mais peuvent parfois renvoyer des données obsolètes ou incohérentes. Les systèmes à faible latence  En étendant la conversation au-delà des partitions pour inclure le fonctionnement normal, PACELC garantit que les performances quotidiennes des systèmes distribués sont traitées avec l’importance qu’elles méritent.  Pour conclure  La formulation du théorème CAP a été un événement important dans la communauté, et les études sur son impact sur la conception des systèmes distribués ont montré que les concepteurs de systèmes distribués ne devraient pas limiter le système à deux propriétés - ils devraient s'efforcer de maximiser les garanties requises dans chaque cas particulier. À cette fin, il est raisonnable de diviser le système en segments, chacun ayant ses propres exigences, et de concevoir le système en fonction des exigences de chacun des segments.  Le théorème CAP est depuis des décennies une pierre angulaire de la réflexion sur les systèmes distribués. Il nous a fourni un cadre pour raisonner sur les compromis inhérents à la cohérence, à la disponibilité et à la tolérance de partition. Mais à bien des égards, il s'agit d'une simplification de la réalité, supposant des choix binaires et ignorant des facteurs critiques comme la latence.  PACELC s'appuie sur le CAP, reconnaissant que :   Des compromis existent même lorsque les partitions n’existent pas.    dans la conception de systèmes distribués. La latence est une préoccupation de premier ordre  CAP et PACELC sont tous deux des outils précieux, mais aucun des deux ne constitue une recette étape par étape pour la création de systèmes. Au contraire, ils fournissent   permettant d'évaluer les compromis et de comprendre les limites des architectures distribuées. des modèles mentaux  Documents supplémentaires   La PAC, douze ans après : comment les « règles » ont changé   Cassandra : Le guide ultime    et  S'il vous plaît, arrêtez d'appeler les bases de données CP ou AP Une critique du théorème CAP par Martin Kleppmann   Notes sur les systèmes distribués pour les jeunes sangs   Merci de votre lecture !   Vous êtes curieux de quelque chose ou vous avez des idées à partager ? Laissez votre commentaire ci-dessous ! Consultez   ou suivez-moi via   ,   , ou   . mon blog LinkedIn Substack Telegram

Subscribe

Buy My Book

Cet audio est produit dans la langue originale de l'histoire !

Pourquoi les systèmes distribués ne peuvent pas tout avoir

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps