Lokale erste Software

Zustand

Während sich das Web weiterentwickelt, nimmt die Anzahl der Elemente zu, mit denen Benutzer interagieren und die sie anzeigen. Diese Elemente verändern den Bildschirm, den der Benutzer sieht. Dinge, die den Bildschirm verändern, können als „Zustände“ definiert werden.

Beispielsweise ist „Status“ im Fall einer Informationswebseite wie einer Landingpage eine anzuzeigende Information.

Als nächstes gibt es im Fall von GitHub verschiedene Informationen wie meine Informationen, meine Repository-Informationen, Anzahl der Sterne usw. Da der dem Benutzer angezeigte Bildschirm je nachdem variiert, können alle diese als „Status“ betrachtet werden '.

Als komplexeres Beispiel können Sie ein Beispiel wie Figma nehmen. Alle Grafiken auf dem Bildschirm, wie Punkte, Linien und Flächen, sind allesamt „Zustände“. Darüber hinaus erfordern Kollaborationsfunktionen, dass Sie den Status anderer Personen als Ihnen selbst teilen.

Status und Daten

Zustände sind alle Daten. Informationen über den Benutzer, benutzerspezifische Informationen usw. sind alle Daten, die irgendwo gespeichert werden, und diese Daten werden bald zum Status des Bildschirms, den der Benutzer sieht. Normalerweise werden diese Daten als Single Source of Truth auf dem Server gespeichert. Wenn Sie sich bei einer Website anmelden, wird dies als einzelne Zeile in der Benutzertabelle auf dem Server dieser Website gespeichert.

Daten sind zu weit entfernt

Das Web ist heutzutage kompliziert. Es gibt unzählige Schaltflächen und viele Daten werden auf einem Bildschirm angezeigt. Es gibt viele Informationen, deren Aktualität wichtig ist. Immer wenn sich diese Zustände ändern, müssen die Daten zum Server hin und her übertragen werden, um die Konsistenz sicherzustellen. Wenn Sie nur die „nächste Seite“ wie ein Dokument pro Minute erhalten müssen, ist das kein großes Problem. In Fällen wie Notion, in denen Benutzer Daten kontinuierlich ändern, wird dies jedoch zu einem großen Problem. Wenn ich es jedes Mal laden müsste, wenn ich so etwas wie eine Funktion auf der Seite einstelle, wäre ich verärgert

Optimistisches Update

Denken Sie daran, auf einer Social-Media-Seite wie Instagram auf die Schaltfläche „Gefällt mir“ zu klicken. Wenn ich auf „Gefällt mir“ klicke, muss ich zum Server gehen und die Information speichern, dass mir der Beitrag gefallen hat, die Anzahl der „Gefällt mir“-Angaben für den Beitrag um eins erhöhen und dann die „Gefällt mir“-Angaben für den aktuellen Beitrag abrufen und sie mir zeigen.

Aber auf Instagram werden Likes angeklickt und die Anzahl steigt zusammen mit der Animation in 0,001 Sekunden.

Dies ist möglich, indem der Status des Clients aktualisiert wird, bevor die Informationen überhaupt den Server erreichen. Die Idee besteht darin, den Status des Clients zu aktualisieren, vorausgesetzt, dass die entsprechenden Daten gut auf dem Server aufgezeichnet werden. In den meisten Fällen wird die Kommunikation mit dem Server erfolgreich sein, daher gehen wir optimistisch davon aus, dass dies ein Erfolg war.

Natürlich gibt es Fälle, in denen die an den Server gesendete Anfrage fehlschlägt. Daher muss darauf geachtet werden, den Client-Status im Fehlerfall wiederherzustellen.

Reaktionsfähigkeit geht vor Konsistenz

Es ist sehr sinnvoll, optimal anzuzeigen, ob ich auf den „Gefällt mir“-Button geklickt habe oder nicht. Aber wenn ich klicke, klickt auch jemand anderes, sodass sich die Anzahl der Likes möglicherweise um eins oder mehrere erhöht hat

Dies lässt sich leicht lösen, indem man die Datenkonsistenz leicht ignoriert. Wenn es sich bei dem Beitrag um einen beliebten Beitrag handelt, ist die Anzahl der „Gefällt mir“-Angaben während der Zeit, in der ich den Beitrag angesehen habe, auf keinen Fall gestiegen. Dies ist lediglich die Richtlinie der Software. Für eine schnelle Reaktion wird ein Teil der Datenkonsistenz geopfert

CAP-Theorem

In verteilten Systemstudien gibt es die CAP-Theorie. Diese Theorie besagt, dass bei der Konfiguration eines verteilten Systems nur zwei von C, A und P verwendet werden können.

C steht für Konsistenz. Egal von welchem ​​Knoten Sie Daten lesen, Sie müssen dieselben Daten lesen

A ist Verfügbarkeit, was bedeutet, ob auf alle Anfragen reagiert werden kann, auch wenn ein Knoten ausfällt.

P ist Partitionstoleranz, d. h. wie viele Knoten betrieben werden können, wenn die Netzwerkverbindung verloren geht, und ob sie nach der Netzwerkverbindung wiederhergestellt werden kann.

Laut dieser Theorie sind letztendlich drei Systeme möglich: CA, AP und CP.

CA

Theoretisch kann ein verteiltes System CA wählen, aber wir haben uns entschieden, ein System, das nicht funktioniert, wenn die Netzwerkverbindung unterbrochen wird, nicht als verteiltes System zu bezeichnen.

Am Ende muss P garantiert sein, wenn es sich um ein verteiltes System handelt.

AP

Verfügbarkeit geht vor Konsistenz

Wenn mehrere Knoten vom Netzwerk getrennt werden, verringert sich der Wert der verbundenen Knoten, auch wenn sich nicht alle Knoten über den neuesten Status des Werts einig sind. Daher stimmen die neuesten Daten möglicherweise nicht zwischen getrennten Knoten überein. Benutzer können den Dienst jedoch weiterhin nutzen, als ob sie die neuesten Daten erhalten würden.

Ein repräsentatives Beispiel sind soziale Medien. Obwohl dies in der Realität unwahrscheinlich ist, gehen wir davon aus, dass die Netzwerkverbindung zwischen den Instagram-Knoten in Europa und den Knoten in Asien verloren geht. Es ist in Ordnung, dass die Anzahl der Follower, Likes usw., die Benutzer aus Asien und Benutzer aus Europa sehen, in dieser Zeit der Störung leicht unterschiedlich ist. Die Funktion funktioniert aber weiterhin.

CP

Konsistenz vor Verfügbarkeit

Dies ist ein System, das in Situationen, in denen die neuesten Daten bei einem Netzwerkausfall nicht gewährleistet werden können, nicht auf Benutzeranfragen reagiert.

Beispiele beziehen sich normalerweise auf Geld (Transaktionen). Nehmen wir an, es liegt eine Netzwerkunterbrechung vor, wenn nur noch ein Hotelzimmer mit 50 % Rabatt verfügbar ist. Im AP-System werden Reservierungen unter der Annahme vorgenommen, dass beide Zimmer verfügbar sind, sodass die Möglichkeit einer Überbuchung besteht. Das CP-System ist sich über den aktuellen Status dieser Daten nicht sicher und verschiebt die Anfrage oder lehnt sie ab.

PACELC-Theorem

Die CAP-Theorie ist eigentlich eine Theorie der Teilung. Wenn eine Partitionierung erfolgt ist, müssen Sie A oder C wählen.

Aber tatsächlich kommt es unter normalen Umständen nicht zu einer Teilung. Die Theorie, die in solchen Situationen angewendet werden kann, ist die PACELC-Theorie.

wenn (P) dann (AC) sonst (LC)

Mit anderen Worten, im Fall einer Partition berücksichtigen Sie AC, andernfalls berücksichtigen Sie LC.

LC

Latenz und Konsistenz

Unter normalen Umständen wägt das System Latenz und Konsistenz ab. Es ist eine grandiose Theorie, aber in Wirklichkeit ist sie in der gesamten Computertechnik eine Wahrheit

Über einen Kompromiss nachzudenken bedeutet, einen gewissen Kompromiss zwischen diesen beiden Standards zu sehen.

Latenz kann intuitiv von langsam bis schnell bestimmt werden, aber es ist schwierig, intuitiv zu wissen, was Konsistenz ist.

Starke Konsistenz

Eine starke Konsistenz kann man schon beim Hören des Namens spüren. Egal auf welchen Knoten Sie zugreifen, Sie müssen dieselben Daten sehen. Mit anderen Worten: Konsistenz ist nur möglich, wenn alle Knoten die gleichen Daten haben.

Ich denke, man kann über eine Bank nachdenken.

Endgültige Konsistenz

Es ist eine Konsistenz namens

Eines Tages wird es konsistent sein. Dies bedeutet, dass nicht alle Clients bei einer bestimmten Änderung gleichzeitig denselben Wert sehen, aber nach Abschluss der Synchronisierung schließlich denselben Wert sehen.

Daher wird abhängig von den Eigenschaften der Software entschieden, ob auf Konsistenz geachtet und gleichzeitig Latenz geopfert werden soll, oder ob auf Konsistenz geachtet werden soll, um eine schnelle Reaktion zu ermöglichen.

Das obige ist der detaillierte Inhalt vonLokale erste Software. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!