Nach Ansicht des Autors sind Nachrichtenwarteschlange , Cache sowie Unterdatenbank und Untertabelle die drei Schwertkämpfer von Lösungen mit hoher Parallelität.
In meiner Karriere habe ich bekannte Nachrichtenwarteschlangen wie ActiveMQ, RabbitMQ, Kafka und RocketMQ verwendet.
In diesem Artikel kombiniert der Autor seine eigenen realen Erfahrungen, um sieben klassische Anwendungsszenarien von Nachrichtenwarteschlangen mit Ihnen zu teilen.
1 Asynchron und Entkopplung
Der Autor war einst für den Benutzerservice eines E-Commerce-Unternehmens verantwortlich, der grundlegende Funktionen wie Benutzerregistrierung, Abfrage und Änderung bereitstellte. Nachdem sich der Benutzer erfolgreich registriert hat, muss eine Textnachricht an den Benutzer gesendet werden.
Im Bild sind das Hinzufügen neuer Benutzer und das Versenden von Textnachrichten im User Center-Dienst enthalten. Die Nachteile dieser Methode liegen auf der Hand:
-
Der SMS-Kanal ist nicht stabil genug und das Senden einer Textnachricht dauert etwa 5 Sekunden. Dies macht die Benutzerregistrierungsoberfläche sehr zeitaufwändig und beeinträchtigt das Front-End-Benutzererlebnis.
-
Wenn sich die SMS-Kanalschnittstelle ändert, muss der User-Center-Code geändert werden. Aber das User Center ist das Kernsystem. Sie müssen jedes Mal vorsichtig sein, wenn Sie online gehen. Das fühlt sich sehr umständlich an, da Nicht-Kernfunktionen Auswirkungen auf das Kernsystem haben.
Um dieses Problem zu lösen, hat der Autor die Nachrichtenwarteschlange verwendet, um es zu rekonstruieren.
-
asynchron
Nachdem der User Center-Dienst die Benutzerinformationen erfolgreich gespeichert hat, sendet er eine Nachricht an die Nachrichtenwarteschlange und gibt das Ergebnis sofort an das Frontend zurück. Dadurch kann das Problem vermieden werden, dass es lange dauert und die Benutzererfahrung beeinträchtigt.
-
Entkopplung
Wenn der Aufgabendienst die Nachricht empfängt, ruft er den SMS-Dienst auf, um die SMS zu senden. Dadurch werden die Kerndienste von Nicht-Kernfunktionen getrennt und die Kopplung zwischen Systemen erheblich verringert.
2 Spitzenbeseitigung
In Szenarien mit hoher Parallelität können plötzliche Anforderungsspitzen leicht dazu führen, dass das System instabil wird. Beispielsweise wird eine große Anzahl von Anforderungen für den Zugriff auf die Datenbank die Datenbank stark belasten oder es kann zu einem Engpass bei den Systemressourcen (CPU und E/A) kommen .
Der Autor diente einmal dem Bestellteam für Privatwagen in Shenzhou. Während des Passagierlebenszyklus der Bestellung ändert der Bestelländerungsvorgang zunächst den Bestellcache und sendet dann die Nachricht an MetaQ Die Informationen sind normal (z. B. ob sie nicht in Ordnung sind). Wenn die Bestelldaten korrekt sind, werden sie in der Datenbank gespeichert.
Wenn eine Anforderungsspitze auftritt, hat dies keine großen Auswirkungen auf die Datenbank, da die Gleichzeitigkeit der Verbraucher innerhalb eines Schwellenwertbereichs liegt und die Verbrauchsgeschwindigkeit relativ gleichmäßig ist. Gleichzeitig sind die Hersteller des Bestellsystems damit konfrontiert Auch das Frontend wird stabiler.
3 Nachrichtenbus
Der sogenannte Bus ist wie der Datenbus im Motherboard, mit der Möglichkeit, Daten zu übertragen und zu interagieren. Die Parteien kommunizieren nicht direkt und nutzen den Bus als Standard-Kommunikationsschnittstelle .
Der Autor betreute einmal das Bestellteam einer Lotteriegesellschaft. Während des Lebenszyklus einer Lotteriebestellung durchlief diese viele Schritte wie die Erstellung, die Aufteilung von Unterbestellungen, die Ticketausgabe und die Gewinnberechnung. Jeder Link erfordert eine andere Serviceverarbeitung, jedes System verfügt über eine eigene unabhängige Tabelle und die Geschäftsfunktionen sind relativ unabhängig. Wenn jede Anwendung die Informationen in der Bestellstammtabelle ändern müsste, wäre das ziemlich verwirrend.
Aus diesem Grund hat der Architekt des Unternehmens den Dienst von <font color="red"> Dispatch Center </font> entworfen. Das Dispatch Center verwaltet Bestellinformationen, kommuniziert jedoch nicht mit Unterdiensten, sondern über Nachrichtenwarteschlangen und Ticketing-Gateways B. Gewinnberechnungsdienste, übermitteln und tauschen Informationen aus.
Das architektonische Design des Nachrichtenbusses kann das System stärker entkoppeln und es jedem System ermöglichen, seine eigenen Aufgaben auszuführen.
4 Verzögerte Aufgaben
Wenn ein Benutzer eine Bestellung über die Meituan-App aufgibt und nicht sofort bezahlt, wird bei der Eingabe der Bestelldetails ein Countdown angezeigt. Bei Überschreitung der Zahlungszeit wird die Bestellung automatisch storniert.
Eine sehr elegante Möglichkeit besteht darin, verzögerte Nachrichten aus der Nachrichtenwarteschlange zu verwenden .
Nachdem der Bestelldienst die Bestellung generiert hat, sendet er eine verzögerte Nachricht an die Nachrichtenwarteschlange. Die Nachrichtenwarteschlange übermittelt die Nachricht an den Verbraucher, wenn die Nachricht die Zahlungsablaufzeit erreicht. Nachdem der Verbraucher die Nachricht erhalten hat, bestimmt sie, ob der Bestellstatus „bezahlt“ ist, und führt die Logik zum Stornieren der Bestellung aus.
Der Code für den RocketMQ 4.X-Produzenten zum Senden verzögerter Nachrichten lautet wie folgt:
Message msg = new Message();
msg.setTopic("TopicA");
msg.setTags("Tag");
msg.setBody("this is a delay message".getBytes());
//设置延迟level为5，对应延迟1分钟
msg.setDelayTimeLevel(5);
producer.send(msg);
Die RocketMQ 4.X-Version unterstützt standardmäßig 18 Ebenen verzögerter Nachrichten, die durch das Konfigurationselement messageDelayLevel auf der Brokerseite bestimmt werden.
Die Version RocketMQ 5.
5 Radioverbrauch
Broadcast-Verbrauch : Bei Verwendung des Broadcast-Verbrauchsmodus wird jede Nachricht an alle Verbraucher im Cluster gesendet, um sicherzustellen, dass die Nachricht von jedem Verbraucher mindestens einmal konsumiert wird.
Der Broadcast-Verbrauch wird hauptsächlich in zwei Szenarien verwendet: Nachrichten-Push und Cache-Synchronisierung .
01 Nachrichten-Push
Die folgende Abbildung zeigt den fahrerseitigen Push-Mechanismus eines Privatwagens. Nachdem der Benutzer eine Bestellung aufgegeben hat, generiert das Bestellsystem eine spezielle Autobestellung. Das Versandsystem sendet die Bestellung basierend auf dem entsprechenden Algorithmus und dem Fahrer -end erhält die Versand-Push-Nachricht.
Der Push-Dienst ist ein TCP-Dienst (benutzerdefiniertes Protokoll) und ein Verbraucherdienst. Der Nachrichtenmodus ist Broadcast-Verbrauch.
Nachdem der Treiber die Treiber-APP geöffnet hat, stellt die APP über Lastausgleich und Push-Dienst eine lange Verbindung her und der Push-Dienst speichert die TCP-Verbindungsreferenz (z. B. Treibernummer und TCP-Kanalreferenz).
Der Versanddienst ist der Produzent und sendet die Versanddaten an MetaQ. Der Push-Dienst stellt fest, ob der TCP-Kanal im lokalen Speicher vorhanden ist über die TCP-Verbindung.
02 Cache-Synchronisierung
In Szenarien mit hoher Parallelität nutzen viele Anwendungen den lokalen Cache, um die Systemleistung zu verbessern.
Der lokale Cache kann HashMap, ConcurrentHashMap oder das Caching-Framework Guava Cache oder Caffeine Cache sein.
Wie in der Abbildung oben gezeigt, wird nach dem Start von Anwendung A als RocketMQ-Verbraucher der Nachrichtenmodus auf Broadcast-Verbrauch eingestellt. Um die Schnittstellenleistung zu verbessern, lädt jeder Anwendungsknoten die Wörterbuchtabelle in den lokalen Cache.
Wenn sich die Daten der Wörterbuchtabelle ändern, kann über das Geschäftssystem eine Nachricht an RocketMQ gesendet werden, und jeder Anwendungsknoten verbraucht die Nachricht und aktualisiert den lokalen Cache.
6 Verteilte Transaktionen
Am Beispiel des E-Commerce-Transaktionsszenarios wird der Kernvorgang der Benutzerzahlung für Bestellungen auch Änderungen in mehreren Subsystemen mit sich bringen, wie z. B. nachgelagerte Logistiklieferungen, Punkteänderungen und das Löschen des Warenkorbstatus.
1. Herkömmliche XA-Transaktionslösung: unzureichende Leistung
Um die Konsistenz der Ausführungsergebnisse der oben genannten vier Zweige sicherzustellen, wird eine typische Lösung durch ein verteiltes Transaktionssystem basierend auf dem XA-Protokoll implementiert. Kapseln Sie die vier Aufrufzweige in einer großen Transaktion mit vier unabhängigen Transaktionszweigen. Die auf verteilten XA-Transaktionen basierende Lösung kann die Korrektheit der Geschäftsverarbeitungsergebnisse gewährleisten. Der größte Nachteil besteht jedoch darin, dass in einer Umgebung mit mehreren Zweigstellen der Ressourcensperrbereich groß und die Parallelität gering ist Die Systemleistung wird immer schlechter.
2. Basierend auf einem gewöhnlichen Nachrichtenschema: Schwierigkeiten bei der Gewährleistung der Konsistenz
Bei dieser Lösung sind der Nachrichten-Downstream-Zweig und der Hauptzweig des Bestellsystems anfällig für Inkonsistenzen, zum Beispiel:
- Die Nachricht wurde erfolgreich gesendet, die Bestellung wurde jedoch nicht erfolgreich ausgeführt und die gesamte Transaktion muss zurückgesetzt werden.
- Der Auftrag wurde erfolgreich ausgeführt, die Nachricht wurde jedoch nicht erfolgreich gesendet und es war eine zusätzliche Entschädigung erforderlich, um die Inkonsistenz zu entdecken.
- Die Zeitüberschreitung beim Senden der Nachricht ist unbekannt und es ist nicht möglich festzustellen, ob die Bestellung zurückgesetzt oder die Bestelländerungen übermittelt werden müssen.
3. Basierend auf verteilten RocketMQ-Transaktionsnachrichten: Unterstützt letztendliche Konsistenz
Bei der oben genannten Lösung für gewöhnliche Nachrichten liegt der Grund dafür, dass gewöhnliche Nachrichten und Auftragstransaktionen nicht garantiert werden können, dass sie konsistent sind, im Wesentlichen darin, dass gewöhnliche Nachrichten nicht wie eigenständige Datenbanktransaktionen über die Fähigkeit zum Festschreiben, Zurücksetzen und zur einheitlichen Koordination verfügen können.
Die auf RocketMQ implementierte verteilte Transaktionsnachrichtenfunktion unterstützt zweistufige Übermittlungsfunktionen basierend auf gewöhnlichen Nachrichten. Binden Sie die zweiphasige Übermittlung an lokale Transaktionen, um Konsistenz bei den globalen Übermittlungsergebnissen zu erreichen.
RocketMQ-Transaktionsnachrichten unterstützen die Sicherstellung der letztendlichen Konsistenz der Nachrichtenproduktion und lokaler Transaktionen in verteilten Szenarien . Der Interaktionsprozess ist in der folgenden Abbildung dargestellt:
1. Der Produzent sendet die Nachricht an den Broker.
2. Nachdem der Broker die Nachricht erfolgreich gespeichert hat, gibt er eine Bestätigung an den Produzenten zurück , um zu bestätigen, dass die Nachricht erfolgreich gesendet wurde. Zu diesem Zeitpunkt wird die Nachricht als „ vorübergehend unzustellbar “ markiert. Transaktionsnachricht .
3. Der Produzent beginnt mit der Ausführung der lokalen Transaktionslogik .
4. Der Produzent übermittelt ein sekundäres Bestätigungsergebnis (Commit oder Rollback) basierend auf dem lokalen Transaktionsausführungsergebnis. Nachdem der Broker das Bestätigungsergebnis erhalten hat, lautet die Verarbeitungslogik wie folgt:
- Das sekundäre Bestätigungsergebnis ist Commit: Der Broker markiert die Halbtransaktionsnachricht als zustellbar und übermittelt sie an den Verbraucher.
- Das sekundäre Bestätigungsergebnis ist Rollback: Der Broker führt die Transaktion zurück und übermittelt die Halbtransaktionsnachricht nicht an den Verbraucher.
5. Unter besonderen Umständen, wenn die Netzwerkverbindung getrennt oder die Produzentenanwendung neu gestartet wird, wenn der Broker das vom Absender übermittelte sekundäre Bestätigungsergebnis nicht erhält oder sich das vom Broker empfangene sekundäre Bestätigungsergebnis nach einer festen Zeit im Status „Unbekannt“ befindet Für einen bestimmten Zeitraum initiiert der Dienst das Terminal eine Nachrichtenüberprüfung .
- Nachdem der Produzent die Nachrichtenüberprüfung erhalten hat, muss er das Endergebnis der lokalen Transaktionsausführung entsprechend der Nachricht überprüfen.
- Der Produzent sendet erneut eine sekundäre Bestätigung basierend auf dem endgültigen Status der überprüften lokalen Transaktion , und der Server verarbeitet weiterhin die Halbtransaktionsnachricht gemäß Schritt 4.
7 Datenübertragungs-Hub
In den letzten 10 Jahren sind spezielle Systeme wie KV-Speicher (HBase), Suche (ElasticSearch), Streaming-Verarbeitung (Storm, Spark, Samza), Zeitreihendatenbank (OpenTSDB) und andere spezielle Systeme entstanden. Diese Systeme wurden mit einem einzigen Ziel vor Augen entwickelt und ihre Einfachheit macht es einfacher und kostengünstiger, verteilte Systeme auf Standardhardware aufzubauen.
Oftmals muss derselbe Datensatz in mehrere spezialisierte Systeme eingespeist werden.
Wenn beispielsweise Anwendungsprotokolle für die Offline-Protokollanalyse verwendet werden, ist die Suche nach einzelnen Protokolldatensätzen offensichtlich unpraktisch. Es ist offensichtlich unpraktisch, unabhängige Workflows zum Sammeln jeder Art von Daten zu erstellen und diese dann mithilfe von Nachrichtenwarteschlangen in ihre eigenen Systeme zu importieren dient als Datentransfer-Hub und die gleichen Daten können in verschiedene dedizierte Systeme importiert werden.
Die Protokollsynchronisierung besteht hauptsächlich aus drei Hauptbestandteilen: dem Protokollerfassungs-Client, der Kafka-Nachrichtenwarteschlange und der Back-End-Protokollverarbeitungsanwendung.
- Der Protokollsammlungs-Client ist für die Erfassung von Protokolldaten verschiedener Benutzeranwendungsdienste verantwortlich und sendet die Protokolle „in Stapeln“ und „asynchron“ in Form von Nachrichten an den Kafka-Client. Der Kafka-Client sendet und komprimiert Nachrichten stapelweise, was kaum Auswirkungen auf die Leistung von Anwendungsdiensten hat.
- Kafka speichert Protokolle in Nachrichtendateien und sorgt so für Persistenz.
- Protokollverarbeitungsanwendungen wie Logstash abonnieren und konsumieren Protokollnachrichten in Kafka, und schließlich ruft der Dateisuchdienst die Protokolle ab, oder Kafka übergibt die Nachrichten an andere Big-Data-Anwendungen wie Hadoop zur systematischen Speicherung und Analyse.
Wenn mein Artikel für Sie hilfreich ist, liken Sie ihn, lesen Sie ihn weiter und leiten Sie ihn weiter. Vielen Dank!
