Dieser Artikel führt zunächst dazu, welche Probleme Nachrichten-Middleware normalerweise lösen muss, welche Schwierigkeiten bei der Lösung dieser Probleme auftreten werden, ob Apache RocketMQ als Hochleistungs-, Hochdurchsatz-Distributed-Message-Middleware von Alibaba gelöst werden kann und wie diese Probleme in der Spezifikation definiert sind. Dieser Artikel wird dann das Architekturdesign von RocketMQ vorstellen, um den Lesern ein schnelles Verständnis von RocketMQ zu vermitteln.
1. Welche Probleme muss Nachrichten-Middleware lösen? Veröffentlichen/Abonnieren ist die grundlegendste Funktion der Nachrichten-Middleware und steht auch im Vergleich zur traditionellen RPC-Kommunikation. Ich werde hier nicht ins Detail gehen.
Die in der Message Priority-Spezifikation beschriebene Priorität bezieht sich auf eine Nachrichtenwarteschlange; jede Nachricht hat eine andere Priorität, die in der Regel durch ganze Zahlen beschrieben wird, die Nachricht mit hoher Priorität wird zuerst zugestellt; wenn die Nachricht vollständig in einer Speicherwarteschlange ist, kann sie nach der Priorität vor der Zustellung sortiert werden, sodass die hohe Priorität zuerst zugestellt wird.
Da alle Nachrichten in RocketMQ persistent sind, wird der Overhead sehr groß sein, wenn sie nach Priorität sortiert werden, weshalb RocketMQ keine spezifische Nachrichtenpriorität unterstützt, sondern ähnliche Funktionen als Workaround implementieren kann, das heißt, eine Warteschlange mit hoher Priorität und eine mit normaler Priorität konfigurieren und unterschiedliche Prioritäten an verschiedene Warteschlangen senden.
Für Prioritätsfragen lassen sie sich in zwei Kategorien zusammenfassen:
- Solange die Priorität erreicht wird, ist sie im strengen Sinne keine Priorität und wird üblicherweise in hoch, mittel, niedrig oder mehrere weitere Stufen unterteilt. Jede Priorität kann durch ein anderes Thema dargestellt werden und beim Senden einer Nachricht verschiedene Themen angeben, die die Priorität darstellen, was die meisten Prioritätsprobleme lösen kann, aber die Genauigkeit der Geschäftsprioritäten beeinträchtigt.
- Strikte Priorität, Priorität wird als ganze Zahl ausgedrückt, zum Beispiel 0 ~ 65535; diese Art von Prioritätsproblem eignet sich im Allgemeinen nicht für die Lösung verschiedener Themen. Wenn du möchtest, dass MQ dieses Problem löst, hat das einen sehr großen Einfluss auf die Leistung von MQ. Hier ist ein Punkt, um sicherzustellen, dass das Unternehmen diese strikte Priorisierung wirklich braucht, und wenn die Prioritäten auf wenige reduziert werden, wie viel Einfluss hat das auf das Unternehmen?
Nachrichtenreihenfolge bezeichnet eine Art von Nachricht, die in der Reihenfolge konsumiert werden kann, in der sie gesendet wird. Zum Beispiel erzeugt eine Bestellung drei Nachrichten, nämlich Auftragserstellung, Auftragszahlung und Auftragsabschluss. Beim Konsumieren ist es sinnvoll, in dieser Reihenfolge zu konsumieren. Aber gleichzeitig können Bestellungen parallel konsumiert werden.
RocketMQ kann streng sicherstellen, dass Nachrichten geordnet sind.
Message FilterBroker Nachrichtenfilterung
Im Broker hat das Filtern nach den Anforderungen des Verbrauchers den Vorteil, die Übermittlung unnötiger Nachrichten an den Verbraucher zu reduzieren.
Der Nachteil ist, dass dies die Belastung für den Makler erhöht und relativ komplex in der Umsetzung ist.
1. Taobao Notify unterstützt eine Vielzahl von Filtermethoden, darunter direkte Filterung nach Nachrichtentyp und flexible Syntax-Ausdrucksfilterung, die fast die anspruchsvollsten Filterbedürfnisse erfüllen kann.
2. Taobao RocketMQ unterstützt Filterung nach einfachem Nachrichtentag sowie Nachrichtenkopf und -körper.
3. Flexible Syntax-Ausdrucksfilterung wird ebenfalls in der CORBA-Benachrichtigungsspezifikation unterstützt.
Verbraucherseitige Nachrichtenfilterung
Diese Filterung kann von der Anwendung vollständig angepasst werden, aber der Nachteil ist, dass viele nutzlose Nachrichten an den Verbraucher gesendet werden.
Es gibt mehrere gängige Persistenzmethoden, die von Nachrichtenpersistenz verwendet werden:
- Persistiere in einer Datenbank, wie zum Beispiel Mysql.
- Persistieren Sie auf KV-Speicher, wie levelDB, Berkeley DB und andere KV-Speichersysteme.
- Persistenz in Form von Dateidatensätzen, wie Kafka, RocketMQ
- Erstellen Sie ein gespeichertes Bild der Speicherdaten, zum Beispiel Beanstalkd, VisiNotify
- (1), (2) und (3) alle drei Persistenzmethoden können den Speicher-Warteschlangenpuffer erweitern, und (4) sind lediglich ein Speicherabbild, das die Daten aus dem vorherigen Speicher wiederherstellen kann, auch wenn der Broker auflegt und neu startet.
Die JMS- und CORBA-Benachrichtigungsspezifikationen geben nicht explizit an, wie gespeichert werden soll, aber die Leistung des Persistenzteils bestimmt direkt die Leistung der gesamten Nachrichten-Middleware.
RocketMQ nutzt den Speichercache des Linux-Dateisystems voll aus, um die Leistung zu verbessern.
Es gibt mehrere Situationen, in denen die Zuverlässigkeit der Nachricht die Zuverlässigkeit der Nachricht beeinflusst:
- Broker schließt normalerweise ab
- Broker-Crash
- Betriebssystemabsturz
- Die Maschine verliert die Energie, aber die Stromversorgung kann sofort wiederhergestellt werden.
- Der Rechner lässt sich nicht einschalten (er kann an wichtigen Geräten wie CPU, Mainboard, Speicher usw. beschädigt sein).
- Festplattengeräteschädigung.
(1), (2), (3) und (4) sind alles Situationen, in denen Hardwareressourcen sofort wiederhergestellt werden können, und RocketMQ kann sicherstellen, dass Nachrichten nicht verloren gehen oder eine kleine Datenmenge verloren geht (je nachdem, ob die Flashmethode synchron oder asynchron ist).
(5) (6) Es handelt sich um einen Single Point of Failure und kann nicht wiederhergestellt werden; sobald er auftritt, gehen alle Nachrichten auf diesem einzelnen Punkt verloren. In beiden Fällen stellt RocketMQ sicher, dass 99 % der Nachrichten durch asynchrone Replikation nicht verloren gehen, aber es gibt immer noch sehr wenige Nachrichten, die verloren gehen können. Die synchrone Dual-Write-Technologie kann Single Points vollständig vermeiden, was zwangsläufig die Leistung beeinträchtigt, und eignet sich daher für Situationen mit extrem hohen Anforderungen an Nachrichtenzuverlässigkeit, wie z. B. Money-bezogene Anwendungen.
RocketMQ unterstützt synchrones duales Schreiben ab Version 3.0.
Nachrichten mit niedriger Latenz können den Verbraucher unmittelbar nach Erreichen der Nachricht beim Broker erreichen, ohne dass sich Nachrichten ansammeln.
RocketMQ verwendet eine Long-Polling-Pull-Methode, um sicherzustellen, dass die Nachricht sehr Echtzeit erfolgt und die Echtzeit-Nachricht nicht niedriger als die von Push.
Mindestens einmal bedeutet, dass jede Nachricht einmal zugestellt werden muss.
RocketMQ Consumer zieht die Nachricht zunächst in den lokalen Bereich und gibt den Ack nach Abschluss des Verbrauchs an den Server zurück.
Genau nur einmal- Die Send-Nachrichten-Stufe erlaubt das Versenden von doppelten Nachrichten nicht.
- In der Phase "Nachricht konsumieren" dürfen doppelte Nachrichten nicht konsumiert werden.
Nur wenn die oben genannten beiden Bedingungen erfüllt sind, kann die Nachricht als "Genau nur einmal" betrachtet werden, und um die beiden genannten Punkte zu erreichen, wird in der verteilten Systemumgebung zwangsläufig ein enormer Overhead erzeugt. Daher garantiert RocketMQ diese Funktion nicht und erfordert Deduplizierung im Geschäft, was bedeutet, dass Verbrauchernachrichten idempotent sein müssen. Obwohl RocketMQ keine strikte Garantie für Nicht-Duplikation gewährleisten kann, gibt es unter normalen Umständen selten wiederholte Senden und Konsum, nur Netzwerkabweichungen, Start und Stopp von Konsumenten sowie andere abnormale Situationen wie Nachrichtenduplizierung.
Der wesentliche Grund für dieses Problem ist, dass es Unsicherheiten bei Netzwerkanrufen gibt, also den dritten Zustand von weder Erfolg noch Misserfolg, sodass das Problem der Nachrichtenwiederholung entsteht.
Was soll ich tun, wenn der Broker's Buffer voll ist? Der Puffer des Brokers bezieht sich üblicherweise auf die Speicherpuffergröße einer Warteschlange im Broker, die in der Regel begrenzt ist – was ist, wenn der Puffer voll ist?
So wird es in der CORBA-Benachrichtigungsspezifikation gehandhabt:
- RejectNewEvents lehnt die neue Nachricht ab und gibt dem Producer den Fehlercode RejectNewEvents zurück.
- Verwerfen bestehende Nachrichten gemäß einer bestimmten Richtlinie
- AnyOrder – Jedes Event kann beim Überlaufen verworfen werden. Dies ist die Standardeinstellung für diese Eigenschaft.
- FifoOrder – Das erste erhaltene Event wird als erstes abgeworfen.
- LifoOrder – Das zuletzt erhaltene Event ist das erste, das abgeworfen wird.
- PriorityOrder – Ereignisse sollten in Prioritätsreihenfolge verworfen werden, sodass Ereignisse mit niedrigerer Priorität vor höheren Prioritäten verworfen werden.
- DeadlineOrder – Ereignisse sollten zuerst in der Reihenfolge der kürzesten Ablauffrist verworfen werden.
RocketMQ verfügt nicht über das Konzept eines Speicherpuffers, und die Warteschlangen von RocketMQ sind persistente Festplatten, wobei die Daten regelmäßig gelöscht werden.
Für die Lösung dieses Problems unterscheidet sich RocketMQ sehr deutlich von anderen MQs: Der Speicherpuffer von RocketMQ ist in eine unendliche Warteschlange abstrahiert, egal wie viel Daten eingehen, es kann installiert werden, diese Unendlichkeit ist ein Basis, der Broker löscht regelmäßig abgelaufene Daten, zum Beispiel speichert der Broker nur 3 Tage an Nachrichten, und obwohl die Länge dieses Puffers unendlich ist, werden die Daten von vor 3 Tagen am Ende der Warteschlange gelöscht.
Retrospektiver Konsum bezeichnet die Botschaft, die der Verbraucher erfolgreich konsumiert hat und die aufgrund der Nachfrage des Unternehmens erneut konsumiert werden muss. Zum Beispiel müssen aufgrund eines Ausfalls des Verbrauchersystems die Daten von vor einer Stunde nach der Wiederherstellung erneut verbraucht werden, dann sollte der Broker einen Mechanismus bereitstellen, um den Verbrauchsfortschritt entsprechend der Zeitdimension zurückzusetzen.
RocketMQ unterstützt einen retrospektiven Zeitverbrauch mit einer Zeitdimension, die auf Millisekunden genau ist und vorwärts oder rückwärts zurückverfolgt werden kann.
Die Hauptfunktion der Nachrichten-Stacking-Middleware ist die asynchrone Entkopplung, und eine weitere wichtige Funktion ist es, den Daten-Flood-Peak des Frontends zu blockieren und die Stabilität des Backend-Systems zu gewährleisten, was von der Message Middleware eine bestimmte Fähigkeit zum Stacking von Nachrichten benötigt, und der Message Heap integriert folgende zwei Situationen:
- Nachrichten werden in Speicherpuffern gestapelt, und sobald sie den Speicherpuffer überschreiten, können Nachrichten gemäß einer bestimmten Drop-Policy, wie in der CORBA-Benachrichtigungsspezifikation beschrieben, verworfen werden. Sie eignet sich für Dienste, die das Verwerfen von Nachrichten tolerieren können; in diesem Fall liegt die Akkumulationskapazität der Nachrichten hauptsächlich in der Größe des Speicherpuffers, und die Leistungsverschlechterung wird nach dem Stapeln der Nachricht nicht allzu groß sein, da die Datenmenge im Speicher nur begrenzten Einfluss auf die Zugriffsfähigkeit für die Außenwelt hat.
- Nachrichten werden in persistenten Speichersystemen wie DB, KV-Speicher oder Dateidatensatzform gestapelt. Wenn Nachrichten im Speicher-Cache nicht getroffen werden können, ist es unvermeidlich, auf die Festplatte zuzugreifen, die eine große Menge an Lese-IO erzeugt, und der Durchsatz des Lese-IO bestimmt direkt die Zugriffsfähigkeit der Nachrichten nach dem Stapeln.
Es gibt vier Hauptpunkte zur Bewertung der Nachrichtenakkumulierungsfähigkeit:
- Wie viele Nachrichten können sich stapeln, wie viele Bytes? Das heißt, die Heap-Kapazität der Nachricht.
- Nachdem eine Nachricht gestapelt wurde, wird der Durchsatz der Nachricht durch das Stapeln beeinflusst?
- Wird der normale Konsum der Verbraucher nach der Ansammlung der Botschaften beeinträchtigt sein?
- Wie hoch ist der Durchsatz beim Zugriff auf Nachrichten, die auf der Festplatte gestapelt sind, nachdem die Nachrichten aufgestapelt sind?
Verteilte Transaktionen Mehrere bekannte Spezifikationen für verteilte Transaktionen, wie XA, JTA usw. Unter ihnen wird die XA-Spezifikation von großen Datenbankanbietern wie Oracle, Mysql usw. weitgehend unterstützt. Unter ihnen wird XAs TM-Implementierungsführer wie Oracle Tuxedo häufig in Finanzen, Telekommunikation und anderen Bereichen eingesetzt.
Verteilte Transaktionen beinhalten zweistufige Commit-Probleme, und in Bezug auf die Datenspeicherung muss KV-Speicher unterstützt werden, da die zweite Phase des Commit-Rollbacks den Nachrichtenzustand ändern muss, was die Aktion beinhaltet, die Nachricht gemäß dem Schlüssel zu finden. RocketMQ umgeht das Problem, die Nachricht gemäß dem Schlüssel in der zweiten Stufe zu finden, indem die erste Stufe verwendet wird, um die vorbereitete Nachricht zu senden, den Offset der Nachricht zu erhalten, und die zweite Stufe, um über den Offset auf die Nachricht zuzugreifen und den Zustand zu ändern; der Offset ist die Adresse der Daten.
Die Transaktionsimplementierungsmethode von RocketMQ erfolgt nicht über KV-Speicher, sondern über die Offset-Methode, die einen erheblichen Nachteil aufweist, nämlich dass das Ändern von Daten durch Offset zu vielen verschmutzten Seiten im System führt, was besondere Aufmerksamkeit erfordert.
Geplante Nachrichten Geplante Nachrichten bedeuten, dass Nachrichten von Konsumenten nicht sofort nach dem Versand an den Broker konsumiert werden können und nur zu einem bestimmten Zeitpunkt oder nach dem Warten auf eine bestimmte Zeit konsumiert werden können.
Wenn Sie eine willkürliche Zeitgenauigkeit auf Broker-Ebene unterstützen wollen, müssen Sie Nachrichtensortierung durchführen, und wenn Persistenz im Spiel ist, verursacht die Nachrichtensortierung zwangsläufig einen enormen Leistungsaufwand.
RocketMQ unterstützt Timing-Nachrichten, unterstützt jedoch keine willkürliche Zeitgenauigkeit und unterstützt spezifische Level wie Timing 5s, 10s, 1m usw.
Nachrichten-Wiederholung Nachdem der Verbraucher die Nachricht nicht konsumieren kann, bieten Sie einen Wiederholungsmechanismus bereit, um die Nachricht erneut konsumieren zu lassen. Fehlgeschlagene Verbrauchernachrichten können in der Regel in folgenden Situationen betrachtet werden:
- Aufgrund des Grundes der Nachricht selbst, wie zum Beispiel eines Deserialisierungsfehlers, können die Nachrichtendaten selbst nicht verarbeitet werden (wie zum Beispiel die Aufladung der Telefonrechnung, die Mobiltelefonnummer der aktuellen Nachricht ist ausgeloggt, kann nicht aufgeladen werden) usw. Dieser Fehler erfordert in der Regel, dass diese Nachricht übersprungen und andere Nachrichten konsumiert werden, und diese fehlgeschlagene Nachricht ist zu 99 % erfolglos, selbst wenn der Verbrauch sofort erneut versucht wird, daher ist es am besten, einen zeitlich begrenzten Wiederholungsmechanismus bereitzustellen, also einen erneuten Versuch nach 10 Sekunden.
- Da die abhängigen nachgelagerten Anwendungsdienste nicht verfügbar sind, wie etwa die Datenbankverbindung, das externe Systemnetzwerk unerreichbar usw. Wenn dieser Fehler auftritt, werden selbst wenn die aktuelle fehlgeschlagene Nachricht übersprungen wird, auch andere Nachrichten konsumiert. In diesem Fall wird empfohlen, den Schlaf von 30 Stunden anzuwenden und die nächste Nachricht zu konsumieren, was den Druck auf den Broker verringern kann, die Nachricht erneut zu versuchen.
RocketMQ Überblick Finden wir heraus, ob RocketMQ die Probleme der oben genannten Nachrichten-Middleware löst.
Was ist RocketMQ?
Die obige Abbildung ist ein typisches Modell der Nachrichten-Middleware, die Nachrichten senden und empfangen möchte; RocketMQ ist ebenfalls so konzipiert; kurz gesagt, RocketMQ hat folgende Eigenschaften:
- Es handelt sich um eine Warteschlangenmodell-Nachrichten-Middleware mit hoher Leistung, hoher Zuverlässigkeit, hoher Echtzeit- und verteilten Eigenschaften.
- Produzent, Konsument und Warteschlange können alle verteilt werden.
- Der Producer sendet nacheinander Nachrichten an einige Warteschlangen, die Warteschlangensammlung heißt Topic, Consumer Wenn Broadcast-Konsum verwendet wird, verbraucht eine Consumer-Instanz alle Warteschlangen dieses Themas, und bei Cluster-Konsum verbrauchen mehrere Consumer-Instanzen die Warteschlangensammlung dieses Themas gleichmäßig.
- Eine strikte Nachrichtenreihenfolge kann garantiert werden
- Bietet reichhaltige Nachrichten-Pull-Modi
- Effiziente horizontale Teilnehmerskalierungsfunktionen
- Echtzeit-Nachrichtenabonnement-Mechanismus
- Hunderte Millionen Nachrichtenakkumulationskapazität
- Weniger Abhängigkeit
Physische Aufbaustruktur der RocketMQ
Wie in der obigen Abbildung dargestellt, weist die Auslösungsstruktur von RocketMQ folgende Eigenschaften auf:
- Name Server ist ein nahezu zustandsloser Knoten, der in Clustern ohne Informationssynchronisation zwischen den Knoten bereitgestellt werden kann.
- Der Einsatz von Broker ist relativ komplex: Broker ist in Master und Slave unterteilt, ein Master kann mehreren Slaves entsprechen, aber ein Slave kann nur einem Master entsprechen, die Entsprechung zwischen Master und Slave wird durch die Angabe desselben BrokerName, einer anderen BrokerId definiert, BrokerId ist 0 für Master und nicht-0 bedeutet Slave. Masters können auch in mehreren Bereichen eingesetzt werden. Jeder Broker stellt eine lange Verbindung mit allen Knoten im Nameserver-Cluster her und registriert in regelmäßigen Abständen Themeninformationen an alle Name Server.
- Der Produzent stellt eine lange Verbindung mit einem der Knoten im Name Server-Cluster her (zufällig ausgewählt), ruft periodisch Themen-Routing-Informationen vom Name Server ab, stellt eine lange Verbindung zum Master her, der den Topic-Service bereitstellt, und sendet in regelmäßigen Abständen Herzschläge an den Master. Producer ist vollständig stateless und kann in Clustern bereitgestellt werden.
- Der Consumer stellt eine lange Verbindung mit einem der Knoten im Nameserver-Cluster her (zufällig ausgewählt), ruft regelmäßig Themenrouting-Informationen vom Name Server ab und stellt eine lange Verbindung zum Master und Slave her, die den Topic-Service bereitstellen, und sendet in regelmäßigen Abständen Herzschläge an Master und Slave. Verbraucher können Nachrichten sowohl von Master als auch von Slave abonnieren, und die Abonnementregeln werden durch die Broker-Konfiguration bestimmt.
Logische Auslösungsstruktur der RocketMQ
Wie in der obigen Abbildung gezeigt, weist die logische Bereitstellungsstruktur von RocketMQ zwei Merkmale auf: Produzent und Verbraucher.
Zur Darstellung einer Messaging-Anwendung enthält eine Producer-Gruppe mehrere Producer-Instanzen, die mehrere Maschinen, mehrere Prozesse einer Maschine oder mehrere Producer-Objekte eines Prozesses sein können. Eine Producer Group kann mehrere Topic-Nachrichten senden, und die Producer Group funktioniert wie folgt:
- Identifizieren Sie einen Typ von Produzenten
- Sie können über das O&M-Tool abfragen, ob es mehrere Producer-Instanzen in dieser Messaging-Anwendung gibt.
- Beim Senden einer verteilten Transaktionsnachricht ruft der Broker, falls der Produzent unerwartet ausfällt, aktiv jede Maschine in der Produzentengruppe zurück, um den Transaktionsstatus zu bestätigen.
Zur Darstellung einer Consumer-Messaging-Anwendung enthält eine Consumer-Gruppe mehrere Consumer-Instanzen, die mehrere Maschinen, mehrere Prozesse oder mehrere Consumer-Objekte eines Prozesses sein können. Mehrere Konsumenten in einer Verbrauchergruppe konsumieren Nachrichten gleichmäßig verteilt, und wenn sie auf Broadcast eingestellt sind, verbraucht jede Instanz in dieser Verbrauchergruppe die volle Datenmenge.
RocketMQ-Datenspeicherstruktur
Wie in der obigen Abbildung gezeigt, verwendet RocketMQ eine Speichermethode, die Daten von Indizes trennt. Effektiv den Verlust von Dateiressourcen, IO-Ressourcen und Speicherressourcen reduzieren. Selbst mit riesigen Daten wie Alibaba können hochzeitige Nebenläufigkeitsszenarien die End-to-End-Latenz effektiv reduzieren und starke horizontale Skalierungsmöglichkeiten bieten.
|
Veröffentlicht am 28.07.2017 20:26:52
|
|
|
|
Veröffentlicht am 29.07.2017 08:09:37