Cohérence des données : concepts de base et stratégies de mise en œuvre

À l’ère de l’information d’aujourd’hui, les données sont devenues l’un des principaux actifs des entreprises. Cependant, à mesure que la quantité de données continue d’augmenter et que les scénarios d’application continuent de se développer, garantir la cohérence des données est devenu un défi important. La cohérence des données n'est pas seulement liée à l'exactitude et à la fiabilité du système, mais affecte également directement l'expérience utilisateur et les résultats commerciaux de l'entreprise. Par conséquent, il est essentiel que toute personne engagée dans un travail lié aux données ait une compréhension approfondie des concepts fondamentaux de cohérence des données et maîtrise diverses stratégies de mise en œuvre.

Dans cet article, nous présenterons d'abord les concepts de base de la cohérence des données, notamment la cohérence forte, la cohérence faible, la cohérence éventuelle, etc., et expliquerons leur signification et leur différence à travers des exemples spécifiques. Ensuite, nous approfondirons diverses théories distribuées, notamment les théories CAP, ACID et BASE.

J'espère que cet article pourra aider les lecteurs à mieux comprendre l'importance de la cohérence des données et comment atteindre et garantir efficacement la cohérence des données dans le travail réel.

Annuaire d'articles

1. Introduction à la cohérence des données

1.1. Notion de cohérence des données

La cohérence des données signifie que les données peuvent atteindre l'état attendu après une série d'opérations. Dans une base de données, la cohérence signifie généralement que les données satisfont à certaines contraintes, telles que les contraintes de clé étrangère et les contraintes d'unicité dans les bases de données relationnelles.

Dans les systèmes distribués, la question de la cohérence des données est plus complexe. Étant donné que les données peuvent être copiées sur plusieurs nœuds, lorsque les données changent sur un certain nœud, il faut s'assurer que ce changement peut être vu par tous les autres nœuds. C'est le problème de cohérence des données dans les systèmes distribués.

1.2. Le rôle de la cohérence des données

Le maintien de la cohérence des données dans les systèmes distribués est un problème important pour les raisons suivantes :

Exactitude des données : la cohérence des données est la base pour garantir l’exactitude des données. Si les données d'un système distribué sont incohérentes, les utilisateurs peuvent voir des données incorrectes ou prendre des décisions incorrectes basées sur des données incorrectes.
Disponibilité du système : si les données du système distribué sont incohérentes, certaines opérations peuvent ne pas être effectuées, affectant ainsi la disponibilité du système. Par exemple, si une opération nécessite la lecture et l’écriture de données qui ne sont pas dans le même état, elle risque de ne pas s’exécuter correctement.
Continuité des activités : dans certains scénarios commerciaux, la cohérence des données est indispensable. Par exemple, dans les systèmes de commerce électronique, la cohérence des stocks est la base pour garantir un traitement correct des commandes.

Par conséquent, la manière de maintenir la cohérence des données dans les systèmes distribués est une question importante dans la conception de systèmes distribués.

2. Modèle de cohérence des données

Le modèle de cohérence des données est un concept important dans les systèmes distribués, qui détermine la manière dont les données restent cohérentes sur plusieurs nœuds. Différents modèles de cohérence ont différentes caractéristiques et scénarios applicables, notamment une cohérence forte, une cohérence linéaire, une cohérence causale, une cohérence de session, une cohérence éventuelle, une cohérence de lecture monotone, une cohérence d'écriture monotone, une cohérence d'écriture et une cohérence d'écriture.Suivez la cohérence de lecture, etc. Comprendre ces modèles de cohérence peut nous aider à mieux concevoir et comprendre les systèmes distribués.

2.1. Modèle de cohérence forte

Une cohérence forte est un modèle de cohérence des données qui nécessite que le système affiche la même vue des données à tous les opérateurs à tout moment. Plus précisément, une fois qu'un élément de données a été mis à jour, toutes les opérations de lecture ultérieures renverront cette nouvelle valeur. Cela signifie que s'il existe plusieurs réplicas, tous les réplicas doivent être mis à jour simultanément lors d'une opération de mise à jour.

L’avantage d’une forte cohérence est qu’elle fournit un modèle de programmation très intuitif et simple, car tous les opérateurs voient la même vue des données et n’ont pas besoin de gérer les incohérences des données. Ceci est très important dans certains scénarios qui nécessitent une stricte cohérence des données (comme les virements bancaires).

Cependant, l’inconvénient d’une cohérence forte est qu’elle nécessite généralement un coût de performance important pour sa mise en œuvre dans un environnement distribué. Car lorsque vous effectuez une opération de mise à jour, vous devez attendre que toutes les répliques soient mises à jour, ce qui entraînera une diminution du débit du système et du temps de réponse. De plus, si une copie ne peut pas être mise à jour à temps en raison de problèmes ou de pannes de réseau, l'ensemble du système peut être bloqué, affectant la disponibilité du système.

Le modèle de cohérence forte comprend une cohérence linéaire et une cohérence séquentielle. Le premier a des contraintes de sécurité plus fortes et constitue la meilleure cohérence pouvant être garantie dans un système distribué.

2.2. Modèle de cohérence linéaire

La linéarisabilité est un modèle de cohérence forte, également connu sous le nom de cohérence atomique. Cela nécessite que pour tout nœud, toute opération ait un ordre fixe globalement et que tous les nœuds observent toutes les opérations dans cet ordre.

Plus précisément, la cohérence linéaire présente les caractéristiques suivantes :

L'ordre des opérations est cohérent avec l'ordre dans lequel elles se produisent réellement : si une opération se termine avant une autre, tout observateur verra en premier les résultats de la première opération.
Les résultats de l'opération sont immédiatement visibles par tous les nœuds : une fois l'opération terminée, toutes les opérations de lecture ultérieures renverront cette nouvelle valeur.

La cohérence linéaire fournit un modèle de programmation très intuitif et simple car tous les opérateurs voient la même vue des données et n'ont pas besoin de gérer les incohérences des données. Cependant, obtenir une cohérence linéaire nécessite un coût de performances important, car lors de l'exécution d'une opération de mise à jour, vous devez attendre que toutes les répliques soient mises à jour, ce qui entraînera une diminution du débit et du temps de réponse du système.

Par exemple, supposons que nous ayons deux nœuds. Le nœud A effectue d'abord l'opération d'écriture A (écriture des données x = 1), puis le nœud B effectue l'opération de lecture B.

Dans le modèle de cohérence linéaire, chaque fois que le nœud B effectue l'opération de lecture B, il doit lire les données x=1.

La mise en œuvre de modèles de cohérence linéaire repose généralement sur des technologies de traitement de transactions distribuées, telles que la validation en deux phases (2PC), la validation en trois phases (3PC), etc. De plus, les algorithmes de consensus tels que Paxos et Raft peuvent également atteindre une cohérence linéaire.

2.3. Modèle de cohérence de séquence

La cohérence séquentielle est un type de modèle de cohérence forte. La cohérence de la séquence nécessite que l'ordre des opérations vues par tous les nœuds soit cohérent, même si cet ordre n'a pas besoin d'être cohérent avec l'ordre d'occurrence réel. Cela signifie que toutes les opérations de lecture verront les résultats des dernières opérations d'écriture, à condition que ces écritures soient terminées avant l'opération de lecture. Par conséquent, la cohérence des séquences répond à la définition d’une cohérence forte, c’est-à-dire que le système affiche à tout moment la même vue des données à tous les opérateurs.

Plus précisément, la cohérence des séquences présente les caractéristiques suivantes :

Ordre global : toutes les opérations sont dans un ordre global et tous les nœuds observent toutes les opérations dans cet ordre.
Ordre de lecture et d'écriture : si une opération d'écriture se termine avant une opération de lecture, l'opération de lecture doit renvoyer le résultat de l'opération d'écriture.

La cohérence des séquences fournit un modèle de programmation relativement simple car tous les opérateurs voient le même ordre des opérations. Cependant, parvenir à la cohérence des séquences a un coût en termes de performances, car l'ordre global des opérations doit être maintenu.

Supposons maintenant que nous ayons deux opérations : l’opération A consiste à écrire des données et l’opération B consiste à lire des données.

Dans le modèle de cohérence linéaire, si l'opération A se termine avant l'opération B, alors l'opération B doit être capable de lire les données écrites par l'opération A, quel que soit le nœud sur lequel les deux opérations ont eu lieu. Cela nécessite que le système maintienne une séquence cohérente d’opérations à l’échelle mondiale.

Par exemple, supposons que nous ayons deux nœuds. Le nœud A effectue d'abord l'opération d'écriture A (écriture des données x = 1), puis le nœud B effectue l'opération de lecture B.

Dans le modèle de cohérence séquentielle, il est seulement requis que l'ordre des opérations vues par tous les nœuds soit cohérent, mais il n'exige pas que cet ordre soit cohérent avec l'ordre d'occurrence réel. Cela signifie que si le nœud A effectue d'abord une opération d'écriture A, puis que le nœud B effectue une opération de lecture B, le nœud B risque de ne pas être en mesure de lire les données x=1, car du point de vue du nœud B, l'opération de lecture B peut effectuer une opération d'écriture A qui s'est produite auparavant.

Par conséquent, les modèles de cohérence linéaire offrent des garanties de cohérence plus fortes que les modèles de cohérence séquentielle.

La mise en œuvre du modèle de cohérence de séquence repose généralement sur des technologies telles que les verrous distribués ou les horodatages pour garantir la cohérence de l'ordre des opérations vu par tous les nœuds.

2.4. Modèle de cohérence faible

La faible cohérence est un modèle de cohérence des données qui n'exige pas que le système affiche la même vue des données à tous les opérateurs à tout moment. Plus précisément, une fois qu'un élément de données a été mis à jour, les opérations de lecture ultérieures peuvent renvoyer des données plus anciennes pendant un certain temps jusqu'à ce que toutes les répliques aient été mises à jour.

L’avantage d’une cohérence faible est qu’elle peut fournir des performances et une disponibilité plus élevées dans un environnement distribué. Parce que lors de l'exécution d'une opération de mise à jour, il n'est pas nécessaire d'attendre que toutes les répliques soient mises à jour et les résultats peuvent être renvoyés immédiatement, ce qui peut améliorer le débit et le temps de réponse du système. De plus, même si une copie ne peut pas être mise à jour à temps en raison de problèmes ou de pannes de réseau, cela n'affectera pas la disponibilité du système.

Cependant, l’inconvénient d’une faible cohérence est que le modèle de programmation est plus complexe et que l’application doit gérer seule l’incohérence des données. Par exemple, si un opérateur lit l'ancienne valeur d'un élément de données, il peut devoir attendre un certain temps ou adopter une stratégie (comme réessayer) pour obtenir la nouvelle valeur. Cela peut entraîner des problèmes dans certains scénarios qui nécessitent une grande cohérence des données (comme les mises à jour des cercles d'amis sur les réseaux sociaux).

Le modèle de cohérence faible n'a pas d'algorithme de mise en œuvre spécifique. Il s'agit plutôt d'un principe de conception du système, c'est-à-dire que le système permet aux données d'être incohérentes pendant un certain temps. Dans les systèmes réels, une faible cohérence est généralement obtenue grâce à certaines stratégies de réplication (telles que la cohérence éventuelle).

. Le modèle de cohérence faible est un concept large qui inclut une variété de modèles de cohérence spécifiques, notamment des modèles de cohérence causale et des modèles de cohérence éventuelle.

2.5. Modèle de cohérence causale

La cohérence causale est un modèle de cohérence des données qui est plus faible que la cohérence des séquences mais plus fort que la cohérence faible. Dans le modèle de cohérence causale, seules les opérations causalement pertinentes doivent rester en ordre, et les opérations causalement non pertinentes peuvent être dans n'importe quel ordre.

Plus précisément, si une opération A affecte une autre opération B (par exemple, l'opération A est une opération d'écriture, l'opération B est une opération de lecture et les données écrites par A sont lues), alors nous disons que A et B sont causalement liés. Dans le modèle de cohérence causale, tous les opérateurs voient l’ordre correct des opérations causalement liées. Cependant, pour des opérations sans lien causal, différents opérateurs peuvent voir des séquences différentes.

L’avantage de la cohérence causale est qu’elle peut fournir des performances supérieures à la cohérence de séquence, tout en conservant la garantie de cohérence de la causalité. Parce que lors de l'exécution d'une opération de mise à jour, il n'est pas nécessaire d'attendre que toutes les répliques soient mises à jour et les résultats peuvent être renvoyés immédiatement, ce qui peut améliorer le débit et le temps de réponse du système. Dans le même temps, puisque seul l’ordre des opérations causalement liées doit être garanti, les performances peuvent être encore améliorées.

Cependant, l’inconvénient de la cohérence causale est que le modèle de programmation est plus complexe et que l’application doit gérer elle-même l’ordre des opérations. Par exemple, si un opérateur effectue une série d'opérations dans une séquence, mais que l'ordre des opérations vu par les autres opérateurs peut être incompatible avec l'ordre réel des opérations, cela peut entraîner certains problèmes.

La mise en œuvre de modèles de cohérence causale s'appuie généralement sur des technologies telles que Vector Clock ou Version Vector pour garantir l'ordre des opérations causalement liées.

2.6. Modèle de cohérence final

La cohérence éventuelle est un modèle de cohérence des données, qui constitue un cas particulier de faible cohérence. Dans le modèle de cohérence éventuel, le système ne garantit pas que la même vue des données sera affichée à tout moment pour tous les opérateurs, mais il garantit qu'en l'absence de nouvelles mises à jour des données, toutes les copies finiront par atteindre un état cohérent.

Plus précisément, une fois qu'un élément de données a été mis à jour, les opérations de lecture ultérieures peuvent renvoyer des données plus anciennes pendant un certain temps jusqu'à ce que toutes les répliques aient été mises à jour. Ce processus peut prendre un certain temps, mais une fois toutes les répliques mises à jour, tous les opérateurs verront la même vue des données.

L'avantage de la cohérence éventuelle est qu'elle peut fournir des performances et une disponibilité supérieures dans un environnement distribué, tout en garantissant la cohérence des données. Parce que lors de l'exécution d'une opération de mise à jour, il n'est pas nécessaire d'attendre que toutes les répliques soient mises à jour et les résultats peuvent être renvoyés immédiatement, ce qui peut améliorer le débit et le temps de réponse du système. De plus, même si une copie ne peut pas être mise à jour à temps en raison de problèmes ou de pannes de réseau, cela n'affectera pas la disponibilité du système.

La cohérence finale a été appliquée dans de nombreux systèmes pratiques, tels que les systèmes DNS, le système Dynamo d'Amazon et de nombreuses bases de données NoSQL (telles que Redis, MongoDB, etc.). Ces systèmes doivent généralement gérer un grand nombre de requêtes de lecture et d'écriture, ont des exigences élevées en matière de performances et de disponibilité, et des exigences relativement faibles en matière de cohérence des données.

Par exemple, supposons que nous ayons un système distribué avec deux nœuds : le nœud A et le nœud B. Maintenant, nous effectuons une opération d'écriture sur le nœud A, en changeant la valeur de l'élément de données x de 0 à 1. Une fois cette opération d'écriture terminée, la valeur de l'élément de données x sur le nœud A est devenue 1, mais la valeur de l'élément de données x sur le nœud B peut toujours être 0, car le résultat de l'opération d'écriture n'a pas encore été propagé au nœud B. . Par conséquent, si nous effectuons une opération de lecture ultérieure sur le nœud B, l'opération de lecture peut lire l'ancienne valeur de l'élément de données x, 0, au lieu de la nouvelle valeur de 1.

Ps : Des amis attentifs peuvent constater que dans le même exemple, les résultats du « modèle de cohérence séquentielle » et du « modèle de cohérence éventuelle » sont les mêmes, mais pourquoi le premier appartient-il à une cohérence forte et le second à une cohérence faible ? C'est parce que les deux définitions de « l'opération d'écriture est considérée comme terminée » sont différentes.

Dans un modèle de cohérence forte, tel qu'un modèle de cohérence linéaire, une opération d'écriture est considérée comme terminée si et seulement si l'opération d'écriture a été appliquée à toutes les répliques, c'est-à-dire que tous les nœuds ont vu le résultat de l'opération d'écriture.

Cependant, dans un modèle de cohérence faible, tel qu'un modèle de cohérence éventuelle, une opération d'écriture peut être considérée comme terminée tant que l'opération d'écriture a été appliquée à une réplique, même si les autres répliques n'ont pas encore vu le résultat de l'opération d'écriture. . . Dans ce cas, les autres nœuds devront peut-être attendre un certain temps pour voir les résultats de l'opération d'écriture.

La mise en œuvre du modèle de cohérence éventuel repose généralement sur certaines stratégies de réplication, telles que la liste de préférences et le hachage cohérent dans le système Dynamo, ainsi que sur certaines technologies de traitement des transactions distribuées telles que TCC, ou sur des protocoles de cohérence tels que ZooKeeper The ZAB et al.

2.7. Autres modèles de cohérence

De plus, il existe certains modèles de cohérence classés en fonction de leurs scénarios, tels que :

Cohérence de la session : dans la même session, le client peut lire les données qu'il a écrites auparavant. C'est-à-dire qu'une fois qu'un client écrit de nouvelles données, toutes les opérations de lecture ultérieures peuvent lire ces nouvelles données dans la même session.
Cohérence de lecture monotone : si un nœud lit une fois une certaine valeur d'un élément de données du système, il peut au moins lire cette valeur lors des opérations de lecture ultérieures. En d'autres termes, le nœud lit la valeur de l'élément de données obtenu ne sera pas roulé dos.
Cohérence d'écriture monotone : le système exige que les opérations d'écriture sur un nœud soient effectuées dans l'ordre dans lequel elles se produisent. C'est-à-dire que pour deux opérations d'écriture, si elles se produisent dans un certain ordre sur un nœud, alors l'ordre d'exécution de celles-ci deux opérations d'écriture sont les mêmes sur tous les nœuds.
Cohérence de lecture de vos écritures : le système garantit qu'un nœud peut lire les dernières données qu'il a écrites auparavant. C'est-à-dire que si un nœud écrit une nouvelle valeur d'un élément de données, alors lors d'une opération de lecture ultérieure, ce nœud peut au moins lire cette nouvelle valeur.
Cohérence des écritures-suivi-lectures : si un nœud a lu une certaine valeur d'un élément de données du système, alors lors des opérations d'écriture ultérieures, ce nœud peut au moins écrire une valeur supérieure ou égale à cette nouvelle valeur de la valeur, c'est-à-dire que la valeur de l'élément de données écrit par le nœud ne sera pas annulée.

3. Introduction à la théorie de la PAC

3.1. Introduction à la théorie de la PAC

La théorie CAP, également connue sous le nom de protocole CAP, fait référence au fait que dans un système distribué, « Cohérence », « Disponibilité » et « Tolérance de partition » ne peuvent être satisfaites qu'en même temps. Il est impossible de prendre en charge deux des trois éléments.

Concernant la cohérence : Dans la théorie de la PAC, la cohérence fait généralement référence à une forte cohérence. Dans la théorie CAP, la cohérence signifie que les données vues par tous les nœuds du système distribué en même temps sont cohérentes. C'est-à-dire que pour tout nœud, toute opération a un ordre global fixe, et tous les nœuds observent toutes les opérations dans cet ordre. commande;

Concernant la disponibilité : Dans la théorie CAP, la disponibilité (Availability) fait généralement référence à : « Les lectures et écritures réussissent toujours », c'est-à-dire « le service est toujours disponible dans le temps de réponse normal ». Une bonne disponibilité signifie principalement que le système peut bien servir les utilisateurs sans provoquer une mauvaise expérience utilisateur telle qu'une défaillance des opérations de l'utilisateur ou un délai d'attente d'accès. Disponibilité Généralement, la disponibilité est étroitement liée à la redondance des données distribuées, à l'équilibrage de charge, etc. ;

Concernant la tolérance de partition : dans la théorie CAP, la tolérance de partition fait généralement référence à : « Le système continue de fonctionner malgré la perte de message arbitraire ou la défaillance d'une partie du système », c'est-à-dire « le système distribué rencontre un certain Lorsqu'un nœud ou une partition réseau échoue , il peut toujours fournir des services externes répondant aux exigences de cohérence ou de disponibilité" ;

Explication de la partition réseau : Par exemple, il y a deux serveurs (Serveur A, Serveur B) et il y a une communication entre eux. Cependant, soudainement, pour des raisons d'emplacement, la liaison réseau entre les deux est interrompue, provoquant l'arrêt des deux serveurs. sur le même réseau. "Serveur A" et "Serveur B" ont des partitions réseau, devenant "Réseau A" où se trouve le "Serveur A" et "Réseau B" où se trouve le "Serveur A".

La tolérance de partition signifie que plusieurs serveurs d'un service de données peuvent toujours continuer à fournir des services lorsque la situation ci-dessus se produit (partition réseau) !

3.2. Preuve du scénario de base de la théorie de la PAC

Vient ensuite la preuve de la théorie CAP. Ce qui suit est un scénario de base d'un système distribué : il y a deux nœuds Node1 et Node2 dans le réseau (vous pouvez simplement comprendre que Node1 et Node2 sont respectivement deux ordinateurs), et le réseau entre les deux peut être connecté. , Il y a une « Application A » et une « Base de données A » dans Node1, et Node2 a également une « Application B » et une « Base de données B ». Désormais, « Application A » et « Application B » sont deux parties du système distribué, et « Base de données A » et « Base de données B » sont deux sous-bases de données du stockage de données du système distribué.

Lorsque la cohérence est atteinte : les données de Node1 et Node2 sont les mêmes, V0=V0.
Lorsque la disponibilité est satisfaite : les utilisateurs recevront une réponse immédiate, qu'ils demandent Node1 ou Node2.
Lorsque la tolérance aux pannes de partition est respectée : lorsque Node1 ou Node2 tombe en panne ou que le réseau est indisponible, le fonctionnement normal de Node1 et Node2 ne sera pas affecté.

3.3. Preuve du fonctionnement normal du CAP

La figure suivante représente le processus de fonctionnement normal du système distribué. L'utilisateur demande la mise à jour des données à partir de la machine Node1. Le programme A met à jour la base de données V0 vers V1. Le système distribué synchronise les données M et synchronise V1 avec V0 dans Node2 afin que les données dans Node2, V0 est également mis à jour vers V1 et les données de Node2 répondent à la demande de Node2.

Ici, vous pouvez définir si les données entre la base de données V de Node1 et Node2 sont identiques en termes de cohérence ; la réponse à la demande externe à Node1 et Node2 est la disponibilité ; l'environnement réseau entre Node1 et Node2 est la tolérance aux pannes de partition.

3.4. Preuve de l'anomalie théorique du CAP

Il s'agit d'un scénario de fonctionnement normal et d'un scénario idéal. Cependant, la réalité est cruelle : lorsqu'une erreur se produit, la cohérence, la disponibilité et la tolérance de partition peuvent-elles être satisfaites en même temps, ou y a-t-il un compromis ?

En tant que système distribué, la plus grande différence entre celui-ci et un système autonome est le réseau. Supposons maintenant une situation extrême, le réseau entre le nœud 1 et le nœud 2 est déconnecté. Nous devons prendre en charge cette anomalie du réseau, ce qui équivaut à rencontrer une erreur de partition. tolérance : peut-elle satisfaire à la fois cohérence et réactivité ? Ou devrions-nous faire un choix entre eux ?

Supposons que lorsque le réseau entre le nœud 1 et le nœud 2 est déconnecté, un utilisateur envoie une demande de mise à jour des données au nœud 1, puis les données V0 du nœud 1 seront mises à jour vers V1. Puisque le réseau est déconnecté, le système distribué fonctionne de manière synchrone, donc les données dans Node2 est toujours V0 ; à ce moment-là, un utilisateur envoie une demande de lecture de données à Node2. Comme les données n'ont pas été synchronisées, l'application ne peut pas renvoyer immédiatement les dernières données V1 à l'utilisateur. Que dois-je faire ?

Il existe deux options :

Premièrement, sacrifiez la cohérence des données et répondez aux anciennes données V0 à l'utilisateur ;
Deuxièmement, la disponibilité est sacrifiée, bloquant et attendant que la connexion réseau soit restaurée et que l'opération de mise à jour des données M soit terminée, puis les dernières données V1 sont répondues à l'utilisateur.

Ce processus prouve que pour qu'un système distribué satisfasse à la tolérance aux pannes de partition, on ne peut en choisir qu'une parmi la cohérence et la disponibilité.

3.5. Les compromis de la théorie de la PAC

Grâce à la théorie CAP, nous savons que les trois caractéristiques de cohérence, de disponibilité et de tolérance de partitionnement ne peuvent être réunies en même temps. Alors, laquelle faut-il abandonner ?

CA sans P : si P n'est pas requis (le partitionnement n'est pas autorisé), C (cohérence forte) et A (disponibilité) sont garantis. Mais en fait, le partitionnement n'est pas un problème auquel vous pensez, mais existera toujours. Par conséquent, le système CA permet à chaque sous-système de rester CA après le partitionnement.
CP sans A : si A (disponible) n'est pas requis, cela signifie que chaque demande doit être fortement cohérente entre les serveurs, et P (partition) entraînera une prolongation indéfinie du temps de synchronisation, de sorte que CP peut également être garanti. De nombreuses transactions distribuées de bases de données traditionnelles s'inscrivent dans ce modèle.
AP sans C : Pour être hautement disponible et permettre le partitionnement, vous devez renoncer à la cohérence. Une fois le partitionnement effectué, les nœuds peuvent perdre le contact. Pour une haute disponibilité, chaque nœud ne peut fournir des services qu'avec des données locales, ce qui entraînera une incohérence globale des données. De nombreux NoSQL entrent désormais dans cette catégorie.

Pour la plupart des scénarios d'application Internet à grande échelle, il existe de nombreux hôtes et déploiements dispersés, et l'échelle actuelle du cluster devient de plus en plus grande, donc les pannes de nœuds et de réseau sont normales, et la disponibilité du service doit être garantie pour atteindre N neuf, c'est-à-dire , P et A sont garantis, jetez C (la meilleure chose à faire est d'assurer une cohérence éventuelle). Même si cela affectera l'expérience client à certains endroits, ce n'est pas suffisamment grave pour provoquer un flux d'utilisateurs.

Pour les scénarios impliquant de l’argent où il ne peut y avoir de compromis, C doit le garantir. En cas de panne du réseau, il est préférable d'arrêter le service, afin de garantir CA et d'abandonner P. Il semble que pas moins de 10 accidents se soient produits dans le secteur bancaire national au cours des dernières années, mais l'impact n'a pas été important, il n'y a pas eu beaucoup de rapports et le grand public en savait peu. Une autre option consiste à garantir CP et à éliminer A. Par exemple, une panne de réseau ne peut que lire mais pas écrire.

4. Introduction à la théorie ACID et à la théorie BASE

4.1. Théorie ACIDE

ACID et BASE sont deux théories courantes de conception de systèmes distribués et représentent deux concepts de conception différents.

ACID peut être compris comme la signification la plus importante d'ACID, qui est l'atomicité et l'isolement, c'est-à-dire la cohérence obligatoire, soit tout faire, soit ne pas le faire, et les données vues par tous les utilisateurs sont cohérentes. Mettre l’accent sur la fiabilité, la cohérence et la disponibilité des données.

ACID fait référence à l'atomicité, à la cohérence, à l'isolement et à la durabilité.

Atomicité : toutes les opérations d'une transaction sont soit complètement terminées, soit non terminées, et ne se termineront pas quelque part au milieu. Si une erreur se produit lors de l'exécution de la transaction, elle sera restaurée à l'état avant le début de la transaction, comme si la transaction n'avait jamais été exécutée ;
Cohérence : l'intégrité de la base de données n'est pas compromise avant le début et après la fin de la transaction. Cela signifie que les données écrites doivent respecter pleinement toutes les règles prédéfinies, y compris l'exactitude et la concaténation des données, et que la base de données ultérieure peut spontanément accomplir le travail prédéterminé ;
Isolation : la base de données permet à plusieurs transactions simultanées de lire, d'écrire et de modifier ses données en même temps. L'isolation peut empêcher l'incohérence des données due à l'exécution croisée lorsque plusieurs transactions sont exécutées simultanément. L'isolation des transactions est divisée en différents niveaux, notamment la lecture non validée, la lecture validée, la lecture répétable, la sérialisation, etc. ;
Durabilité : Une fois la transaction terminée, les modifications apportées aux données sont permanentes et ne seront pas perdues même en cas de panne du système.

4.2. Théorie BASE

La théorie BASE a été proposée par les architectes d'eBay. BASE est le résultat d'un compromis entre cohérence et disponibilité dans le CAP, il est issu de la synthèse des pratiques des systèmes distribués Internet à grande échelle et évolue progressivement sur la base de la loi CAP. L'idée centrale est que même si une cohérence forte ne peut être obtenue, chaque application peut utiliser des méthodes appropriées pour atteindre une cohérence finale dans le système en fonction de ses propres caractéristiques métier.

BASE fait référence à un état fondamentalement disponible, souple et finalement cohérent.

Fondamentalement disponible : le système est toujours disponible, mais dans certains cas, il peut ne fournir que des fonctions partielles. Par exemple, dans le cas de partitions réseau, il ne peut que lire mais pas écrire, ou ne restituer qu'une partie des données ;
État logiciel : l'état du système peut changer pour diverses raisons, telles qu'un retard du réseau, une panne partielle, etc. Le système n'a pas besoin de maintenir la cohérence en temps réel ;
Cohérence à terme : le système garantit que sans nouvelles opérations de mise à jour, toutes les données de réplique finiront par atteindre un état cohérent après un certain temps.

La principale différence entre ACID et BASE est qu'ACID fournit un modèle de cohérence strict, adapté aux scénarios avec des exigences de cohérence très élevées, tels que les virements bancaires. BASE fournit un modèle de cohérence éventuelle, adapté aux scénarios nécessitant une très haute disponibilité, tels que les applications Internet. Dans la conception réelle d’un système, il est nécessaire de peser la relation entre cohérence et disponibilité et de choisir une théorie de conception appropriée basée sur les besoins et les caractéristiques du système.

5. État actuel et perspectives des solutions de cohérence

5.1. Cas d'application pratiques

Voici quelques cas d'application pratiques de grandes sociétés Internet assurant la cohérence des données dans leurs systèmes distribués :

Bigtable de Google : Bigtable est un système de stockage distribué de Google permettant de stocker des données structurées. Bigtable utilise un service de verrouillage distribué appelé Chubby pour garantir la cohérence des données. Chubby fournit un service de verrouillage basé sur l'algorithme Paxos. Bigtable assure la cohérence des données en acquérant des verrous dans Chubby.
Dynamo d'Amazon : Dynamo est un système de stockage clé-valeur distribué d'Amazon, utilisé pour gérer le service de panier d'achat d'Amazon. Dynamo utilise une technologie appelée hachage cohérent pour distribuer les données. En introduisant les concepts de nœuds virtuels et d'anneaux de hachage, il garantit la cohérence des données lorsque des nœuds sont ajoutés ou supprimés. Parallèlement, Dynamo utilise également une technologie appelée horloge vectorielle pour résoudre le problème des conflits de données.
Cassandra de Facebook : Cassandra est un système de stockage distribué développé par Facebook pour stocker les données de recherche de la boîte de réception de Facebook. Cassandra utilise également un hachage cohérent pour distribuer les données et introduit également un protocole appelé Gossip pour synchroniser les informations sur l'état des nœuds afin de garantir la cohérence des données.
Kafka de LinkedIn : Kafka est un système de messagerie distribué développé par LinkedIn et utilisé pour traiter les flux de données en temps réel de LinkedIn. Kafka utilise un service appelé ZooKeeper pour garantir la cohérence des données. ZooKeeper fournit un service de cohérence basé sur l'algorithme Paxos. Kafka assure la cohérence des données en conservant les informations de métadonnées dans ZooKeeper.

Ci-dessus sont quelques cas d'application pratiques de grandes sociétés Internet assurant la cohérence des données dans leurs systèmes distribués. Ces cas montrent comment choisir le modèle de cohérence et la cohérence appropriés en fonction des besoins et des caractéristiques du système dans la conception réelle du système.

5.2. Tendances de développement futures

Avec le développement du cloud computing et de la technologie du big data, l'échelle des systèmes distribués devient de plus en plus grande et le problème de la cohérence des données devient de plus en plus complexe. Voici quelques tendances de développement futures des solutions de cohérence des données dans les systèmes distribués, ainsi que les défis possibles :

Performances et disponibilité plus élevées : les utilisateurs ayant des exigences de plus en plus élevées en matière de qualité de service, les systèmes distribués doivent offrir des performances et une disponibilité plus élevées. Cela nécessite d’améliorer autant que possible les performances et la disponibilité du système tout en garantissant la cohérence des données. Cela peut nécessiter la conception d’algorithmes de consensus plus efficaces ou l’introduction de davantage de techniques d’optimisation dans la conception du système.
Modèles de cohérence plus complexes : à mesure que la complexité des exigences métier augmente, des modèles de cohérence plus complexes peuvent être nécessaires pour répondre aux besoins métier. Par exemple, pour certaines entreprises, il peut être nécessaire d’assurer une cohérence causale ou une cohérence des transactions. Cela nécessite de prendre en compte davantage de facteurs dans la conception de modèles de cohérence et d’algorithmes de consensus.
Systèmes distribués à plus grande échelle : à mesure que les systèmes distribués deviennent de plus en plus grands, le problème de la cohérence des données devient de plus en plus complexe. Par exemple, lorsque l'échelle du système atteint une échelle mondiale, des problèmes tels que la latence du réseau et les différences de fuseau horaire peuvent devoir être pris en compte. Cela nécessite que davantage de facteurs soient pris en compte dans la conception de l’algorithme de consensus.
Sécurité des données et protection de la vie privée : Alors que la sécurité des données et la protection de la vie privée deviennent de plus en plus importantes, la manière de protéger la sécurité et la confidentialité des données tout en garantissant la cohérence des données constitue également un défi important. Cela peut nécessiter l’introduction de davantage de techniques de sécurité et de protection de la vie privée dans la conception des algorithmes de consensus.

Ce qui précède présente les tendances futures de développement des solutions de cohérence des données dans certains systèmes distribués, ainsi que les défis auxquels ils peuvent être confrontés. À l’avenir, nous devrons poursuivre la recherche et l’exploration pour répondre aux besoins de cohérence des données dans les systèmes distribués.