Nachrichtenbroker verstehen. Erlernen der Mechanismen des Messaging über ActiveMQ und Kafka. Kapitel 1

Hallo allerseits!

Begann ein kleines Buch zu übersetzen:
" Message Brokers verstehen ",
Autor: Jakub Korab, Herausgeber: O'Reilly Media, Inc., Erscheinungsdatum: Juni 2017, ISBN: 9781492049296.

Aus der Einleitung zum Buch:
"... In diesem Buch lernen Sie, über Messaging-Systeme bei Brokern zu sprechen, indem Sie zwei beliebte Brokertechnologien vergleichen und gegenüberstellen: Apache ActiveMQ und Apache Kafka. Hier finden Sie Beispiele für Verwendungs- und Entwicklungsanreize, die ihre Entwickler dazu veranlasst haben, völlig unterschiedliche Ansätze zu verwenden im gleichen Bereich - Messaging zwischen Systemen mit einem Zwischenbroker. Wir werden diese Technologien von Grund auf betrachten und den Einfluss verschiedener Designoptionen auf dem Weg hervorheben. Sie erhalten ein tiefes Verständnis für beide Produkte. ein Verständnis dafür, wie sie verwendet werden sollten und nicht, und ein Verständnis dafür, worauf zu achten ist, wenn in Zukunft andere Messaging-Technologien in Betracht gezogen werden ... "

Bisher übersetzte Teile:
Kapitel 1. Einführung
Kapitel 2. ActiveMQ
Kapitel 3. Kafka

Übersetzung abgeschlossen: tele.gg/middle_java

Ich werde die fertigen Kapitel veröffentlichen, sobald sie übersetzt sind.

KAPITEL 1

Einführung

Intersystem Messaging ist einer der am wenigsten verstandenen Bereiche der IT. Als Entwickler oder Architekt sind Sie möglicherweise mit verschiedenen Frameworks und Datenbanken vertraut. Es ist jedoch wahrscheinlich, dass Sie nur vorübergehend mit der Funktionsweise von Broker-basierten Messaging-Technologien vertraut sind. Wenn Sie sich so fühlen, machen Sie sich keine Sorgen, Sie sind in guter Gesellschaft.

Menschen haben normalerweise nur sehr begrenzten Kontakt zur Messaging-Infrastruktur. Oft stellen sie eine Verbindung zu einem System her, das vor langer Zeit erstellt wurde, oder laden ein Distributionskit aus dem Internet herunter, installieren es im PROM und beginnen, Code dafür zu schreiben. Nach dem Start der Infrastruktur in PROM können die Ergebnisse gemischt sein: Nachrichtenverlust bei Fehlern, Senden funktioniert nicht wie erwartet oder Broker "suspendieren" Ihre Produzenten oder senden keine Nachrichten an Ihre Verbraucher.

Kommt Ihnen das bekannt vor?

Ein häufiges Szenario ist, wenn Ihr Messaging-Code vorerst einwandfrei funktioniert. Bis es nicht mehr funktioniert. Diese Zeit lindert die Wachsamkeit und vermittelt ein falsches Sicherheitsgefühl, was zu noch mehr Code führt, der auf falschen Vorstellungen über das grundlegende Verhalten der Technologie basiert. Wenn etwas schief geht, werden Sie mit einer unangenehmen Wahrheit konfrontiert: Sie haben das grundlegende Verhalten des Produkts oder die von den Autoren gewählten Kompromisse wie Leistung versus Zuverlässigkeit oder Transaktionsfähigkeit versus horizontale Skalierbarkeit wirklich nicht verstanden.

Ohne ein tiefes Verständnis der Funktionsweise von Brokern machen die Leute scheinbar vernünftige Aussagen über ihre Messagingsysteme, wie zum Beispiel:

• Das System verliert niemals Nachrichten
• Nachrichten werden nacheinander verarbeitet
• Durch das Hinzufügen von Verbrauchern wird das System schneller
• Nachrichten werden nur einmal zugestellt.

Leider basieren einige dieser Aussagen auf Annahmen, die nur unter bestimmten Umständen gelten, während andere einfach falsch sind.

In diesem Buch erfahren Sie, wie Sie über Broker-basierte Messaging-Systeme sprechen, indem Sie zwei beliebte Broker-Technologien vergleichen und gegenüberstellen: Apache ActiveMQ und Apache Kafka. Hier werden Beispiele für Nutzungs- und Entwicklungsanreize beschrieben, die ihre Entwickler dazu veranlassten, völlig unterschiedliche Ansätze für dasselbe Feld zu verwenden - Messaging zwischen Systemen mit einem Zwischenbroker. Wir werden diese Technologien von Grund auf betrachten und die Auswirkungen verschiedener Designoptionen auf dem Weg hervorheben. Sie erhalten ein tiefes Verständnis für beide Produkte, ein Verständnis dafür, wie sie verwendet werden sollten und nicht, und ein Verständnis dafür, worauf Sie achten müssen, wenn Sie in Zukunft andere Messaging-Technologien in Betracht ziehen.

Bevor wir anfangen, gehen wir die Grundlagen durch.

Was ist ein Nachrichtensystem und warum wird es benötigt?

Damit zwei Anwendungen miteinander kommunizieren können, müssen sie zunächst eine Schnittstelle definieren. Die Definition dieser Schnittstelle umfasst die Auswahl eines Transports oder Protokolls wie HTTP, MQTT oder SMTP und die Aushandlung der Nachrichtenformate, die die Systeme austauschen. Dies kann ein strenger Prozess sein, z. B. das Definieren eines XML-Schemas mit den Nutzlastanforderungen einer Nachricht, oder es kann viel weniger formal sein, z. B. eine Vereinbarung zwischen zwei Entwicklern, dass ein Teil der HTTP-Anforderung eine Client-ID enthält .

Solange das Nachrichtenformat und die Reihenfolge des Sendens zwischen den Systemen konsistent sind, können sie miteinander interagieren, ohne sich um die Implementierung eines anderen Systems sorgen zu müssen. Die Interna dieser Systeme, wie z. B. eine Programmiersprache oder ein verwendetes Framework, können sich im Laufe der Zeit ändern. Solange der Vertrag selbst unterstützt wird, kann die Interaktion von der anderen Seite unverändert fortgesetzt werden. Die beiden Systeme werden durch diese Schnittstelle effektiv getrennt.

Messaging-Systeme sehen in der Regel die Teilnahme eines Vermittlers zwischen zwei Systemen vor, die interagieren, um den Absender weiter vom Empfänger oder von den Empfängern zu trennen (zu trennen). Gleichzeitig ermöglicht das Nachrichtensystem dem Absender, eine Nachricht zu senden, ohne zu wissen, wo sich der Empfänger befindet, ob er aktiv ist oder wie viele von ihnen.

Schauen wir uns einige Analogien der verschiedenen Probleme an, die ein Messaging-System löst, und führen wir einige grundlegende Begriffe ein.

Punkt zu Punkt

Alexandra geht zur Post, um Adam ein Paket zu schicken. Sie geht zum Fenster und gibt dem Angestellten ein Paket. Der Mitarbeiter holt das Paket ab und gibt Alexandra eine Quittung. Adam muss zum Zeitpunkt des Versands des Pakets nicht zu Hause sein. Alexandra ist zuversichtlich, dass das Paket irgendwann in der Zukunft an Adam geliefert wird und weiterhin ihr eigenes Ding machen kann. Später, irgendwann, erhält Adam das Paket.

Dies ist ein Beispiel für ein Punkt-zu-Punkt- Messaging-Modell. Die Post fungiert hier als Paketverteilungsmechanismus und stellt sicher, dass jedes Paket einmal zugestellt wird. Die Nutzung der Post trennt den Versand des Pakets von der Zustellung des Pakets.
In klassischen Messagingsystemen wird das Punkt-zu-Punkt-Modell über Warteschlangen implementiert. Die Warteschlange fungiert als FIFO-Puffer (First In, First Out), den ein oder mehrere Verbraucher abonnieren können. Jede Nachricht wird nur an einen der abonnierten Verbraucher gesendet. Warteschlangen versuchen normalerweise, Nachrichten fair zwischen Verbrauchern zu verteilen. Nur ein Verbraucher erhält diese Nachricht.

Der Begriff "dauerhaft" wird auf Warteschlangen angewendet. Zuverlässigkeit ist eine Funktion des Dienstes, die sicherstellt, dass das Nachrichtensystem Nachrichten in Abwesenheit aktiver Teilnehmer speichert, bis der Verbraucher die Warteschlange für die Nachrichtenübermittlung abonniert.

Zuverlässigkeit wird oft mit Persistenz verwechselt, und obwohl die beiden Begriffe synonym verwendet werden, erfüllen sie unterschiedliche Funktionen. Die Persistenz bestimmt, ob die Nachricht vom Nachrichtensystem in einem beliebigen Speicher zwischen dem Empfang und dem Senden an den Verbraucher ausgetauscht wird. An die Warteschlange gesendete Nachrichten können dauerhaft sein oder nicht.
Punkt-zu-Punkt-Nachrichten werden verwendet, wenn für einen Anwendungsfall eine einmalige Aktion mit einer Nachricht erforderlich ist. Ein Beispiel ist das Einzahlen von Geldern auf ein Konto oder das Abschließen eines Lieferauftrags. Wir werden später diskutieren, warum das Nachrichtensystem selbst keine einmalige Zustellung bereitstellen kann und warum Warteschlangen bestenfalls eine Zustellungsgarantie mindestens einmal bieten können.

Publisher-Abonnent

Gabriella wählt die Konferenznummer. Während sie mit der Konferenz verbunden ist, hört sie alles, was der Sprecher sagt, zusammen mit den anderen Teilnehmern des Anrufs. Wenn sie abschaltet, überspringt sie das Gesagte. Wenn sie wieder verbunden ist, hört sie weiter, was sie sagen.

Dies ist ein Beispiel für ein Publish-Subscribe- Messaging-Modell. Konferenzen fungieren als Broadcast-Mechanismus. Der sprechenden Person ist es egal, wie viele Personen gerade an dem Anruf teilnehmen - das System stellt sicher, dass jeder, der gerade verbunden ist, hört, was gesagt wird.
In klassischen Messagingsystemen wird das Publish-Subscribe-Messaging-Modell thematisch implementiert. Das Thema bietet dieselbe Broadcast-Methode wie der Konferenzmechanismus. Wenn eine Nachricht an das Thema gesendet wird, wird sie an alle abonnierten Benutzer verteilt .

Themen sind normalerweise nicht zuverlässig (nicht haltbar) . Wie ein Zuhörer, der nicht hört, was in der Telefonkonferenz gesagt wird, überspringen die Themenabonnenten beim Trennen der Verbindung alle Nachrichten, die gesendet werden, wenn sie offline sind. Aus diesem Grund kann gesagt werden, dass Themen eine Zustellgarantie für jeden Verbraucher nur einmal bieten.

Publikations-Abonnement-Nachrichten werden normalerweise verwendet, wenn Nachrichten informativer Natur sind und der Verlust einer Nachricht nicht besonders bedeutend ist. Beispielsweise kann ein Thema einmal pro Sekunde Temperaturwerte von einer Gruppe von Sensoren übertragen. Ein System, das an der aktuellen Temperatur interessiert ist und das Thema abonniert, macht sich keine Sorgen, wenn eine Nachricht übersehen wird - ein anderes wird in naher Zukunft eintreffen.

Hybridmodelle

Auf der Website des Geschäfts werden Bestellnachrichten in die Nachrichtenwarteschlange gestellt. Der Hauptkonsument dieser Nachrichten ist das Exekutivsystem. Darüber hinaus muss das Audit-System über Kopien dieser Auftragsnachrichten für die spätere Verfolgung verfügen. Beide Systeme können keine Nachrichten überspringen, auch wenn die Systeme selbst für einige Zeit nicht verfügbar sind. Eine Website sollte keine Kenntnis von anderen Systemen haben.

Verwendungsszenarien erfordern häufig die Kombination von Publish-Subscribe- und Point-to-Point-Messaging-Modellen, z. B. wenn mehrere Systeme eine Kopie der Nachricht benötigen und sowohl Zuverlässigkeit als auch Persistenz erforderlich sind, um einen Nachrichtenverlust zu verhindern.

In diesen Fällen ist ein Ziel erforderlich (ein allgemeiner Begriff für Warteschlangen und Themen), das Nachrichten hauptsächlich als Thema verteilt, sodass jede Nachricht an ein separates System gesendet wird, das an diesen Nachrichten interessiert ist, an dem jedoch jedes System mehrere definieren kann Verbraucher, die eingehende Nachrichten empfangen, was eher einer Warteschlange ähnelt. Die Art der Lesung ist in diesem Fall für jeden Interessenten einmalig . Diese Hybridempfänger erfordern häufig eine lange Lebensdauer. Wenn der Verbraucher die Verbindung trennt, werden Nachrichten, die zu diesem Zeitpunkt gesendet werden, nach dem erneuten Verbinden des Verbrauchers empfangen.

Hybridmodelle sind nicht neu und können in den meisten Messagingsystemen verwendet werden, einschließlich ActiveMQ (über virtuelle oder zusammengesetzte Ziele, die Themen und Warteschlangen kombinieren) und Kafka (implizit als grundlegende Eigenschaft des Entwurfs des Adressaten).

Nachdem wir einige grundlegende Begriffe und ein Verständnis dafür haben, wofür ein Messagingsystem nützlich sein könnte, gehen wir nun zu den Details über.

Übersetzung abgeschlossen: tele.gg/middle_java

Nächster Teil: Kapitel 2. ActiveMQ

Fortsetzung folgt...