"Cohérence éventuelle" vs "Cohérence finale forte" vs "Cohérence forte"?
Je suis tombé sur le concept de "forte cohérence éventuelle". Est-il censé être plus fort que "cohérence éventuelle" mais plus faible que "cohérence forte"? Quelqu'un pourrait-il expliquer les différences entre ces trois concepts avec des exemples applicables?
http://en.wikipedia.org/wiki/Eventual_consistency#Strong_Eventual_Consistencyhttp://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
Merci beaucoup.
AVIS DE NON-RESPONSABILITÉ: Le texte ci-dessous devrait vous donner une idée approximative des différences entre la cohérence éventuelle, la cohérence finale forte et la cohérence forte. Mais ils sont en quelque sorte une simplification excessive. Alors prenez-les avec un grain de sel;)
Tout d'abord: lorsque nous parlons de cohérence , nous faisons référence à un scénario dans lequel différentes entités (nœuds) ont leur propre copie d'un objet de données. Maintenant, des conflits surviennent parce que chaque nœud peut mettre à jour sa propre copie (par exemple, car il y a des clients, chacun connecté à un nœud, leur demandant de le faire), donc si je lis les données de différents nœuds, je verrai différentes valeurs. C'est là que la cohérence éventuelle (EC), la forte cohérence finale (SEC) et la forte cohérence (SC) entrent en jeu.
Cohérence éventuelle Des conflits peuvent survenir, mais les nœuds se communiquent leurs modifications pour résoudre ces conflits, de sorte qu'avec le temps, ils s'accordent sur la valeur définitive. Ainsi, si plus aucun changement n'est appliqué aux données pendant une certaine période, alors tous les nœuds seront d'accord sur la valeur des données (c'est-à-dire qu'ils seront finalement d'accord) afin que les lecteurs de données voient finalement la même valeur.
Exemple: deux nœuds A et B ( nA et nB ) ont chacun une copie d'une chaîne, qui est mise à jour avec les opérations read() et write(string). Disons que chacun a son propre client ( cliA et cliB ). Disons qu'au départ, les deux nœuds stockent la même valeur "Joe", mais à un moment donné nA la met à jour en "Frank" (appelle write("Frank")). Alors nA dira nB que la valeur a été mise à jour; comme les deux valeurs diffèrent, un conflit est apparu mais peut être résolu en utilisant une politique (par exemple, last-write-wins) donc nB met enfin à jour son enregistrement également à "Frank". Avant que le conflit ne soit résolu cliA et cliB verra différentes versions du (le résultat de l'opération read() sera différent), mais finalement les deux verront à nouveau la même valeur.
Gardez à l'esprit que si les deux nœuds mettent à jour leur valeur simultanément, la résolution des conflits est toujours possible mais plus compliquée. C'est là que SEC brille.
Forte cohérence éventuelle Il s'agit d'un cas particulier d'EC, qui n'est valable que pour certains types de données.
Supposons que l'objet de données partagé soit un compteur et que les mises à jour soient effectuées par des opérations add(int value) et substract(int value). Dans ce cas, l'ordre dans lequel nous appliquons les mises à jour n'a pas d'importance ! Donc, si les deux nA et nB commencent par une valeur de compteur de 0, et si alors nA exécute add(10) et nB exécute substract(5) (simultanément), il leur suffit d'envoyer le mettre à jour le fonctionnement les uns des autres sans se soucier de la résolution des conflits, il est finalement garanti qu'ils atteindront la même valeur (rappelez-vous que, dans l'exemple précédent pour EC, une résolution des conflits pourrait être nécessaire)!
Malheureusement, SEC n'est applicable que dans certains types de données et opérations qui ont des propriétés spécifiques (commutativité et autres). Ces types de données sont indiqués Type de données répliquées sans conflit (CRDT).
Forte cohérence Assez différent des deux autres. Ici, il est nécessaire que lors des opérations de mise à jour, tous les nœuds s'accordent sur la nouvelle valeur avant de rendre la nouvelle valeur visible pour les clients. De cette façon, les mises à jour sont visibles par tous les clients "en même temps", de sorte qu'ils liront la même valeur à tout moment. Maintenant, cela introduit la nécessité d'un blocage dans les opérations de mise à jour. À la fois dans EC et SEC, une opération de mise à jour était terminée dès que la copie locale était mise à jour (puis l'opération était diffusée aux autres nœuds). Ici, une mise à jour client ne revient pas tant que tous les nœuds n'ont pas convenu de la valeur des données, et pendant que cela est fait, tous les accès à toute copie de ces données sont "verrouillés" (donc les autres lectures des clients sont bloquées). Dans notre exemple pour EC, si cliA exécute write("Frank"), cliA sera bloqué jusqu'à ce que la mise à jour soit acceptée par nA et nB , puis il sera rendu visible pour cliA et cliB en même temps, c'est-à-dire que l'opération read() devrait retourner la même valeur à partir de là.