Sprechen Sie über die Website-Performance-Technologie von 12306.cn

Während das Frühlingsfest näher rückt, ticken die Tickets für die Website 12306.cn im Sekundentakt und Menschen im ganzen Land schimpfen. Lassen Sie uns die Leistung und Umsetzung der Website 12306 besprechen . Wir besprechen nur Leistungsprobleme, nicht die Benutzeroberfläche, die Benutzererfahrung oder funktionale Dinge, die Zahlung und Ticketkauf und -bestellung trennen)

Geschäft

Jede Technologie ist untrennbar mit Geschäftsanforderungen verbunden. Daher möchte ich zunächst das Leistungsproblem erläutern über geschäftliche Themen sprechen.

• 1. Manche Leute vergleichen dieses Ding vielleicht mit QQ oder Online-Spielen . Aber ich denke, die beiden sind unterschiedlich. Online-Spiele und QQ online oder beim Anmelden greifen auf mehr eigene Daten des Benutzers zu, während das Ticketbuchungssystem auf die Ticketvolumendaten des Centers zugreift, was unterschiedlich ist. Denken Sie nicht, dass Online-Spiele oder QQ dasselbe sind, nur weil sie funktionieren. Die Back-End-Lasten von Online-Spielen und QQ sind immer noch einfacher als die von E-Commerce-Systemen.

• 2. Manche Leute sagen, dass die Buchung von Zügen während des Frühlingsfestes wie ein Website-Flash-Sale-Event ist . Es ist tatsächlich sehr ähnlich, aber wenn man nicht über die Oberfläche hinausdenkt, wird man feststellen, dass es auch etwas anders ist. Einerseits wird das Thema Bahntickets mit einer großen Anzahl von Abfragevorgängen einhergehen. Darüber hinaus sind bei der Bestellung viele konsistente Vorgänge in der Datenbank erforderlich ist die Konsistenz jedes Abschnittstickets vom Startpunkt bis zum Endpunkt. Andererseits haben Käufer eine große Auswahl an Routen, Zügen und Zeiten und werden ihre Bestellmethoden ständig ändern. Was Flash-Verkäufe betrifft, beenden Sie sie einfach direkt. Es gibt nicht so viele Abfragen und Konsistenzprobleme. Darüber hinaus kann bei Flash-Verkäufen festgelegt werden, dass nur Anfragen von den ersten N Benutzern angenommen werden (ohne Daten im Backend zu verwalten, sondern nur die Bestellungen des Benutzers zu protokollieren). Für diese Art von Geschäft müssen Sie nur die verfügbaren Daten eingeben Im Speichercache können die Daten auch für 100 Produkte verteilt werden. Es ist nicht erforderlich, zu diesem Zeitpunkt eine Datenbank zu betreiben. Wenn die Anzahl der Bestellungen ausreicht, stoppen Sie den Flash-Sale und schreiben Sie dann stapelweise in die Datenbank. Und es gibt nicht viele Flash-Sale-Artikel. Zugtickets sind nicht so einfach wie Flash-Verkäufe. Während der Reisezeit zum Frühlingsfest sind fast alle Tickets heiß begehrt, und fast alle Fahrkarten kommen aus dem ganzen Land. Es gibt auch Transfergeschäfte und der Bestand mehrerer Linien muss abgewickelt werden . Möchten Sie darüber nachdenken, wie schwierig es ist? (Taobaos Double Eleven hat nur 3 Millionen Nutzer, während Bahntickets sofort Dutzende Millionen oder sogar Hunderte Millionen erreichen können).

• 3. Manche Leute vergleichen dieses System mit dem olympischen Ticketsystem . Ich denke, es ist immer noch anders. Allerdings wurde das olympische Ticketsystem abgeschafft, sobald es online ging. Bei den Olympischen Spielen gilt jedoch das Lotterieverfahren, d . Es gibt keine Schlösser und es ist einfach, es horizontal zu erweitern.

• 4.Das Buchungssystem sollte dem E-Commerce-Bestellsystem sehr ähnlich sein, die beide eine Bestandsverwaltung erfordern: 1) Belegung des Lagerbestands, 2) Zahlung (Optional), 3) Der Vorgang des Abzugs des Lagerbestands. Dies erfordert eine Konsistenzprüfung, d. h. die Daten müssen während der Parallelität gesperrt werden. B2C-E-Commerce-Unternehmen werden dies grundsätzlich asynchron tun, das heißt, die von Ihnen aufgegebene Bestellung wird nicht sofort, sondern erst verzögert bearbeitet, und das System sendet Ihnen eine Bestätigungs-E-Mail . Ich glaube, dass viele Freunde E-Mails erhalten haben, die darauf hinweisen, dass die Registrierung der Bestellung nicht erfolgreich war. Dies bedeutet, dass die Datenkonsistenz bei Parallelität einen Engpass darstellt .

• 5.Das Eisenbahnticketgeschäft ist sehr ungewöhnlichEs werden plötzlich Tickets freigegeben, und einige Tickets reichen bei weitem nicht aus, um alle zu teilen, also einfach jeder Es wird eine Praxis geben, Tickets zu ergattern, was ein Geschäft mit chinesischen Merkmalen ist. Wenn also die Tickets freigegeben werden, werden Millionen oder sogar Dutzende Millionen Menschen herbeiströmen, um sich zu erkundigen und Bestellungen aufzugeben. Innerhalb weniger Dutzend Minuten kann eine Website zig Millionen Besuche verzeichnen. Das ist eine erschreckende Sache. Es wird gesagt, dass der Spitzenbesuch von 12306 1 Milliarde PV beträgt, konzentriert von 8 bis 10 Uhr, mit mehreren zehn Millionen PV pro Sekunde auf dem Höhepunkt.

Sagen Sie noch ein paar Worte:

• Inventar ist ein Albtraum für B2C und die Bestandsverwaltung ist ziemlich kompliziert. Wenn Sie es nicht glauben, können Sie alle traditionellen und E-Commerce-Einzelhandelsunternehmen fragen, wie schwierig es für sie ist, den Lagerbestand zu verwalten. Sonst gäbe es nicht so viele Leute, die nach Vankes Inventar fragen. (Sie können auch „Die Biografie von Steve Jobs“ lesen und erfahren, warum Tim die Position des CEO von Apple übernommen hat. Der Hauptgrund ist, dass er das Lagerzyklusproblem von Apple gelöst hat)

• Für eine Website ist die hohe Belastung durch das Surfen im Internet leicht zu bewältigen. Die Belastung durch Abfragen ist zwar schwierig, kann aber dennoch durch Zwischenspeichern der Abfrageergebnisse bewältigt werden . Da wir auf den Lagerbestand zugreifen müssen, erfolgt die Auftragserteilung grundsätzlich asynchron. Während des letztjährigen Double 11 lag die Bestellzahl von Taobao pro Stunde bei rund 600.000, während JD.com nur 400.000 Bestellungen pro Tag unterstützen konnte (noch schlimmer als 12.306, die Amazon vor fünf Jahren unterstützen konnte). Es ist ersichtlich, dass die Auftragserteilung nicht so leistungsstark ist, wie wir denken.

• Taobao ist viel einfacher als B2C-Websites, da es kein Lager gibt und es daher keine N-Lager wie B2C gibt, um den Bestand desselben Produkts zu aktualisieren und zu aktualisieren . Abfragevorgang. Bei der Bestellung muss die B2C-Website ein Lager in der Nähe des Benutzers finden, das über einen Lagerbestand verfügt, was viele Berechnungen erfordert. Stellen Sie sich vor, Sie haben ein Buch in Peking gekauft, wenn es nicht mehr vorrätig ist. Dann müssen Sie prüfen, ob das Lager in Shenyang oder Xi'an die Ware hat , Sie müssen sich das Jiangsu-Lager usw. ansehen. Auf Taobao gibt es nicht so viele Dinge. Jeder Händler hat sein eigenes Inventar. Das Inventar ist nur eine Nummer und das Inventar wird an die Händler verteilt, was der Leistungssteigerung zuträglich ist.

• Datenkonsistenz ist der eigentliche Leistungsengpass. Einige Leute sagen, dass Nginx 100.000 statische Anfragen pro Sekunde verarbeiten kann, daran bezweifle ich nicht. Dies ist jedoch nur eine statische Anforderung. Solange die Bandbreite und die E/A stark genug sind, der Server über genügend Rechenleistung verfügt und die Anzahl der unterstützten gleichzeitigen Verbindungen dem Aufbau von 100.000 TCP-Verbindungen standhalten kann, wird dies der Fall sein Kein Problem. Angesichts der Datenkonsistenz sind diese 100.000 jedoch völlig zu einem unerreichbaren theoretischen Wert geworden.

Ich habe so viel gesagt, ich möchte Ihnen nur aus geschäftlicher Sicht sagen, dass wir die Perversionen des Geschäfts mit der Buchung von Bahntickets für das Frühlingsfest aus geschäftlicher Sicht wirklich verstehen müssen.

Front-End-Leistungsoptimierungstechnologie

Um Leistungsprobleme zu lösen, werde ich sie im Folgenden auflisten Die folgende Technologie wird einen qualitativen Sprung in ihrer Leistung machen.

1. Front-End-Lastausgleich

Über den DNS-Lastausgleich (im Allgemeinen basierend auf der Routing-Last umgeleitet) kann der Benutzerzugriff gleichmäßig verteilt werden auf mehreren Webservern. Dies reduziert die Anforderungslast auf dem Webserver. Da es sich bei HTTP-Anfragen um kurze Jobs handelt, kann diese Funktion über einen sehr einfachen Load Balancer ausgeführt werden. Am besten ist es, über ein CDN-Netzwerk zu verfügen, das es Benutzern ermöglicht, sich mit dem nächstgelegenen Server zu verbinden (CDN wird normalerweise von verteiltem Speicher begleitet). (Ausführlichere Anweisungen zum Lastausgleich finden Sie unter „Backend-Lastausgleich“)

2. Reduzieren Sie die Anzahl der Frontend-Links

Ich habe mir 12306 angesehen .cn und öffnete die Homepage, um mehr als 60 HTTP-Verbindungen herzustellen, und die Ticketbuchungsseite hat mehr als 70 HTTP-Anfragen. Heutige Browser erfordern alle gleichzeitige Anfragen (natürlich ist die Anzahl gleichzeitiger Anfragen für eine Browserseite begrenzt). Sie können Benutzer jedoch nicht stoppen, wenn Sie mehrere Seiten öffnen. Die TCP-Verbindung des Back-End-Servers wird am Front-End getrennt und nicht sofort freigegeben. Solange es also 1 Million Benutzer gibt, kann es 60 Millionen Links geben (nach dem ersten Besuch wird diese Zahl mit dem Browser-Cache sinken, selbst wenn sie nur 20 % beträgt, handelt es sich immer noch um eine Millionenzahl). Links), auch Vieles mehr. Eine Login-Abfrageseite wäre völlig in Ordnung. Geben Sie js in eine Datei ein, geben Sie CSS in eine Datei ein, geben Sie das Symbol in eine Datei ein und verwenden Sie CSS, um es in Blöcken anzuzeigen. Beschränken Sie die Anzahl der Links auf ein Minimum.

3. Reduzieren Sie die Webseitengröße und erhöhen Sie die Bandbreite

Nicht jedes Unternehmen auf der Welt wagt es, Bilddienste anzubieten, da Bilder zu viel Bandbreite verbrauchen. Im heutigen Breitbandzeitalter ist es für niemanden schwer, die Situation im DFÜ-Zeitalter zu verstehen, als man beim Erstellen einer Bildseite Angst davor hatte, Bilder zu verwenden (dies ist auch beim Surfen auf Mobiltelefonen der Fall). Ich habe die Gesamtdateigröße, die heruntergeladen werden muss, auf der 12306-Homepage überprüft, die etwa 900 KB beträgt. Wenn Sie sie besucht haben, wird der Browser viel für Sie zwischenspeichern und Sie müssen nur etwa 10 KB Dateien herunterladen. Aber wir können uns einen Extremfall vorstellen, bei dem 1 Million Benutzer zum ersten Mal zu Besuch sind. Wenn es innerhalb von 120 Sekunden zurückgegeben werden muss, ist 1 Million erforderlich. 1 M /120 * 8 = 66 Gbit/s Bandbreite. Es ist erstaunlich. Ich schätze also, dass an diesem Tag die Überlastung von 12306 im Wesentlichen auf die Netzwerkbandbreite zurückzuführen sein sollte, sodass Sie möglicherweise keine Reaktion sehen. Später half der Cache des Browsers 12306 dabei, die Bandbreitennutzung erheblich zu reduzieren, sodass die Last sofort auf das Backend übertragen wurde und der Engpass bei der Datenverarbeitung im Backend sofort beseitigt wurde. Sie werden also viele http 500-Fehler sehen. Dies bedeutet, dass der Backend-Server ausgefallen ist.

4. Statisierung von Frontend-Seiten

Statisieren Sie einige Seiten und Daten, die sich nicht häufig ändern, und komprimieren Sie sie. Eine andere perverse Methode besteht darin, diese statischen Seiten unter /dev/shm abzulegen. Dies ist das Verzeichnis, in dem die Dateien direkt aus dem Speicher gelesen und zurückgegeben werden können. Durch die Verwendung der Sendfile-Funktion von Nginx können diese statischen Dateien direkt im Kernel ausgetauscht werden, was die Leistung erheblich steigern kann.

5. Abfragen optimieren

Viele Leute führen dieselbe Abfrage durch, und Sie können einen Reverse-Proxy verwenden, um diese gleichzeitigen und identischen Abfragen zusammenzuführen. Diese Technologie wird hauptsächlich durch das Zwischenspeichern von Abfrageergebnissen implementiert. Die erste Abfrage geht an die Datenbank, um die Daten abzurufen, und legt die Daten im Cache ab. Hashen Sie jede Abfrage und nutzen Sie die NoSQL-Technologie, um diese Optimierung abzuschließen. (Diese Technologie kann auch für statische Seiten verwendet werden)

Für die Abfrage der Anzahl der Bahntickets denke ich persönlich, dass statt Zahlen nur „Ja“ oder „Nein“ angezeigt werden, was das System erheblich vereinfachen kann Komplexität reduzieren und die Leistung verbessern. Entlasten Sie die Datenbank von der Last der Abfragen, damit die Datenbank den Personen, die Bestellungen aufgeben, besser dienen kann.

6. Caching-Probleme

Cache kann zum Zwischenspeichern dynamischer Seiten und auch zum Zwischenspeichern von Abfragedaten verwendet werden. Beim Caching treten normalerweise mehrere Probleme auf:

1) Cache-Update. Wird auch als Cache- und Datenbanksynchronisierung bezeichnet. Es gibt mehrere Methoden, den Cache zu deaktivieren und erneut zu überprüfen. Die andere besteht darin, das Backend über Aktualisierungen zu informieren. Ersteres ist relativ einfach zu implementieren, aber seine Echtzeitleistung ist nicht hoch. Letzteres ist komplexer zu implementieren, aber seine Echtzeitleistung ist hoch.

2) Zwischengespeichertes Paging. Der Speicher reicht möglicherweise nicht aus, daher müssen einige inaktive Daten aus dem Speicher ausgelagert werden. Dies ähnelt dem Speicherauslagern und -auslagern des Betriebssystems. FIFO, LRU und LFU sind allesamt relativ klassische Paging-Algorithmen. Verwandte Inhalte finden Sie im Caching-Algorithmus von Wikipeida.

3) Cache-Rekonstruktion und -Persistenz. Der Cache befindet sich im Speicher und muss immer gewartet werden. Wenn der Cache nicht mehr vorhanden ist, muss er neu erstellt werden. Wenn die Datenmenge groß ist, ist der Cache-Wiederherstellungsprozess sehr langsam , was sich auf die Produktionsumgebung auswirkt. Daher muss auch die Chemisierung berücksichtigt werden.

Viele leistungsstarke NoSQLs unterstützen die oben genannten drei großen Caching-Probleme.

Back-End-Leistungsoptimierungstechnologie

Wir haben bereits über die Front-End-Leistungsoptimierungstechnologie gesprochen, sodass das Front-End möglicherweise kein Engpassproblem darstellt. Dann tritt das Leistungsproblem bei den Back-End-Daten auf. Hier sind einige gängige Techniken zur Back-End-Leistungsoptimierung.

1. Datenredundanz

In Bezug auf Datenredundanz müssen wir die Datenredundanz unserer Datenbank verarbeiten, was bedeutet, dass der Overhead von Tabellenverbindungen reduziert wird. Dies beeinträchtigt jedoch die Datenkonsistenz. Das Risiko ist relativ hoch. Viele Leute verwenden NoSQL für Daten. Es ist schneller, weil die Daten redundant sind, aber dies birgt ein großes Risiko für die Datenkonsistenz. Dies muss je nach Unternehmen analysiert und verarbeitet werden. (Hinweis: Es ist einfach, eine relationale Datenbank auf NoSQL zu übertragen, aber es ist schwierig, umgekehrt von NoSQL auf eine relationale Datenbank umzusteigen.)

2. Datenspiegelung

Fast alle Mainstream-Datenbanken unterstützen die Spiegelung, also die Replikation. Der Vorteil der Datenbankspiegelung besteht darin, dass sie zum Lastausgleich verwendet werden kann. Verteilen Sie die Last einer Datenbank gleichmäßig auf mehrere Plattformen und stellen Sie gleichzeitig die Datenkonsistenz sicher (SCN von Oracle). Das Wichtigste ist, dass dadurch auch eine hohe Verfügbarkeit gewährleistet werden kann, wenn eine Maschine ausfällt, die andere weiterhin in Betrieb ist.

Die Datenkonsistenz der Datenspiegelung kann ein komplexes Problem sein. Daher müssen wir die Daten auf ein einzelnes Datenelement aufteilen, das heißt, den Bestand eines meistverkauften Produkts gleichmäßig auf verschiedene Server verteilen, z a Die meistverkauften Produkte haben 10.000 Lagerbestände. Wir können 10 Server mit jeweils 1.000 Lagerbeständen einrichten, genau wie ein B2C-Lager.

3. Datenpartitionierung

Ein Problem, das die Datenspiegelung nicht lösen kann, besteht darin, dass zu viele Datensätze in der Datentabelle vorhanden sind, was dazu führt, dass der Datenbankbetrieb zu langsam ist. Partitionieren Sie also die Daten. Es gibt viele Möglichkeiten, Daten zu partitionieren. Im Allgemeinen sind sie wie folgt:

1) Klassifizieren Sie die Daten nach einer bestimmten Logik. Beispielsweise kann das Buchungssystem für Bahntickets nach jedem Eisenbahnbüro, nach verschiedenen Modellen, nach dem Ursprungsbahnhof und nach dem Zielort unterteilt werden ... Wie auch immer, es besteht darin, eine Tabelle in mehrere Blätter mit derselben Aufteilung aufzuteilen Bei den Feldern handelt es sich um verschiedene Arten von Tabellen, daher können diese Tabellen auf verschiedenen Computern vorhanden sein, um die Last aufzuteilen.

2) Teilen Sie die Daten nach Feldern auf, dh teilen Sie die Tabellen vertikal auf. Platzieren Sie beispielsweise einige Daten, die sich nicht häufig ändern, in einer Tabelle und häufig geänderte Daten in mehreren anderen Tabellen. Verwandeln Sie eine Tabelle in eine 1-zu-1-Beziehung. Auf diese Weise können Sie die Anzahl der Felder in der Tabelle reduzieren und in gewissem Maße auch die Leistung verbessern. Darüber hinaus führen zu viele Felder dazu, dass die Speicherung eines Datensatzes in verschiedenen Seitentabellen erfolgt, was zu Problemen mit der Lese- und Schreibleistung führt. Aber dann gibt es viele komplizierte Steuerungen.

3) Durchschnittspunkttabelle. Da die erste Methode nicht unbedingt gleichmäßig verteilt ist, können dennoch viele Daten eines bestimmten Typs vorhanden sein. Daher gibt es auch eine Durchschnittsverteilungsmethode, um die Tabellen entsprechend dem Bereich der Primärschlüssel-ID zu unterteilen.

4) Dieselbe Datenpartition. Dies wurde oben in der Datenspiegelung erwähnt. Das heißt, der Inventarwert desselben Produkts wird verschiedenen Servern zugewiesen. Wenn beispielsweise 10.000 Inventare vorhanden sind, können diese 10 Servern zugewiesen werden, und ein Server verfügt über 1.000 Inventare. Dann Lastausgleich.

Alle drei Arten von Trennwänden haben ihre Vor- und Nachteile. Die am häufigsten verwendete ist die erste. Sobald die Daten partitioniert sind, benötigen Sie einen oder mehrere Scheduler, um Ihrem Front-End-Programm mitzuteilen, wo sich die Daten befinden. Die Partitionierung der Bahnticketdaten und deren Platzierung in verschiedenen Provinzen und Städten wird eine sehr bedeutende und qualitative Verbesserung der Leistung des 12306-Systems bewirken.

4. Lastausgleich des Back-End-Systems

Wie bereits erwähnt, kann die Datenpartitionierung die Last bis zu einem gewissen Grad reduzieren, aber sie kann die Last von Hot-End-Systemen nicht reduzieren. Beim Verkauf von Produkten kann es sich um Fahrkarten für bestimmte Hauptstrecken in Großstädten handeln. Dies erfordert den Einsatz einer Datenspiegelung zur Lastreduzierung. Bei der Datenspiegelung müssen Sie den Lastausgleich verwenden. Im Backend kann es für uns schwierig sein, einen Lastausgleicher wie einen Router zu verwenden, da dieser den Datenverkehr ausgleichen soll, da der Datenverkehr nicht die Auslastung des Servers widerspiegelt. Daher benötigen wir ein Aufgabenverteilungssystem, das auch die Auslastung jedes Servers überwachen kann.

Der Aufgabenverteilungsserver hat einige Schwierigkeiten:

• Die Lastsituation ist komplexer. Was ist beschäftigt? Ist die CPU hoch? Oder ist die Festplatten-I/O hoch? Oder ist die Speichernutzung hoch? Oder ist die Parallelität hoch? Oder ist die Speicher-Paging-Rate hoch? Möglicherweise müssen Sie sie alle berücksichtigen. Diese Informationen werden an den Aufgabenverteiler gesendet und der Aufgabenverteiler wählt einen Server mit der geringsten Auslastung für die Verarbeitung aus.

• Der Aufgabenverteilungsserver muss die Aufgabe in die Warteschlange stellen und darf die Aufgabe nicht verlieren, daher muss sie auch beibehalten werden. Und Aufgaben können stapelweise den Rechenservern zugewiesen werden.

• Was soll ich tun, wenn der Aufgabenverteilungsserver ausfällt? Dies erfordert einige hochverfügbare Technologien wie Live-Standby oder Failover. Wir müssen auch darauf achten, wie die Warteschlangen persistenter Aufgaben auf andere Server übertragen werden.

Ich habe gesehen, dass viele Systeme eine statische Methode zur Zuweisung verwenden, einige verwenden Hashing und andere analysieren einfach nacheinander. Diese sind nicht gut genug. Der andere schwerwiegende Fehler der statischen Methode besteht darin, dass unser Allokator dies tun muss, wenn ein Computerserver abstürzt. Außerdem muss der Hash neu berechnet werden (konsistentes Hashing kann dieses Problem teilweise lösen).

Eine andere Methode besteht darin, eine präventive Methode für den Lastausgleich zu verwenden, bei der der nachgeschaltete Computerserver zum Aufgabenserver geht, um Aufgaben abzurufen. Lassen Sie diese Rechenserver entscheiden, ob sie Aufgaben wünschen. Dies hat den Vorteil, dass die Komplexität des Systems vereinfacht werden kann und außerdem die Rechenserver in Echtzeit reduziert oder erhöht werden können. Der einzige Nachteil besteht jedoch darin, dass dies zu einer gewissen Komplexität führen kann, wenn einige Aufgaben nur auf einem bestimmten Server verarbeitet werden können. Insgesamt bietet diese Methode jedoch möglicherweise einen besseren Lastausgleich.

5. Asynchrone, Drosselung und Stapelverarbeitung

Asynchrone, Drosselung und Stapelverarbeitung erfordern alle eine Warteschlangenverarbeitung der Anzahl gleichzeitiger Anforderungen.

• Asynchron bedeutet im Geschäftsleben im Allgemeinen, Anfragen zu sammeln und dann die Bearbeitung zu verzögern. Technisch ist jedes Bearbeitungsprogramm parallel gestaltbar und horizontal erweiterbar. Die technischen Probleme bei Asynchronität sind jedoch wahrscheinlich folgende: a) Das vom Aufgerufenen zurückgegebene Ergebnis wird Kommunikationsprobleme zwischen Prozess-Threads mit sich bringen. b) Wenn das Programm zurückgesetzt werden muss, ist das Rollback etwas kompliziert. c) Asynchron geht normalerweise mit Multithreading und Multiprozess einher, und die Parallelitätskontrolle ist relativ problematisch. d) Viele asynchrone Systeme verwenden Nachrichtenmechanismen, und der Verlust und die Störung von Nachrichten können ebenfalls komplexe Probleme darstellen.

• Die Drosselungstechnologie verbessert nicht wirklich die Leistung. Diese Technologie verhindert hauptsächlich, dass das System durch Datenverkehr überlastet wird, der seine Kapazitäten übersteigt . Im Allgemeinen eignet sich die Throttle-Technologie für Systeme, die Sie nicht kontrollieren können, beispielsweise das Banksystem, das mit Ihrer Website verbunden ist.

• Die Stapelverarbeitungstechnologie besteht darin, eine Reihe grundsätzlich gleicher Anfragen stapelweise zu verarbeiten. Wenn beispielsweise alle gleichzeitig das gleiche Produkt kaufen, müssen Sie nicht eines kaufen und ich schreibe einmal in die Datenbank. Eine bestimmte Anzahl von Anfragen kann gleichzeitig gesammelt und bearbeitet werden. Diese Technik kann auf viele Arten eingesetzt werden. Um beispielsweise Netzwerkbandbreite zu sparen, beträgt die MTU (maximale Übertragungseinheit) im Netzwerk 1500 Byte für Ethernet und mehr als 4000 Byte für Glasfaser. Wenn eines Ihrer Netzwerkpakete diese MTU nicht ausfüllt, ist dies der Fall Dies ist eine Verschwendung von Netzwerkbandbreite, da der Netzwerkkartentreiber nur Block für Block effizient lesen kann. Daher müssen wir beim Senden von Paketen über das Netzwerk genügend Informationen sammeln, bevor wir Netzwerk-E/A durchführen. Dies ist auch eine Stapelverarbeitungsmethode. Der Feind der Stapelverarbeitung ist der geringe Datenverkehr. Daher legen Stapelverarbeitungssysteme im Allgemeinen zwei Schwellenwerte fest: einen für das Auftragsvolumen und einen für die Zeitüberschreitung. Solange eine Bedingung erfüllt ist, beginnt die Übermittlungsverarbeitung.

Solange es also asynchron ist, gibt es im Allgemeinen einen Drosselmechanismus und im Allgemeinen eine Warteschlange. Wenn es eine Warteschlange gibt, gibt es Persistenz Das System verwendet im Allgemeinen die Stapelverarbeitung.

Das von Yunfeng entwickelte „Warteschlangensystem“ ist diese Technologie. Dies ist dem E-Commerce-Bestellsystem sehr ähnlich. Das heißt, mein System hat Ihre Ticketkaufanfrage erhalten, aber ich habe sie noch nicht tatsächlich verarbeitet. Mein System wird diese großen Mengen aufgrund meiner eigenen Verarbeitungsfähigkeiten drosseln. Anfragen werden nach und nach gestellt und bearbeitet. Sobald die Bearbeitung abgeschlossen ist, kann ich dem Benutzer per E-Mail oder SMS mitteilen, dass Sie tatsächlich Tickets kaufen können.

Hier möchte ich das Warteschlangensystem von Yunfeng aus Sicht der Geschäfts- und Benutzeranforderungen diskutieren, da es dieses Problem technisch zu lösen scheint, es jedoch möglicherweise noch einige Probleme in Bezug auf Geschäfts- und Benutzeranforderungen gibt Dinge, über die es sich lohnt, gründlich nachzudenken:

1) Queue-DoS-Angriff. Denken wir zunächst darüber nach: Ist dieses Team einfach eine Warteschlange? Dies ist nicht gut genug, da wir Scalper nicht eliminieren können und eine einfache Ticket_ID anfällig für DoS-Angriffe ist. Wenn ich beispielsweise N Ticket_ID initiiere und in den Ticketkaufprozess eingehe, kostet es Sie einen halben Dollar Es fällt mir leicht, es Leuten, die Tickets kaufen möchten, unmöglich zu machen, Tickets für mehrere Tage zu kaufen. Einige Leute sagen, dass Benutzer ihre ID-Karten verwenden sollten, um sich in die Warteschlange zu stellen, sodass sie diese ID-Karte verwenden müssen, um Einkäufe zu tätigen. Dies kann jedoch die Scalping-Warteschlangen oder Kontohändler nicht beseitigen. Weil sie N-Konten registrieren können, um sich in die Warteschlange zu stellen, aber sie kaufen einfach nicht. Scalper müssen derzeit nur eines tun: Die Website für normale Menschen unzugänglich machen, sodass Benutzer nur über sie einkaufen können.

2) Spaltenkonsistenz? Erfordern Vorgänge in dieser Warteschlange Sperren? Solange eine Sperre vorhanden ist, wird die Leistung nicht verbessert. Stellen Sie sich vor, 1 Million Menschen bitten Sie gleichzeitig, Standortnummern zuzuweisen. Diese Warteschlange wird zu einem Leistungsengpass. Möglicherweise verfügen Sie nicht über eine gute Datenbankleistung, daher kann es sein, dass sie schlechter ist als jetzt. Das Ausrauben der Datenbank und das Ergreifen der Warteschlange sind im Wesentlichen dasselbe.

3) Wartezeit in der Warteschlange. Reicht eine halbe Stunde für den Ticketkauf? Ist es zu viel? Was passiert, wenn der Benutzer zu diesem Zeitpunkt nicht auf das Internet zugreifen kann? Wenn die Zeit knapp ist, werden sich Benutzer beschweren, wenn sie nicht genug Zeit zum Bedienen haben. Wenn die Zeit lang ist, werden sich auch die Leute beschweren, die in der Schlange stehen. Diese Methode kann im praktischen Betrieb viele Probleme bereiten. Außerdem ist eine halbe Stunde zu lang, was völlig unrealistisch ist. Nehmen wir 15 Minuten als Beispiel: Es gibt 10 Millionen Benutzer und es können immer nur 10.000 Benutzer eingegeben werden, um alle Vorgänge abzuschließen Um alle diese 10 Millionen Benutzer zu verarbeiten, werden 1000 * 15 m = 250 Stunden und 10,5 Tage benötigt, und der Zug ist früher abgefahren. (Ich rede nicht nur Unsinn. Nach der Erklärung von Experten des Eisenbahnministeriums: In den letzten Tagen wurden durchschnittlich 1 Million Bestellungen pro Tag aufgegeben, sodass die Bearbeitung von 10 Millionen Benutzern zehn Tage dauert. Dies Die Berechnung ist möglicherweise etwas einfach. Ich möchte nur sagen: In einem System mit so geringer Auslastung können Warteschlangen möglicherweise keine Geschäftsprobleme lösen. )

4) Verteilung von Warteschlangen. Gibt es in diesem Warteschlangensystem nur eine Warteschlange? Nicht gut genug. Denn wenn die Leute, die Sie zum Kauf von Fahrkarten einsetzen, die gleiche Art von Fahrkarten für denselben Zug kaufen (z. B. einen Schlafplatz in einem Zug), schnappen sie sich immer noch Fahrkarten, was bedeutet, dass die Belastung des Systems möglicherweise immer noch hoch ist unter ihnen auf einen bestimmten Server konzentriert. Daher ist es am besten, Benutzer entsprechend ihren Bedürfnissen in eine Warteschlange zu stellen und dabei Herkunft und Ziel anzugeben. Auf diese Weise können mehrere Warteschlangen vorhanden sein. Solange mehrere Warteschlangen vorhanden sind, können sie horizontal erweitert werden. Dies kann das Leistungsproblem lösen, löst jedoch nicht das Problem, dass Benutzer lange in der Warteschlange stehen.

Ich denke, wir können definitiv vom Online-Shopping lernen. Sammeln Sie beim Anstehen (Aufgeben einer Bestellung) die Informationen des Benutzers und die Fahrkarten, die er kaufen möchte, und ermöglichen Sie dem Benutzer, die Priorität des Fahrkartenkaufs festzulegen. Wenn Sie beispielsweise keinen Schlafplatz in Zug A kaufen können, kaufen Sie einen Schlafplatz in Zug B. Wenn Sie ihn noch nicht kaufen können, können Sie einen Schlafplatz in Zug B kaufen. Kaufen Sie einfach einen harten Sitz usw. Dann lädt der Benutzer zuerst das erforderliche Geld auf und dann verarbeitet das System die Bestellung vollständig automatisch und asynchron. Der Benutzer wird per SMS oder E-Mail darüber informiert, ob der Vorgang erfolgreich war oder nicht. Auf diese Weise kann das System nicht nur eine halbe Stunde Benutzerinteraktionszeit einsparen und die Verarbeitung automatisch beschleunigen, sondern auch Personen mit derselben Ticketkaufanfrage für die Stapelverarbeitung zusammenführen (Reduzierung der Anzahl der Datenbankvorgänge). Das Beste an dieser Methode ist, dass sie die Bedürfnisse dieser Warteschlangenbenutzer kennen kann. Sie kann nicht nur die Warteschlange des Benutzers optimieren und Benutzer auf verschiedene Warteschlangen verteilen, sondern es dem Eisenbahnministerium auch ermöglichen, Zugfahrpläne wie die Wunschliste von Amazon zu erstellen Koordinatenanordnungen und -anpassungen (schließlich muss das Warteschlangensystem (Bestellsystem) noch in der Datenbank gespeichert oder persistiert werden, nicht nur im Speicher, sonst wird man beschimpft, wenn die Maschine ausfällt).

Zusammenfassung

Ich habe so viel geschrieben, lassen Sie es mich zusammenfassen:

0) Egal wie Sie es entwerfen, Ihr System muss sich leicht horizontal erweitern lassen . Mit anderen Worten: Alle Links in Ihrem gesamten Datenfluss müssen horizontal erweitert werden können. Auf diese Weise wird das „Hinzufügen von 30-mal mehr Servern“ nicht ausgelacht, wenn Ihr System Leistungsprobleme hat.

1) Die oben genannte Technologie kann nicht von heute auf morgen erreicht werden. Ohne langfristige Akkumulation ist sie grundsätzlich aussichtslos. Wir können sehen, dass es unabhängig davon, welches Sie verwenden, eine gewisse Komplexität mit sich bringt und das Design immer einen Kompromiss darstellt.

2) Ein zentraler Ticketverkauf ist schwierig zu handhaben. Der Einsatz der oben genannten Technologie kann die Leistung des Ticketbuchungssystems um ein Vielfaches verbessern. Der Bau von Unterstationen in verschiedenen Provinzen und Städten und der separate Verkauf von Fahrkarten ist der beste Weg, die Leistung des bestehenden Systems qualitativ zu verbessern.

3) Das Geschäftsmodell, am Vorabend des Frühlingsfests Reisen zu ergattern, und das Angebot an Tickets ist weitaus geringer als die Nachfrage, ist ziemlich ungewöhnlich. Es ermöglicht Dutzenden Millionen oder sogar Hunderten Millionen Menschen, sich einzuloggen um 8 Uhr morgens zur gleichen Zeit eintreffen, um gleichzeitig Tickets zu ergattern. Dieses Geschäftsmodell ist eine Perversion von Perversionen. Die ungewöhnliche Geschäftsform bestimmt, dass sie, egal was sie tun, auf jeden Fall beschimpft werden.

4) Es ist schade, ein so großes System nur für ein oder zwei Wochen zu bauen und den Rest der Zeit untätig zu verbringen.