RocketMQ ist eine Nachrichten-Middleware, die häufig von Java-Brüdern verwendet wird. Obwohl sie häufig verwendet wird, wird die RocketMQ-Architektur oft vergessen. Dafür gibt es zwei Gründe: Man ist mit der Geschäftsentwicklung beschäftigt und vergisst es dann, wenn man es längere Zeit nicht liest, und man versteht die Grundursache des Architekturentwurfs nicht und kann sich nicht gut daran erinnern. Dieser Artikel beschreibt den Architekturentwurfsprozess im Volksmund unter Berücksichtigung der RocketMQ-Architektur.
1. Der Denkprozess der Architektur
Wenn Sie sich an die Prinzipien und die Architektur des Frameworks erinnern, müssen Sie zunächst den Gesamtkontext erfassen, darüber nachdenken, warum es so konzipiert ist, und schließlich über die Details nachdenken, damit Sie sich gut daran erinnern können. Dieser Artikel erklärt Schritt für Schritt die Gründe für den Entwurf der RocketMQ-Architektur, indem er Schritt für Schritt Fragen stellt.
1.Grundform
(1) Wenn Sie ein RocketMQ-Entwickler wären und gebeten würden, eine Nachrichten-Middleware zu entwerfen, welche Rollen würden Sie entwerfen?
Antwort: Es müssen mindestens 3 Zeichen gestaltet werden:
- Nachrichtenübertragungsstation: Broker, Broker ist der Kern und verantwortlich für: Empfangen von Nachrichten, Speichern von Nachrichten, Verarbeiten von Verbraucherverbrauchsanforderungen, Sicherung und Notfallwiederherstellung usw.
- Produzent: Produzent, produziert Nachrichten und übermittelt sie dann an den Broker.
- Verbraucher: Verbraucher, konsumiert Nachrichten vom Broker.
2. So speichern Sie Nachrichten
(2) Nachdem wir die Grundform haben, wissen wir, dass die spezifische Nachricht im Broker gespeichert werden muss. Wie sollte die Nachricht also im Broker gespeichert werden?
Antwort: Dies basiert auf realen Fällen. Wenn beispielsweise ein Logistikunternehmen eine Expresslieferung versendet, muss die Expresslieferung in dieselbe Stadt gemeinsam arrangiert und dann mit derselben Ladung LKW in diese Stadt transportiert werden. Auf diese Weise Das gesamte Logistiksystem arbeitet am effizientesten. Clustering wird hier verwendet, um ähnliche Dinge zusammenzuführen.
In ähnlicher Weise verwenden wir beim Entwerfen der Speicherung von Nachrichten auch das Konzept des Clusterings. Wir platzieren Nachrichten desselben Typs in einem logischen Raum, und dieser logische Raum ist das Thema.
(3) Wie ist die interne Struktur von Topic?
Antwort: Innerhalb des Themas müssen Nachrichtenobjekte vorhanden sein. In welcher Datenstruktur existieren diese Nachrichtenobjekte also zusammen? Die zuerst gesendete Nachricht muss zuerst verbraucht werden. Hier wird die First-In-First-Out-Datenstrukturwarteschlange verwendet. Dies ist die Nachrichtenwarteschlange MessageQueue. Daher besteht Topic intern aus MessageQueue und Nachrichtenobjekte werden in der Nachrichtenwarteschlange gespeichert.
3. Führen Sie Cluster ein
(4) Wir wissen, dass Broker der Kern von RocketMQ ist. Was sollen wir tun, wenn ein so wichtiger Kern ausfällt?
Antwort: Da es sich um den Kern von RocketMQ handelt, muss es eine hohe Verfügbarkeit gewährleisten und darf nicht ausfallen. Daher stellt RocketMQ mehrere Broker bereit, um einen Cluster zur Bereitstellung externer Dienste zu bilden.
4. Lassen Sie uns darüber sprechen, wie Sie die Nachricht speichern
(5) Um eine hohe Verfügbarkeit sicherzustellen, stellt RocketMQ mehrere Broker bereit, um einen Cluster zu bilden. Wenn ein Cluster-Szenario mehrere Maschinen enthält, wie können Themen gespeichert werden?
Antwort: Wir müssen den Grundsatz „Legen Sie keine Eier in einen Korb“ lernen. Da eine große Menge an Nachrichten gespeichert werden muss und mehrere Broker vorhanden sind, werden unterschiedliche Themen in verschiedenen Brokern gespeichert, um den Leistungsdruck einer einzelnen Maschine zu teilen, den Druck der Speicherkapazität zu teilen und die Datenwiederherstellung sicherzustellen.
Folgt man weiterhin dem obigen Logistikbeispiel, muss beispielsweise die Expresslieferung von Peking nach Nanjing mit derselben LKW-Gruppe transportiert werden. Wenn die Expresslieferung klein ist, wird ein LKW verwendet, und wenn die Expresslieferung groß ist, werden mehrere LKWs verwendet eingesetzt werden. Die Expresszustellung ist auf mehrere LKWs aufgeteilt. Ebenso sind Themen in RocketMQ verstreut und werden auf mehreren Brokern gespeichert, und der auf jedem Broker gespeicherte Nachrichteninhalt ist unterschiedlich.
(6) Wenn unterschiedliche Themen in verschiedenen Brokern gespeichert sind, sind die Daten eines bestimmten Themas möglicherweise zu groß und die Datenverzerrung führt direkt zur Zerstörung eines bestimmten Brokers. Was soll ich tun?
Antwort: Wie oben erwähnt, handelt es sich bei Topic tatsächlich um eine Sammlung von Warteschlangen. Dann müssen Sie die Warteschlangen nur in verschiedenen Brokern speichern.
(7) Wenn unterschiedliche Themen in unterschiedlichen Brokern gespeichert werden, besteht immer noch das Risiko eines Datenverlusts, aber der Datenverlust für ein bestimmtes Thema wird kleiner. Wie führt man in diesem Fall ein Daten-Disaster-Recovery-Backup durch?
Antwort: Zu diesem Zeitpunkt wird die Master-Slave-Architektur des Brokers verwendet. Der Broker ist entsprechend seiner Rolle in Master und Slave unterteilt. Die Datensynchronisierung zwischen Master und Slave wird regelmäßig durchgeführt. Der Master ist dafür verantwortlich, auf die Lese- und Schreibanfragen des Clients zu antworten, Nachrichten zu speichern, Verbraucheranfragen zu verarbeiten usw., während der Slave nur für die Synchronisierung der Daten des Masters verantwortlich ist.
5. Sprechen Sie über NameServer
(8) Da es sich bei Brokern um Cluster handelt, müssen Produzenten bei der Übermittlung von Nachrichten wissen, welche Broker vorhanden sind und an welchen Broker sie Nachrichten zustellen sollen. Wie geht das?
Antwort: RocketMQ führt das Konzept von NameServer ein. NameServer entspricht der großen Haushälterin. Er kennt alle grundlegenden Informationen in RocketMQ. NameServer speichert die Metadaten des RocketMQ-Clusters. Zu den im NameServer gespeicherten Metadaten gehören hauptsächlich:
- Welche Broker gibt es im Cluster?
- Wer sind die Produzenten?
- Wer sind die Verbraucher?
- Welche Themen gibt es im Cluster?
- Auf welchen Brokern gibt es diese Topic-Nachrichtenwarteschlangen?
(9) Woher kennt der Nameserver diese Nachrichten?
Antwort: Es ist ähnlich, als wenn jemand in der Antike als Bote in die Regierung ging. Bevor er einen Botengang erledigte, musste er alle seine Informationen in ein Register eintragen. In ähnlicher Weise registrieren Broker, Producer und Consumer beim Start auch Daten beim NameServer.
Der Broker registriert sich beim Start beim NameServer und aktualisiert die Metadaten kontinuierlich über Heartbeats. In ähnlicher Weise stellen Produzent und Verbraucher auch Verbindungen mit NameServer her und interagieren dynamisch mit Daten im Cluster, wodurch es einfacher wird, ihre eigenen Informationen zu melden und andere Informationen im Cluster abzurufen.
Zu diesem Zeitpunkt hat das Architekturdiagramm von RocketMQ Gestalt angenommen, und der Grund für das Design jeder Komponente ist ebenfalls klar.
2. Zusammenfassung
In RocketMQ gibt es vier Kernrollen: Broker, Producer, Consumer und NameServer. Es gibt zwei Kernobjekte für die Nachrichtenspeicherung: Topic und MessageQueue.
Um sicherzustellen, dass keine Daten verloren gehen und keine Daten verzerrt werden, wird MessageQueue im selben Thema in verschiedenen Brokern gespeichert.