Revenons au fond de ce que la cohérence, la disponibilité et la tolérance de partition signifient réellement dans les systèmes distribués de production. Bonjour les gens, je suis de retour. je n'ai pas posté depuis un certain temps, je sais, je le sais. Entre le travail, la vie, et l'habituel "est-ce que quelqu'un lit même cela?" doute spirale, je laisse ce blog recueillir de la poussière. Au lieu de publier des messages sporadiques sur des sujets aléatoires, je m’engage à faire des séries de plongées profondes sur des concepts fondamentaux que j’aimerais mieux comprendre plus tôt dans ma carrière. Cette série de quatre parties sur le théorème CAP est la première de nombreuses plongées profondes que j’ai planifiées.Si vous avez déjà ressenti que vous « obtenez » des systèmes distribués en théorie, mais vous avez du mal à appliquer ces connaissances dans la pratique, cette série est pour vous. Merci d'être là (ou simplement de découvrir ce blog). Obtenez la série complète en 4 parties directement dans votre boîte de réception. 
 
 Il s’agit de la première partie d’une série de quatre parties sur le théorème de la PAC et les échanges de systèmes distribués. Il s’agit de la première partie d’une série de quatre parties sur le théorème de la PAC et les échanges de systèmes distribués. Si vous avez été interviewé pour des rôles d'ingénierie de niveau intermédiaire ou supérieur au cours de la dernière décennie, vous avez certainement été posé une question de conception de systèmes qui conduit finalement à une version du théorème CAP. Et vous avez probablement répondu quelque chose le long des lignes de "vous ne pouvez choisir que deux sur trois". Bien qu'il soit techniquement correct, l'idée derrière elle est grotesquement sur-simplifiée.Cette sur-simplification revient pour vous mordre lorsque vous dépannez la raison pour laquelle votre entrepôt de données distribuée est tombé. Mon objectif est de démystifier ce que nous dit le théorème de la PAC et d’expliquer comment les systèmes de production contournent ce «pick two» crunch. Qu’est-ce que le théorème CAP ? Revenons au tournant du siècle, en 2000. Inktomi Corporation, qui a ensuite dirigé Inktomi Corporation, s’est tenu au podium du symposium PODC d’ACM et a fait une déclaration qui perturberait les développeurs pendant des décennies : un entrepôt de données distribué ne peut garantir que deux des trois éléments suivants : la cohérence, la disponibilité et la tolérance des partitions. par Eric Brewer Quelques années plus tard, le théorème de Brewer a été formalisé en preuve par Seth Gilbert et Nancy Lynch. Le théorème, l’idée derrière lui, tout est vrai. Eh bien, tout le monde se souvient de la partie « choisissez deux » de la conjecture, mais ils laissent presque toujours le contexte le plus important à part : . you only have to pick two   a network partition pendant pendant Le théorème fournit des conseils uniquement lorsque les choses vont mal – lorsque vous commencez à perdre des paquets réseau, ou lorsque les commutateurs échouent, ou lorsque un rongeur mâche à travers une ligne de fibre (c’est ce qui s’est réellement passé chez Amazon). Théorème CAP : Consistance, disponibilité et tolérance de partition Soyons super précis sur ce que C, A et P sont réellement et ce qu'ils signifient, parce que les définitions occasionnelles manquent un peu de nuance. Qu’est-ce que la cohérence dans le théorème CAP ? (linéarisabilité) Lorsque le théorème de la PAC parle de cohérence, il parle de la plus haute forme de cohérence, Si vous venez d'un fond de base de données, vous avez entendu parler de la cohérence faible et forte. la cohérence atomique est juste un pas au-dessus de la cohérence forte. la cohérence atomique est également connue comme . cohérence atomique linéarisation linéarisation L’exécution de toutes les opérations est linéaire Par exemple, si l'opération A se termine avant l'opération B commence, alors l'opération B devrait logiquement prendre effet après l'opération A. Atomique Utilisons un exemple du monde réel pour illustrer cette idée. Imaginez que vous vérifiez le solde de votre compte bancaire et que vous voyez 5000 $. Supposons que vous transférez 1000 $ du compte. 4 000 $ (ou une erreur), mais jamais 5 000 $ de nouveau. Le transfert s'est produit ou non. Il n'y a pas de situation dans laquelle vous verrez l'ancienne valeur après que la nouvelle valeur ait été écrite. Garanties Garanties Signez maintenant Ceci est plus fort que "tous les nœuds voient finalement les mêmes données" - cela s'appelle et ce De quoi parle le théorème de la PAC ? a lot Une éventuelle cohérence is NOT Parce qu'il existe un tas de systèmes qui fournissent des modèles de cohérence plus faibles, tels que: lectures monotones, lectures de votre écriture et cohérence causale, tout en étant extrêmement utiles. Le théorème CAP ne limite pas les systèmes à utiliser ces modèles, seulement la linéarisabilité. Très disponible Qu’est-ce que la disponibilité dans le théorème CAP ? La définition de la disponibilité de CAP est également très précise, elle indique « toute demande à un nœud non-défaillant » recevoir une réponse. » doit Veuillez noter que cela ne signifie pas l'un des éléments suivants : 
 
 
 
 La réponse doit être rapide. La réponse doit être correcte. La plupart des nœuds doivent répondre. Par exemple, si vous avez un cluster de 10 nœuds et que 4 de ces nœuds sont partis, ces 4 nœuds toujours répondre aux demandes à être considérées comme « disponibles » selon la définition de « disponibilité » de la CAP. Dans ce cas, une erreur 4xx ou une lecture stable est toujours considérée comme « disponible ». must Voici un exemple du monde réel : pendant une partition réseau, un ensemble de répliques primaires de MongoDB qui ne peut pas atteindre toutes les répliques secondaires va « descendre » et refuser les écrits du tout. Le processus MongoDB fonctionne comme prévu. unavailability Qu’est-ce que la tolérance de partition ? (et pourquoi vous ne pouvez pas l’éviter) C’est là qu’intervient le « Pick Two ». La tolérance de partition signifie que votre système continue de fonctionner comme annoncé même lorsque le réseau divise vos nœuds en groupes qui ne peuvent pas communiquer. Les partitions réseau sont un fait de la vie dans les systèmes distribués.L'Internet sur lequel nous comptons quotidiennement, les centres de données qui servent nos applications ont tous cette propriété.Les commutateurs échouent, les fibres se coupent, les fournisseurs de cloud ont des interruptions de la zone de disponibilité, les paquets tombent, même au sein d'un centre de données il y a des problèmes de réseau transitoires. La réalité est, Vous ne choisissez pas entre C, A et P. Vous choisissez vraiment entre C et A quand P se produit inévitablement. partition tolerance is absolutely mandatory Le véritable trade-off Regardons ce qui se passe lorsque le réseau échoue. Avant de le faire, reprenons le théorème CAP et ses choix étant donné que P (Tolérance de partition) est absolument obligatoire: 
 
 
 Conséquence : refuser les demandes qui pourraient renvoyer des données obsolètes (sacrifier la disponibilité) Disponibilité : répondre à toutes les demandes même si les données sont obsolètes (sacrifier la cohérence) Encore une fois, prenez note de la condition préalable : « le réseau échoue ». Si le réseau est bon, nous pouvons avoir à la fois la cohérence et la disponibilité. Quand il n'y a pas de partition? Vous pouvez avoir les deux. L'application mobile de votre banque vous montre des soldes précis et à jour tout en restant hautement disponible - car la plupart du temps, le réseau fonctionne bien. Vous vérifiez votre solde, transférez de l'argent et voyez le montant mis à jour immédiatement. Quand La question que le théorème de la PAC vous oblige à aborder est : What should your system do when the network eventually fails? Le compromis de base: Pendant une partition, les systèmes CP vous protègent de voir les données erronées en devenant indisponibles. les systèmes AP vous protègent des temps d'arrêt en servant potentiellement des données stables. Systèmes CP: Choisir la cohérence par rapport à la disponibilité Les systèmes CP décident qu’au cours d’une partition réseau, ils refuseront les demandes plutôt que de risquer de retourner des données obsolètes. Quand cela a-t-il du sens ? 
 
 
 Banques: Si un utilisateur effectue une transaction, est-il préférable d'être en bas pour un peu ou de risquer que la transaction se produise deux fois? Probablement la première, non? Nous ne voulons absolument pas dire au client que la transaction a réussi quand elle n'a pas. Gestion des stocks : Si nous ne sommes pas sûrs si un article est en stock, est-il préférable de rendre le service indisponible ou d’autoriser la possibilité d’une vente excessive ? Analysons le monde réel, De leur propre site Web: «etcd est un magasin de valeur clé fortement cohérent, distribué... Il gère gracieusement les élections de leader pendant les partitions réseau et peut tolérer l'échec de la machine, même dans le nœud leader. » etcd Kubernetes utilise etcd comme magasin de sauvegarde pour toutes les configurations de cluster. Si vous avez déjà utilisé Kubernetes, vous avez vu Une des raisons : etcd ne peut pas atteindre la majorité de ses nœuds, il sacrifie la disponibilité ( pour la linéarisation. kubectl kubectl Systèmes AP: Choisir la disponibilité par rapport à la cohérence Les systèmes AP décident qu’au cours d’une partition réseau, ils risquent de servir des données obsolètes plutôt que de refuser les demandes. Quelques systèmes pour lesquels cela s’applique : 
 
 
 Réseaux sociaux: les utilisateurs préfèrent beaucoup que l'application serve du contenu ancien / ancien plutôt que d'être complètement indisponible.En outre, est-ce vraiment important si un utilisateur ne voit pas une réaction à leur message pendant quelques secondes? Cartes d'achat: Un exemple très célèbre de cela est le DynamoDB d'Amazon, qui a effectivement commencé à traiter le problème de leur panier d'achat; c'est une expérience « toujours en marche ». Pour un système AP réel, vous n’avez pas à penser très dur, le système AP le plus pur n’est rien d’autre que le DNS lui-même. DNS, le système de noms de domaine, est l’exemple parfait d’un système AP, et nous l’utilisons tous des centaines de fois par jour sans même s’en rendre compte. Lorsqu'un enregistrement DNS est mis à jour, la mise à jour ne se propage pas immédiatement à tous les serveurs DNS du monde entier. , DNS n'est jamais "indisponible". Il vous donnera toujours une réponse, même si cette réponse est stable. C'est précisément pourquoi les mises à jour DNS prennent du temps et pourquoi certains sites semblent indisponibles à quelques personnes lorsqu'elles passent par des mises à jour. Dans le cas de DNS, la cohérence finale est absolument meilleure que les temps d'arrêt, ce qui tuerait Internet. however Suivant: Les coûts cachés du choix de la cohérence Dans la prochaine partie de cette série, nous allons plonger profondément dans les systèmes CP – des bases de données et des services qui priorisent la cohérence par rapport à la disponibilité lors d’échecs du réseau. 
 
 
 
 Comment ces systèmes CP mettent en œuvre une forte cohérence. Le coût de la coordination. Lorsque vous choisissez la cohérence sur la disponibilité, cela a du sens. Le «pick two» donne l’illusion d’être coincé avec votre choix pendant toute la durée de vie du système, alors que la réalité est en fait beaucoup plus flexible. Inscrivez-vous pour recevoir la partie 2 quand elle tombe. Merci encore pour le lien.Si vous avez apprécié ce post, s'il vous plaît souscrivez, car il me donne la confiance de continuer. Ali Références 
 
 
 
 Présentation 2000 PODC de Eric Brewer La conjecture de Brewer et la faisabilité de services Web cohérents, disponibles et tolérants aux partitions de Nancy Lynch et Seth Gilbert etcd

This story contains new, firsthand information uncovered by the writer.

Subscribe to my Blog

Newsletter

Read My Stories

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

Le théorème du CAP expliqué, Partie 1 : Le problème avec le "Pick Two"

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

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

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

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

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

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

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps