Logiciel local d'abord

État

À mesure que le Web se développe, le nombre d'éléments avec lesquels les utilisateurs interagissent et affichent augmente. Ces éléments modifient l'écran que l'utilisateur voit. Les éléments qui modifient l’écran peuvent être définis comme des « états ».

Par exemple, dans le cas d'une page Web informative telle qu'une page de destination, le « statut » est une information à afficher.

Ensuite, dans le cas de GitHub, il y a diverses informations telles que mes informations, les informations de mon référentiel, le nombre d'étoiles, etc. Puisque l'écran affiché à l'utilisateur varie en fonction de cela, tout cela peut être considéré comme un « statut ». '.

Comme exemple plus complexe, vous pouvez prendre un exemple comme Figma. Tous les graphiques à l'écran, tels que les points, les lignes et les surfaces, sont tous des « états ». De plus, les fonctions de collaboration nécessitent de partager le statut de personnes autres que vous-même.

État et données

Les États sont tous des données. Les informations sur l'utilisateur, les informations personnalisées par l'utilisateur, etc. sont toutes des données stockées quelque part, et ces données deviennent rapidement l'état de l'écran que l'utilisateur voit. Habituellement, ces données sont stockées sur le serveur comme source unique de vérité. Si vous vous connectez à un site Web, il sera enregistré sous la forme d'une seule ligne dans le tableau des utilisateurs sur le serveur de ce site.

Les données sont trop loin

Le Web est compliqué de nos jours. Il existe d'innombrables boutons et de nombreuses données affichées sur un seul écran. Il existe de nombreuses informations dont l’actualité est importante. Chaque fois que ces états changent, les données doivent faire des allers-retours vers le serveur pour garantir la cohérence. Si vous avez seulement besoin de recevoir la « page suivante » par minute, comme un document, ce n’est pas un gros problème. Cependant, dans des cas comme Notion où les utilisateurs modifient continuellement les données, cela devient un gros problème. Si je devais le charger à chaque fois que je définis quelque chose comme une fonctionnalité sur la page, je serais contrarié

.

Mise à jour optimiste

Pensez à cliquer sur un bouton J'aime sur un site de réseau social comme Instagram. Lorsque je clique sur J'aime, je dois accéder au serveur et enregistrer les informations indiquant que j'ai aimé la publication, augmenter le nombre de mentions J'aime pour la publication d'un, puis obtenir les mentions J'aime pour la publication en cours et me les montrer.

Mais sur Instagram, on clique sur les likes et le nombre augmente avec l'animation en 0,001 seconde.

Cela est possible en mettant à jour l'état du client avant même que les informations n'atteignent le serveur. L'idée est de mettre à jour le statut du client, en supposant que les données similaires seront bien enregistrées sur le serveur. Dans la plupart des cas, la communication avec le serveur réussira, nous jugeons donc avec optimisme que c'est un succès.

Bien sûr, il existe des cas où la requête envoyée au serveur échoue, il faut donc veiller à restaurer l'état du client en cas d'échec.

Réactivité plutôt que cohérence

Il est très raisonnable d'afficher de manière optimale si j'ai cliqué sur le bouton J'aime ou non. Mais lorsque je clique, quelqu'un d'autre clique également, donc le nombre de likes peut avoir augmenté d'un ou plusieurs. Comment gérer cela ?

Ce problème peut être facilement résolu en ignorant légèrement la cohérence des données. Si la publication est une publication populaire, il est impossible que le nombre de likes n’augmente pas pendant que je consulte la publication. C'est juste la politique du logiciel. Pour une réponse rapide, une certaine cohérence des données est sacrifiée

.

Théorème du CAP

Dans les études sur les systèmes distribués, il existe la théorie CAP. Cette théorie stipule que lors de la configuration d'un système distribué, seuls deux des C, A et P peuvent être utilisés.

C signifie Cohérence. Quel que soit le nœud à partir duquel vous lisez les données, vous devez lire les mêmes données

.

A est la disponibilité, ce qui signifie si toutes les demandes peuvent recevoir une réponse même si un nœud meurt.

P est la tolérance de partition, c'est-à-dire le nombre de nœuds qui peuvent fonctionner lorsque la connexion réseau est perdue et si elle peut être restaurée après la connexion réseau.

Selon cette théorie, à terme, trois systèmes sont possibles : CA, AP et CP.

Californie

En théorie, un système distribué peut choisir CA, mais nous avons décidé de ne pas appeler un système distribué qui ne fonctionne pas lorsque la connexion réseau est perdue.

Au final, s'il s'agit d'un système distribué, P doit être garanti.

PA

Disponibilité plutôt que cohérence

Lorsque plusieurs nœuds sont déconnectés du réseau, la valeur des nœuds connectés est diminuée même si tous les nœuds ne sont pas d'accord sur le dernier état de la valeur. Par conséquent, les dernières données peuvent ne pas correspondre entre les nœuds déconnectés. Cependant, les utilisateurs peuvent continuer à utiliser le service comme s'ils recevaient les dernières données.

Un exemple représentatif est celui des médias sociaux. Même s'il est peu probable que cela se produise dans la réalité, supposons que la connexion réseau entre les nœuds d'Instagram en Europe et en Asie soit perdue. Il est normal que le nombre de followers, de likes, etc. vus par les utilisateurs accédant depuis l'Asie et les utilisateurs accédant depuis l'Europe soit légèrement différent pendant cette période de perturbation. Mais la fonction fonctionnera toujours.

CP

Cohérence sur la disponibilité

Il s'agit d'un système qui ne répond pas aux demandes des utilisateurs dans les situations où les dernières données ne peuvent pas être garanties en cas de panne de réseau.

Les exemples sont généralement liés à l'argent (transactions). Disons qu’il y a une déconnexion du réseau dans une situation où il ne reste qu’une seule chambre d’hôtel bénéficiant d’une réduction de 50 %. Dans le système AP, les réservations sont faites en supposant que les deux chambres seront disponibles, il existe donc une possibilité de surréservation. Le système CP n'est pas sûr de l'état à jour de ces données, il reporte donc ou rejette la demande.

Théorème PACELC

La théorie CAP est en fait une théorie sur la partition. Si une partition a eu lieu, vous devez choisir A ou C.

Mais en fait, dans des circonstances normales, la partition ne se produit pas. La théorie qui peut être appliquée dans de telles situations est la théorie PACELC.

si (P) alors (AC) sinon (LC)

En d'autres termes, dans le cas de partition, considérez AC, sinon, considérez LC.

LC

Latence et cohérence

Dans des circonstances normales, le système fait un compromis entre latence et cohérence. C'est une théorie grandiose, mais en fait, c'est comme une vérité dans toute l'ingénierie informatique

.

Penser à un compromis, c'est voir un certain degré de compromis entre ces deux normes.

La latence peut être intuitivement déterminée de lente à rapide, mais il est difficile de savoir intuitivement ce qu'est la cohérence.

Forte cohérence

Une forte cohérence peut être ressentie rien qu'en entendant le nom. Quel que soit le nœud auquel vous accédez, vous devez voir les mêmes données. En d'autres termes, la cohérence n'est possible que lorsque tous les nœuds ont les mêmes données.

Je pense que vous pouvez penser à une banque.

Cohérence éventuelle

C'est une cohérence appelée

Un jour, elle sera cohérente. Cela signifie que tous les clients ne verront pas la même valeur en même temps pour une certaine modification, mais qu'ils finiront par voir la même valeur une fois la synchronisation terminée.

Par conséquent, en fonction des caractéristiques du logiciel, il est décidé de veiller à la cohérence tout en sacrifiant la latence ou de sacrifier la cohérence pour une réponse rapide.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!