Ansturm auf Reisetickets zum Frühlingsfest, die Technologie hinter dem Ticketsystem ist so ausgefeilt!

Im Alltag haben sich die Menschen so sehr an praktische Anwendungen wie Online-Shopping, Online-Zahlung, Kartennavigation usw. gewöhnt, dass wir der dahinter stehenden Technologie kaum noch Beachtung schenken. Dies ist natürlich untrennbar mit der sprunghaften Entwicklung der Kommunikationsnetzwerke verbunden, und die Realisierung dieser Funktionen ist auf den Fortschritt verteilter Systeme zurückzuführen. In diesem Artikel wird das Konzept verteilter Systeme, einschließlich des Paxos-Kernalgorithmus, am Beispiel des Online-Ticketkaufs kurz vorgestellt und erläutert, wie dieses mit der Herausforderung einer Netzwerkunterbrechung umgeht.

Geschrieben von | Chen Qingyang

Der jährliche Reiseansturm zum Frühlingsfest ist wieder da Schätzungen zufolge könnte das Passagieraufkommen im Schienenverkehr in diesem Jahr 510 Millionen übersteigen, was einem Durchschnitt von 12,75 Millionen Passagieren pro Tag entspricht. Während die Leute darum wetteifern, schnell Tickets zu ergattern, stellt sich die Frage, wie das Computersystem 12306 so schnell auf die Massenanfragen reagieren kann. Aufgrund seiner begrenzten Rechenleistung kann ein einzelner Server nicht schnell auf Tausende von Anfragen reagieren. Stellen Sie sich ein Szenario vor, in dem es in einer Offline-Ticketverkaufshalle nur einen Ticketschalter gibt, aber 10.000 Menschen in der Schlange stehen. Ich fürchte, die Leute müssen Schlafsäcke mitbringen, um sich anzustellen.

Wie können wir also den Ticketprozess beschleunigen, um die Wartezeit der Leute zu verkürzen? Erstens kann das Personal am Fenster seine Hände beschleunigen und mit extrem hoher Geschwindigkeit arbeiten, es gibt jedoch eine Obergrenze dafür, wie schnell ein einzelner Mitarbeiter arbeiten kann. Eine andere Möglichkeit besteht darin, mehrere Schalter in der Halle zu öffnen und gleichzeitig Tickets zu verkaufen. Gleiches gilt für das Online-Ticketsystem. Wenn ein einzelner Server die Verarbeitung nicht bewältigen kann, werden mehrere Server zur Koordinierung der Verarbeitung eingesetzt, was den Einsatz eines „verteilten Systems“ erfordert!

Was ist ein verteiltes System?

Einfach ausgedrückt ist ein verteiltes System eine Gruppe von Computern, die zusammenarbeiten, um eine Aufgabe zu erledigen. Diese Computer, auch Knoten genannt, sind über ein Netzwerk miteinander verbunden und arbeiten zusammen, erscheinen dem Benutzer jedoch als Ganzes. Es ist nicht nur das Ticketsystem 12306. Die Empfehlungen, die Sie beim Ansehen von Videos sehen, die Suchergebnisse der Suchmaschinen und die Auftragsverteilung der Essenslieferplattformen laufen alle im Hintergrund der verteilten Systeme ab. Im Vergleich zu einem einzelnen Server kann die Verwendung eines verteilten Systems nicht nur die Systemleistung und die Anforderungsantwortgeschwindigkeit verbessern, sondern auch eine höhere Zuverlässigkeit bieten. Selbst wenn einige Knoten ausfallen oder die Netzwerkverbindung verlieren, kann das gesamte System weiterhin Dienste bereitstellen.

Obwohl verteilte Systeme diese Vorteile bieten, stellt die damit verbundene Komplexität auch eine Herausforderung für den Entwurf von Computersystemen dar. Dabei geht es um Fragen der Parallelität und Datenkonsistenz. Stellen Sie sich am Beispiel des Ticketverkaufs folgendes Szenario vor: Zhang San in Peking und Li Si in Guangzhou versuchen, dasselbe Ticket zu kaufen. Die Ticketanfrage von Zhang San wird an einen Server in Nordchina weitergeleitet, während die Anfrage von Li Si an einen Server in Südchina weitergeleitet wird. Diese beiden Server können nun die Ticketanfragen von zwei Personen parallel verarbeiten. Die Gesamtreaktionsgeschwindigkeit des Systems ist sehr hoch, aber wie kann das System richtig zusammenarbeiten, um den Verkauf doppelter Tickets zu verhindern?

Ein weiteres wichtiges Merkmal verteilter Systeme ist die Möglichkeit eines Teilausfalls. Wie der Name schon sagt, fällt ein Teil des Systems aus, der Rest des Systems kann jedoch weiterhin funktionieren. Ein verteiltes System besteht aus vielen Computern, die über ein Netzwerk verbunden sind. Natürlich können sowohl der Computer als auch das Netzwerk selbst ausfallen, beispielsweise durch einen Stromausfall, einen Bruch des Netzwerkkabels oder einen Ausfall des Betriebssystems des Computers usw. Auch wenn die Wahrscheinlichkeit eines Ausfalls einer einzelnen Maschine gering ist, treten bei einer steigenden Anzahl von Computern sehr häufig Ausfälle des gesamten Systems auf.

Wir können eine einfache Berechnung durchführen. Angenommen, das System umfasst 1.000 Computer und jeder Computer fällt im Durchschnitt nur einmal pro Jahr aus (der Ausfall kann beliebige Ursachen haben). Das bedeutet, dass die Wahrscheinlichkeit eines Ausfalls pro Tag 1/365 beträgt. Umgekehrt beträgt die Wahrscheinlichkeit, dass pro Tag kein Ausfall auftritt, 1-1/365, was ungefähr 0,99726 entspricht. Dies scheint eine hohe Wahrscheinlichkeit zu sein, aber für das gesamte System beträgt die Wahrscheinlichkeit, dass nicht jeden Tag alle Maschinen ausfallen, 0,99726 hoch 1000, also etwa 0,064. Netzwerkprobleme werden hier nicht berücksichtigt, daher ist es nahezu unmöglich, dass das System nicht ausfällt.

Daher muss beim Entwurf verteilter Systeme die Frage berücksichtigt werden, wie normale Dienste bereitgestellt werden können, wenn einige Knoten ausfallen oder die Netzwerkverbindung unterbrochen wird.

Der Grundstein verteilter Systeme – der Konsensalgorithmus

Konsensalgorithmen spielen in verteilten Systemen eine zentrale Rolle. Sie ermöglichen es dem gesamten System, zu einem bestimmten Thema einen Konsens zu erzielen, selbst wenn kein gemeinsamer Speicher vorhanden ist, das System nur durch das Senden von Nachrichten kommunizieren kann und einige Knoten ausfallen können. Unabhängig davon, ob beispielsweise ein bestimmter Sitzplatz verkauft wurde oder nicht, ob er an Zhang San oder Li Si verkauft wurde usw., muss das System einen Konsens erzielen, bevor es mit der Ausführung fortfahren kann.

Leslie Lamport, ein Pionier verteilter Systeme und Gewinner des berühmten Turing Awards, schlug 1990 den Paxos-Algorithmus vor, die Grundlage moderner Konsensalgorithmen. Der Grund, warum Lamport den Namen Paxos verwendete, ist sehr interessant. Paxos ist eine kleine Insel mit langer Geschichte im Ionischen Meer Griechenlands. Lamport stellte sich vor, dass Archäologen entdeckt hätten, dass es in der Antike auf der Insel ein „Teilzeitparlament“ gegeben habe. Die Abgeordneten stimmten über Gesetzesentwürfe durch Boten ab, doch die Boten waren unzuverlässig und die Nachrichten wurden möglicherweise nicht oder nur mit Verzögerung zugestellt. Zudem besteht die Möglichkeit, dass die Abgeordneten nicht zu der Sitzung erscheinen. Wie könnten die Abgeordneten in diesem Fall einen Konsens über einen Gesetzesentwurf erzielen? In seinem Aufsatz verwendet Lamport dieses fiktive Parlament auf der Insel Paxos als Rahmen, um einen Algorithmus zur Konsensfindung bei unzuverlässiger Kommunikation vorzuschlagen und liefert einen strengen mathematischen Beweis. Im Jahr 1990 reichte Lamport das Papier bei ACM Transactions on Computer Systems ein. Die Gutachter meinten, das Papier sei zwar interessant, scheine aber nicht besonders wichtig zu sein, und schlugen vor, den Teil über die Paxos-Geschichte zu entfernen. Lamport sagte, die Gutachter hätten keinen Sinn für Humor gehabt und sich geweigert, Änderungen an der Arbeit vorzunehmen. Später las Butler Lampson, ein weiterer Pionier der verteilten Systeme, das Papier und veröffentlichte zusammen mit Nancy Lynch und anderen führenden Köpfen auf diesem Gebiet seine eigenen Beweise. Zu diesem Zeitpunkt erwog Lamport, die Zeitung erneut zu veröffentlichen. Schließlich wurde das Papier dank der Unterstützung einer Gruppe von Fachkollegen im Jahr 1998 veröffentlicht und ist heute der Eckpfeiler verteilter Systeme.

Pionier verteilter Systeme Leslie Lamport 丨 Bildquelle: Wiki

Nachfolgend beschreiben wir anhand des Ticketverkaufssystems kurz die Idee des Paxos-Algorithmus und wie dieser auch bei Knotenausfällen einen Konsens erreichen kann. Nehmen wir der Einfachheit halber an, dass es im System nur 3 Server (Knoten; 3 Knoten sind die Mindestanzahl, die zur Demonstration des Paxos-Algorithmus erforderlich ist) gibt und nur ein Ticket verkauft wird (der Verkauf mehrerer Tickets kann auch als der Vorgang des wiederholten Verkaufs eines Tickets verstanden werden). Darüber hinaus müssen wir auch kurz die Annahmen des Algorithmus darlegen.

Erstens geht der Paxos-Algorithmus davon aus, dass ein Knoten bei einem Ausfall überhaupt nicht mehr reagiert, anstatt weiterhin fehlerhafte Nachrichten über das Netzwerk zu senden und so das System zu stören. Nach der Reparatur kehrt es zum System zurück und reagiert weiterhin. Diese Art von Fehler wird als Fail-Stop bezeichnet, was bedeutet, dass der Vorgang nach dem Fehler gestoppt wird. Zweitens ist Paxos ein Algorithmus, der auf Mehrheitswahl basiert, was bedeutet, dass eine Mehrheit der Knoten für die Annahme stimmen muss, damit ein Konsens gilt. Paxos benötigt 2m+1 Knoten, um den Ausfall von m Knoten auszugleichen. Mit anderen Worten: Um den Ausfall eines Knotens verkraften zu können, muss das System über mindestens drei Knoten verfügen (die anderen beiden funktionieren normal). Wenn mehr als die Hälfte der Knoten ausfällt, funktioniert der Paxos-Algorithmus nicht richtig.

Jetzt weisen wir diesen drei Servern eine globale Seriennummer zu, um sie zu unterscheiden: Knoten 1, Knoten 2 und Knoten 3. Der Paxos-Algorithmus weist jedem Knoten eine Rolle zu. Hier gehen wir davon aus, dass Knoten 1 sowohl ein Antragsteller als auch ein Akzeptant ist. Knoten 2 und 3 sind Akzeptoren, die nur akzeptieren, aber nicht vorschlagen. Nachdem Knoten 1 die Ticketkaufanfrage von Zhang San erhalten hat, startet er den ersten Schritt des Algorithmus: PREPARE-PROMISE.

Der Vorschlagsknoten 1 weist seinem Vorschlag (z. B. dem Verkauf von Tickets an Zhang San) zunächst eine eindeutige Seriennummer (Vorschlagsnummer) zu. Alle Vorschläge im System haben ihre eigene eindeutige Seriennummer. Eine einfache Implementierungsmethode sieht wie folgt aus: Jeder Knoten verwaltet einen Zähler mit einem Anfangswert von 0. Bei jedem neuen Vorschlag wird der Zähler um 1 erhöht. Die Seriennummer des neuen Vorschlags wird auf eine Dezimalzahl gesetzt, die aus dem Zählerwert und der globalen ID des Knotens besteht, mit einem Dezimalpunkt dazwischen, also {Zähler}.{ID}. Beispielsweise hat der erste Vorschlag von Knoten 1 die Nummer 1.1 und der zweite Vorschlag die Nummer 2.1. In ähnlicher Weise trägt der erste Vorschlag von Knoten 2 die Nummer 1.2, sein zweiter Vorschlag die Nummer 2.2 usw. Gemäß diesem Seriennummerndesign sendet der Vorschlagsknoten 1, wenn er die Anfrage von Zhang San empfängt, zunächst eine PREAPRE-Nachricht an alle anderen Knoten und hängt die vorgeschlagene Seriennummer 1.1 an, die hier als PREPARE(1.1) geschrieben wird.

Die Empfänger des Vorschlags reagieren nach folgender Logik:

1. Überprüfen Sie die der empfangenen PREPARE-Nachricht beigefügte Vorschlagssequenznummer.

2. Vergleichen Sie die empfangene Vorschlagsnummer mit der lokalen Max_ID. Wenn sie größer ist, wird die lokale max_id auf die empfangene Vorschlagsnummer aktualisiert und eine PROMISE-Nachricht zurückgegeben. Dies entspricht der Mitteilung an den Antragsteller: „Ich habe Ihre Nachricht erhalten, Ihre Vorschlagsnummer ist derzeit die größte. Bereiten Sie sich auf die Einreichung eines Vorschlags vor und verspreche, keine Vorschläge mit einer kleineren Nummer als Ihrer anzunehmen.“

3. Wenn die empfangene Vorschlagsnummer kleiner als die lokale max_id ist, antwortet der Empfänger nicht oder mit einer Fehlermeldung, die dem Vorschlagenden mitteilt, dass Ihr Vorschlag fehlgeschlagen ist.

Wenn der Antragsteller (Knoten 1) eine PROMISE-Nachricht von der Mehrheit der Akzeptanten (einschließlich sich selbst) erhält, weiß er, dass alle bereit sind, seinen Vorschlag anzunehmen. Erhält der Antragsteller keine Mehrheitsantwort oder eine Fehlermeldung, kann er den Antrag dieser Runde nur aufgeben. Er kann seinen lokalen Zähler um 1 erhöhen und dann erneut eine neue Vorschlagsrunde vorschlagen (da der Zähler um 1 erhöht wird, wird auch die Vorschlagsnummer um 1 erhöht) und es erneut versuchen. Wenn Knoten 1 die PROMISE-Nachricht von der Mehrheit der Knoten empfängt, tritt er in den zweiten Schritt ein: PROPOSE-ACCEPT.

Im zweiten Schritt sendet Knoten 1 eine PROPOSE-Nachricht mit der Vorschlagsnummer und dem spezifischen Wert. Über diesen Wert hofft jeder, einen Konsens zu erzielen. Im Beispiel des Ticketkaufs in diesem Artikel lautet der Inhalt „Zhang San“, was bedeutet, dass das Ticket an Zhang San verkauft wird. Die von Knoten 1 gesendete Nachricht lautet also wie folgt:

VORSCHLAG(1.1, "Zhang San")

Die Empfänger der Nachricht müssen nun eine Entscheidung treffen, ob sie den Vorschlag annehmen. Ihre Logik ist wie folgt:

1. Wenn die Vorschlagsnummer in der PROPOSE-Nachricht immer noch die höchste ist, die ich bisher erhalten habe (d. h. verglichen mit meiner eigenen max_id), dann akzeptiere den Vorschlag und gib eine ACCEPTED-Nachricht zurück;

2. Andernfalls wird keine Nachricht zurückgegeben oder es wird eine Fehlermeldung zurückgegeben, um dem Antragsteller mitzuteilen, dass der Vorschlag fehlgeschlagen ist.

Wenn der Antragsteller von der Mehrheit der Knoten AKZEPTIERTE Nachrichten erhält, weiß er, dass ein Konsens erreicht wurde. Unter der Annahme, dass sowohl Nr. 2 als auch Nr. 3 die PROPOSE-Nachricht normal empfangen und die ACCEPTED-Nachricht normal zurückgegeben haben, haben alle Knoten einen Konsens über den Status „Das Ticket ist an Zhang San verkauft“ erzielt.

Zusammenfassend waren zwei Schritte nötig, um hier einen Konsens zu erzielen. Das Ziel des ersten Schrittes besteht darin, die Zustimmung der Mehrheit zu erhalten. Das ist so, als würde der Antragsteller allen zurufen: „Ich werde die Daten ändern, seid ihr damit einverstanden oder nicht?“ Erst wenn die Mehrheit zustimmt, wird der zweite Schritt ausgeführt – der Antragsteller sendet tatsächlich den vorzuschlagenden Wert.

Stellen Sie sich vor, der Algorithmus würde den ersten Schritt überspringen und den vorzuschlagenden Wert direkt senden. Dann könnten verschiedene Empfänger Werte von verschiedenen Anbietern erhalten. Da die Zustimmung der Mehrheit nicht im Voraus eingeholt wird, weiß der Empfänger zu diesem Zeitpunkt nicht, ob der Wert, den er erhält, die Meinung der Mehrheit widerspiegelt. Es kann im System mehrere Untergruppen mit jeweils eigenen Werten geben, sodass kein globaler Konsens besteht.

Vollständige Paxos-Algorithmuslogik

Bisher lief der Algorithmus einwandfrei. Sehen wir uns nun einige komplexere Situationen an.

Nehmen wir an, dass nicht nur Knoten 1 der Antragsteller ist, sondern dass auch Knoten 2 zum Antragsteller wird, weil er die Anfrage von Li Si erhält (beachten Sie, dass alle Knoten Akzeptoren sind). Jetzt gibt es zwei verschiedene Antragsteller im System und die von ihnen gesendeten Nachrichten können auf beliebige Weise miteinander verflochten sein.

Angenommen, Knoten 3 hat möglicherweise zuerst die PREPARE-Nachricht (Zhang San kauft ein Ticket) von Knoten 1 erhalten, d. h. PREPARE (1.1), und PROMISE zurückgegeben. In diesem Moment empfängt es eine PREPARE-Nachricht von Knoten 2 (Li Si kauft ein Ticket), d. h. PREPARE (1.2). Da die Vorschlagsnummer 1.2 größer als 1.1 ist, gibt es PROMISE an Knoten 2 zurück und aktualisiert seine max_id auf 1.2. Beachten Sie, dass Knoten 1 im zweiten Schritt weiterhin die PROPOSE-Nachricht sendet, PROPOSE(1.1, "张三"), Knoten 3 seinen Vorschlag jedoch zu diesem Zeitpunkt nicht mehr akzeptiert, da für ihn nun 1.2 ein neuerer Vorschlag ist. Es wird nur die von Knoten 2 gesendete PROPOSE-Nachricht akzeptiert.

Betrachten wir eine andere Situation. Nehmen wir an, dass Li Sis Operation etwas langsamer ist als die von Zhang San. Wenn Knoten 2 zum Antragsteller wird und PREPARE(1.2) sendet, hat Knoten 3 den Vorschlag von Knoten 1 bereits akzeptiert (Vorschlagsnummer ist 1.1), d. h., die Nachricht ACCEPTED wurde gesendet. Zu diesem Zeitpunkt hat Knoten 2 aus verschiedenen Gründen die PREPARE-Nachricht von Knoten 1 nicht erhalten und ist sich überhaupt nicht bewusst, dass Knoten 1 und Knoten 3 einen Konsens erzielt haben (das Ticket wurde an Zhang San verkauft). Wenn Knoten 3 dann gemäß dem Paxos-Algorithmus die Nachricht PREPARE(1.2) von Knoten 2 empfängt, gibt er tatsächlich eine PROMISE-Nachricht an Knoten 2 zurück, da 1.2 die höchste Vorschlagsnummer ist, die Knoten 3 je gesehen hat. Da Knoten 3 jedoch den vorherigen Vorschlag 1.1 bereits akzeptiert hat, enthält die zurückgegebene PROMISE-Nachricht die Sequenznummer und den Wert des zuvor akzeptierten Vorschlags, d. h. PROMISE(1.1, "张三"), und teilt Knoten 2 mit: Ich habe Ihre Vorschlagsnummer erhalten, und es ist tatsächlich der neuste Vorschlag, aber ich habe zuvor einen Vorschlag mit der Sequenznummer 1.1 akzeptiert, und sein Inhalt ist "张三". Nr. 2 erhält die Nachricht und erfährt, dass das Ticket verkauft wurde. Zu diesem Zeitpunkt muss Nr. 2 gemäß dem Paxos-Algorithmus den Wert ändern, den er „Zhang San“ vorschlagen möchte, und dann weiterhin PROPOSE-Nachrichten senden, damit alle Knoten weiterhin einen Konsens erzielen.

Das Endergebnis, das Li Si, der Kunde, sah, war: Die Tickets sind ausverkauft. Tatsächlich kann der Antragsteller mehrere PROMISE-Nachrichten mit zuvor akzeptierten Werten erhalten. Es wählt den Wert aus, der der größten Vorschlagsnummer unter allen PROMISEs entspricht, als den Wert, den es vorschlagen möchte. Wenn keine PROMISE-Nachricht Informationen zu einem zuvor akzeptierten Vorschlag enthält, verwendet der Vorschlagende weiterhin den Wert, den er ursprünglich vorschlagen wollte. Die vollständige Logik des aktualisierten Akzeptors und Vorschlagenden wird in den folgenden Abbildungen dargestellt.

PREPARE-PROMISE-Prozess.

Dies ist der vollständige Paxos-Algorithmus. Betrachten wir abschließend kurz die Situation einer Netzwerktrennung oder eines Knotenausfalls, um zu sehen, wie Paxos unter Fehlerbedingungen weiterhin ordnungsgemäß ausgeführt werden kann.

Paxos unter Netzwerk- oder Knotenfehler

Sowohl beim Antragsteller als auch beim Akzeptanten kann es zu Ausfallzeiten kommen. Wenn der Empfänger ausfällt, hat dies tatsächlich nur geringe Auswirkungen auf den Systembetrieb. Dies ist der Vorteil verteilter Systeme: Auch wenn einige Knoten nicht auf PREPARE- oder PROPOSE-Nachrichten antworten, kann das System trotzdem antworten, solange die Mehrheit der Knoten noch online ist, und der Antragsteller kann immer noch Antworten von der Mehrheit erhalten, sodass der Algorithmus ausgeführt wird. Wenn die ausgefallenen Knoten wieder zum Leben erwachen, erfahren sie schließlich durch von anderen Knoten gesendete PROMISE-Nachrichten, die Informationen zu zuvor akzeptierten Vorschlägen enthalten, von dem Konsens, den sie verpasst haben, und aktualisieren diese lokal.

Was passiert, wenn der Antragsteller (z. B. Knoten 1) ausfällt? Es gibt drei Situationen:

1. Wenn es vor dem Senden der PREPARE-Nachricht abstürzt, passiert im System nichts. Andere Knoten werden zu neuen Antragstellern, wenn sie Benutzeranfragen erhalten.

2. Wenn der Antragsteller nach dem Senden der PREPARE-Nachricht abstürzt und das PROPOSE noch nicht gesendet hat, wird sein Vorschlag, wie gerade gesagt, durch das später aktualisierte PREPARE (vom neuen Antragsteller gesendet) ersetzt.

3. Wenn der Antragsteller den ersten Schritt PREPARE-PROMISE abgeschlossen und den zweiten Schritt eingegeben hat, aber nach dem Senden von PROPOSE-Nachrichten an einige Knoten abgestürzt ist, z. B. ist Nr. 1 nach dem Senden von PROPOSE-Nachrichten an Nr. 3 abgestürzt und hatte keine Zeit, sie an Nr. 2 zu senden; dann wird sein Vorschlag von Nr. 3 angenommen und Nr. 2 erfährt schließlich von dem zwischen Nr. 1 und Nr. 3 erzielten Konsens. Da Nr. 2 irgendwann zum Vorschlagenden wird, erhält er schließlich eine PROMISE-Nachricht von Nr. 3, die die Informationen zum zuvor angenommenen Vorschlag enthält, und aktualisiert seine lokalen Informationen entsprechend, wodurch die Konsistenz mit Nr. 1 und Nr. 3 gewahrt bleibt.

Kommen wir also zurück zum Thema Ticketerwerb. Wenn wir vom Client eine Ticketkaufanfrage senden, interagiert dieser mit dem dahinter liegenden komplexen verteilten System. Wenn es Ihnen nicht gelingt, ein Ticket zu ergattern, liegt das nicht zwangsläufig daran, dass Ihre Hände nicht schnell genug sind. Es kann auch an Netzwerkverzögerungen, Serverabstürzen oder der Funktionsweise des Systemalgorithmus selbst liegen.

Abschluss

Als Eckpfeiler moderner Computersysteme können verteilte Systeme Szenarien mit hoher Belastung und hoher Parallelität unterstützen, wie etwa den Kauf von 12306 Tickets. In diesem Artikel werden einige grundlegende Konzepte und technische Implementierungen von Konsistenz und Fehlertoleranz in verteilten Systemen erläutert. Tatsächlich beschränkt sich die Anwendung verteilter Systeme nicht nur auf das Online-Shopping. Im Bereich der Verschlüsselung bieten verteilte Systeme eine grundlegende Unterstützung der Blockchain-Technologie, um die Sicherheit und Konsistenz der Daten zu gewährleisten. Auch im Bereich des wissenschaftlichen Rechnens werden verteilte Systeme zur Lösung größerer Probleme eingesetzt. All diese Bereiche zeigen, dass verteilte Systeme in unserem täglichen Leben und der technologischen Entwicklung eine wesentliche Rolle spielen. Schließlich steht das Frühlingsfest bald vor der Tür. Ich wünsche Ihnen allen ein frohes Frühlingsfest und viel Glück für Ihre Familie!

Hinweis: Das Titelbild dieses Artikels stammt aus der Copyright-Bibliothek. Der Nachdruck und die Verwendung können zu Urheberrechtsstreitigkeiten führen.

Besondere Tipps

1. Gehen Sie zur „Featured Column“ unten im Menü des öffentlichen WeChat-Kontos „Fanpu“, um eine Reihe populärwissenschaftlicher Artikel zu verschiedenen Themen zu lesen.

2. „Fanpu“ bietet die Funktion, Artikel nach Monat zu suchen. Folgen Sie dem offiziellen Account und antworten Sie mit der vierstelligen Jahreszahl + Monat, also etwa „1903“, um den Artikelindex für März 2019 zu erhalten, usw.

Copyright-Erklärung: Einzelpersonen können diesen Artikel gerne weiterleiten, es ist jedoch keinem Medium und keiner Organisation gestattet, ihn ohne Genehmigung nachzudrucken oder Auszüge daraus zu verwenden. Für eine Nachdruckgenehmigung wenden Sie sich bitte an den Backstage-Bereich des öffentlichen WeChat-Kontos „Fanpu“.