Was sind die Anwendungsszenarien der Java-Nachrichtenwarteschlange?

1. Was ist eine Warteschlange? Warteschlange ist eine häufig verwendete Datenstruktur. Zum Beispiel in der Schlange am Bahnhof stehen, um Fahrkarten zu kaufen usw. Die Warteschlange kann durch die folgende Abbildung dargestellt werden:

wobei a1, a2 und an die Daten in der Warteschlange darstellen. Daten werden vom Ende der Warteschlange in die Warteschlange gestellt und dann am Anfang der Warteschlange aus der Warteschlange entfernt.

2. Was ist eine Nachrichtenwarteschlange? Eine Nachrichtenwarteschlange (Message Queue) ist ein verteilter Nachrichtencontainer, der eine Warteschlange (Queue) als zugrunde liegende Speicherdatenstruktur verwendet und zur Lösung der Kommunikation zwischen verschiedenen Prozessen und Anwendungen verwendet werden kann Wird als Nachrichten-Middleware bezeichnet.

Zu den derzeit häufig verwendeten Nachrichtenwarteschlangen gehören ActiveMQ, RabbitMQ, Kafka, RocketMQ, Redis usw.

Was ist der Unterschied zwischen Nachrichtenwarteschlange und Warteschlange?

Der einzige Unterschied besteht darin, dass es beim Betreten der Warteschlange als Produzent bezeichnet wird und beim Entfernen aus der Warteschlange als Verbraucher bezeichnet wird.

3. Anwendungsszenarien für Nachrichtenwarteschlangen sind sehr umfangreich. Nachfolgend sind einige der häufigsten Szenarien aufgeführt. 1.1. Im Allgemeinen sind die von uns geschriebenen Programme in Ordnung Ausgeführt (d. h. synchron). Am Beispiel einer Bestellung in einem E-Commerce-System ist der Ausführungsablauf beispielsweise wie folgt:

Der Benutzer gibt die Bestellung ab. Die Punkte werden nach Abschluss der Bestellung gutgeschrieben. SMS-Benachrichtigung über Punkteänderungen.

kann durch das folgende Flussdiagramm dargestellt werden:

Wenn jeder Dienst in der oben genannten Reihenfolge ausgeführt wird und eine Sekunde dauert, benötigt der Client 3 Sekunden. Für Benutzer sind 3 Sekunden offensichtlich unerträglich. Wie sollen wir das Problem lösen? Wir können eine asynchrone Methode verwenden, um dieses Problem zu lösen:

Auf diese Weise verwenden der Punktedienst und der SMS-Dienst asynchrone Thread-Vorgänge, sodass der Client nur 1 Sekunde damit verbringen muss wird einige Zeit in Anspruch nehmen. Dieser asynchrone Ansatz bringt jedoch ein weiteres Problem mit sich: eine verringerte Parallelität. Da sowohl der Punktedienst als auch der SMS-Dienst Threads im Bestelldienst öffnen müssen, verringert sich die Parallelität des Kundenzugriffs auf den Bestelldienst, wenn mehr Threads geöffnet werden, und die tatsächliche Zeit, die der Kunde für die Übermittlung einer Bestellung benötigt 1 Sekunde überschreiten. Wie können also die durch Asynchronität verursachten Probleme gelöst werden? Das heißt, die Nachrichtenwarteschlange zu verwenden, siehe das Flussdiagramm unten:

Im obigen Prozess haben wir die Rolle einer Nachrichtenwarteschlange hinzugefügt. Zuerst sendet der Kunde die Bestellung und schreibt dann die Bestellung in die Nachricht Warteschlange, Punktedienst Verbrauchen Sie die Nachrichten in der Nachrichtenwarteschlange gleichzeitig mit dem SMS-Dienst. Bei dieser Methode muss der Bestelldienst keinen zusätzlichen asynchronen Thread öffnen, und der Client kann einen Echtzeitverbrauch von 1 Sekunde erreichen.

1.2. Anwendungsentkopplung

Nehmen wir zur Erläuterung zunächst das Flussdiagramm unten:

Geschäftslogik im obigen Bild: Der Kunde initiiert eine Anfrage zum Erstellen einer Zu diesem Zeitpunkt müssen wir zuerst den Bestand ermitteln und dann den Bestand abziehen. Auf diese Weise bilden das Bestellsystem und das Bestandssystem eine sehr enge Abhängigkeit. Wenn das Inventarsystem zu diesem Zeitpunkt ausfällt, ist das Bestellsystem zu diesem Zeitpunkt nicht verfügbar, da das Bestellsystem vom Inventarsystem abhängt. Wie kann man es also lösen?

Sehen Sie sich das Flussdiagramm zur Verwendung der Nachrichtenwarteschlange unten an:

Im obigen Prozess haben wir die Nachrichtenwarteschlange hinzugefügt. Zuerst initiiert der Client eine Anforderung zum Erstellen einer Bestellung, und die Bestellnachricht wird in die Nachrichtenwarteschlange geschrieben. Anschließend abonniert das Inventarsystem die Nachricht in der Nachrichtenwarteschlange und aktualisiert schließlich das Inventarsystem asynchron. Wenn das Inventarsystem ausfällt, kann das Bestellsystem normal auf Kundenanfragen reagieren, da das Bestellsystem nicht direkt vom Inventarsystem abhängt. Dadurch wird eine Anwendungsentkopplung erreicht.

1.3. Traffic Peak Shaving

Bei Systemen mit hoher Parallelität strömt zu Spitzenzugriffszeiten plötzlicher Datenverkehr wie eine Flut zum Anwendungssystem, insbesondere bei einigen Schreibvorgängen mit hoher Parallelität, die jederzeit zum Zusammenbruch des Datenbankservers führen können . Der Dienst kann nicht weiter bereitgestellt werden.

Die Einführung von Nachrichtenwarteschlangen kann die Auswirkungen von Burst-Verkehr auf Anwendungssysteme verringern. Die Verbrauchswarteschlange ist wie ein „Reservoir“, das Überschwemmungen im flussaufwärts gelegenen Fluss auffängt und den Spitzenfluss in den flussabwärts gelegenen Fluss reduziert, wodurch der Zweck der Reduzierung von Überschwemmungskatastrophen erreicht wird.

Das häufigste Beispiel in diesem Zusammenhang ist das Flash-Sale-System. Wenn der gesamte Datenverkehr zum Flash-Sale-System fließt, wird das Flash-Sale-System im Allgemeinen überlastet In Warteschlangen kann Burst-Verkehr effektiv gepuffert werden, um den Effekt des „Peak-Clipping“ zu erzielen.

Wir verwenden das Flash-Sale-Szenario, um die Verkehrsspitzenreduzierung zu beschreiben. Schauen wir uns zunächst das Flussdiagramm unten an:

oben Dabei bezeichnen wir Flash-Sale-Services als Upstream-Services und Order-Services, Inventory-Services und Balance-Services als Downstream-Services. Der Kunde initiiert eine Flash-Sale-Anfrage. Nach Erhalt der Anfrage des Kunden erstellt der Flash-Sale-Service eine Bestellung, ändert den Bestand und zieht den Restbetrag ab. Dies ist das grundlegende Geschäftsszenario des Flash-Sales.

Angenommen, der Downstream-Dienst kann nur 1.000 gleichzeitige Anforderungen gleichzeitig verarbeiten, der Upstream-Dienst kann 10.000 gleichzeitige Anforderungen verarbeiten und der Client initiiert 10.000 Anforderungen, was die Menge an Parallelität übersteigt, die der Downstream-Dienst bewältigen kann handle, sodass es zu Ausfallzeiten nachgelagerter Dienste kommt. Zu diesem Zeitpunkt können Sie der Nachrichtenwarteschlange beitreten, um das Ausfallzeitproblem zu lösen. Schauen Sie sich das Flussdiagramm für den Beitritt zur Nachrichtenwarteschlange unten an:

Wir haben die Nachrichtenwarteschlange zum obigen Flussdiagramm hinzugefügt, um den Dienst zu beschreiben, der 10000 gesendete Nachrichten empfängt Nachdem eine Anfrage gestellt wurde, werden alle Anfragen in die Nachrichtenwarteschlange geschrieben. Anschließend abonniert der Downstream-Dienst die Flash-Sale-Anfrage in der Nachrichtenwarteschlange und führt dann seine eigenen Geschäftslogikoperationen aus.

Nehmen wir ein einfaches Beispiel. Der Upstream-Dienst kann immer noch 10.000 gleichzeitige Anfragen verarbeiten, und der Downstream-Dienst kann immer noch nur 1.000 gleichzeitige Anfragen in der Nachrichtenwarteschlange zulassen . fragen. Der Upstream-Flash-Sale-Dienst hat 10.000 gleichzeitige Anfragen erhalten, aber die Nachrichtenwarteschlange kann nur 1.000 Anfragen speichern. Die überschüssigen Anfragen werden nicht in der Nachrichtenwarteschlange gespeichert und mit der Meldung „Das System ist beschäftigt, bitte“ direkt an den Client zurückgegeben Warten!" . Dabei handelt es sich um das sogenannte Traffic-Peak-Clipping-Szenario. Dies wird durch die Menge an Parallelität bestimmt, die der Downstream-Dienst verarbeiten kann. Da der Downstream-Dienst nur 1.000 gleichzeitige Anfragen verarbeiten kann, können nur 1.000 Flash-Verkäufe in der Nachrichtenwarteschlange gespeichert werden und alle überschüssigen Flash-Verkäufe-Anfragen werden an die Client-Eingabeaufforderung zurückgegeben. Dadurch wird die normale Reaktion der Downstream-Dienste sichergestellt, es kommt nicht zu Ausfallzeiten der Downstream-Dienste und die Systemverfügbarkeit wird verbessert.

2. Protokollierungsszenario

Protokollübertragung optimieren

Um das Programm robust zu machen, fügen wir dem Programm im Allgemeinen verschiedene Protokollierungsfunktionen hinzu, z B. Fehlerprotokolle, Betriebsprotokolle usw., sehen Sie sich das folgende Flussdiagramm an:

Das obige Flussdiagramm zeigt den Prozess der synchronen Aufzeichnung von Protokollen. Die Verwendung des Prozesses der synchronen Protokollierung erhöht den Zeitaufwand für den gesamten Prozess und kann auch leicht zu Ausfallzeiten des Geschäftssystems führen (wenn die Datenbank beschädigt ist, führt das Aufzeichnen von Protokollen in der Datenbank zu einem Fehler). Wir können Nachrichtenwarteschlangen verwenden, um die Protokollübertragung zu optimieren. Schauen Sie sich das Flussdiagramm unten an:

Nach dem Beitritt zur Nachrichtenwarteschlange kann die auf dem System verbrachte Zeit verkürzt werden und die Funktion der Entkopplung des Anwendungssystems erhöht werden kann auch erreicht werden.

3. Sofortiges Kommunikationsszenario

Chatroom

Die Hauptfunktion der Nachrichtenwarteschlange besteht darin, Nachrichten zu senden und zu empfangen innen, daher eignet es sich sehr gut zum Versenden von Nachrichten.

Wir können ein Punkt-zu-Punkt-Chat-System entwickeln, das auf Nachrichtenwarteschlangen basiert, oder wir können ein Broadcast-System entwickeln, um Nachrichten an eine große Anzahl von Empfängern zu senden.

Das obige ist der detaillierte Inhalt vonWas sind die Anwendungsszenarien der Java-Nachrichtenwarteschlange?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!