Einführung in Nachrichtenqueues und ihre Anwendungsfälle

Aufgrund der zunehmenden Komplexität der digitalen Stacks vieler Unternehmen sind Nachrichtenqueues zu einem unverzichtbaren Bestandteil ihrer Softwarearchitekturen geworden. Anstatt Punkt-zu-Punkt-Integrationen aller Komponenten zu verwalten, ermöglichen Nachrichtenqueues eine asynchrone Kommunikation zwischen den verschiedenen Teilen einer Architektur.

Architekturen, in denen eine queue eine zentrale Komponente ist, werden oft als entkoppelte Systeme bezeichnet. Selbst wenn das empfangende System vorübergehend ausfällt, werden die von den sendenden Systemen erstellten Nachrichten in der queue gespeichert. Dadurch sind diese Systeme wesentlich ausfallsicherer. Außerdem ist die Skalierung einer Architektur weniger aufwendig, da lediglich ein Upgrade der queue und des jeweiligen Senders oder Empfängers erforderlich ist. Es gibt keine Engpässe oder Schwachstellen.

In diesem Artikel erfährst du alles über die Funktionsweise von Nachrichtenqueues, die beliebtesten Technologien und verschiedene Anwendungsfälle für den Einstieg.

Was ist eine Nachrichtenqueue?

Im Grunde ist eine Nachrichtenqueue wie ein Briefkasten. Jemand (der Absender) wirft einen Brief (die Nachricht) in einen Briefkasten (die Nachrichtenqueue), der dann vom Empfänger (dem Abonnenten) abgeholt wird. Es gibt jedoch einen Unterschied: In einer Nachrichtenqueue können mehrere Empfänger die Nachricht erhalten.

Absender und Empfänger müssen nicht gleichzeitig aktiv sein. Die queue fungiert wie ein Puffer; sie speichert Nachrichten, bis der Empfänger bereit ist, sie zu empfangen.

Publisher

Der Publisher (oder Produzent) erstellt und versendet Nachrichten. Das kann alles Mögliche sein – ein Server, der Protokolle erzeugt, eine Anwendung, die Daten an eine Datenbank sendet, oder sogar ein cloud-Speicher-Bucket, der CSV-Dateien zeilenweise versendet. In einem entkoppelten System arbeitet der Publisher unabhängig, ohne sich darum zu kümmern, wer die Nachrichten abruft.

Nachricht

Die Nachricht enthält die eigentlichen Daten, die vom Publisher an den Subscriber übertragen werden. Das kann alles Mögliche sein, von einer einfachen Textzeichenfolge oder einem JSON-Objekt bis hin zu einem XML-Dokument oder sogar serialisiertem Code. Eine Nachricht enthält in der Regel Header mit Metadaten. Diese liefern Kontext und Anweisungen zur Nachricht selbst, zum Beispiel die Absender-ID, den Zeitstempel, die Priorität oder in manchen Systemen Informationen zum vorgesehenen Empfänger.

Nachrichtenqueue

Die Nachrichtenqueue speichert Nachrichten vorübergehend und ist dafür zuständig, die Nachricht an einen oder mehrere Abonnenten zu übermitteln. Manche Nachrichtenqueues unterstützen die Einhaltung einer bestimmten Reihenfolge der Nachrichten, wie zum Beispiel „First-In-First-Out“. Eine geordnete Zustellung kann jedoch gewisse Kompromisse mit sich bringen, etwa in Bezug auf Komplexität und Durchsatz. Wenn sich beispielsweise eine bestimmte Nachricht verzögert, während sie darauf wartet, verarbeitet zu werden, kann sie alle nachfolgenden Nachrichten in der Queue blockieren, was dazu führt, dass die Queue schnell anwächst.

Abonnent

Der Abonnent (oder Konsument) überwacht die queue und entnimmt (relevante) Nachrichten, um sie zu verarbeiten. Wie ein Herausgeber kann auch ein Abonnent alles Mögliche sein: eine andere Anwendung, ein Dienst zur Aktualisierung einer Datenbank oder jede andere Komponente, die die Informationen benötigt.

Thema

Manche Nachrichtenwarteschlangen beinhalten ein Exchange- oder Broker-System – ein Routing-System, das als Verkehrsleiter für Nachrichten fungiert. Der Exchange entscheidet anhand vordefinierter Regeln, welche Queue oder welcher Abonnent eine Nachricht erhalten soll. Eine gängige Art von Exchange ist der Topic Exchange. Bei diesem Ansatz werden Nachrichten mit einem Routing-Schlüssel versehen – einer durch Punkte getrennten Zeichenfolge. Abonnenten oder Queues nutzen Bindungsschlüssel, um Nachrichten zu filtern und zu abonnieren, die bestimmten Routing-Mustern entsprechen.

Hier ein Beispiel von einer Sport-Website:

Ein Publisher sendet die Endergebnisse von Sportwettkämpfen aus allen Sportarten und allen Ligen weltweit mit Routing-Schlüsseln wie „cricket.india.ipl“ und „soccer.uk.premierleague“. Ein Topic verwendet den Bindungsschlüssel „soccer“, um alle Nachrichten zum Thema Fußball zu bündeln, die Abonnenten abrufen können, um alle Fußballergebnisse aus aller Welt zu erhalten.

Bestätigung

Manche Systeme unterstützen die Bestätigung (oder „ack“) von Nachrichten, um eine zuverlässige Nachrichtenübermittlung zu gewährleisten. Im Wesentlichen handelt es sich dabei um ein Signal vom Verbraucher an die queue, dass eine Nachricht erfolgreich empfangen und verarbeitet wurde. Dies gewährleistet eine Zustellgarantie (Verhinderung von Nachrichtenverlusten) und verhindert die doppelte Verarbeitung von Nachrichten. Es gibt verschiedene Strategien zur Zustellgarantie:

• „At-most-once“. Keine Zustellungsgarantie.
• At-least-once. Nachrichten werden mindestens einmal zugestellt, können aber auch doppelt vorkommen.
• Exactly-once. Nachrichten werden genau einmal zugestellt. Dies ist das komplexeste System in der Umsetzung, da du für jede Verbindung zwischen den beiden Systemen ein separates Topic konfigurieren musst.

Messaging-Muster

Messaging-Systeme folgen einer Reihe von Kommunikationsmustern, wobei jedes Muster unterschiedliche Anwendungsfälle unterstützt.

• Eins-zu-eins. Nachrichten werden über ein einziges Thema von einem einzelnen Publisher an einen einzelnen, vordefinierten Subscriber zugestellt.
• Eins-zu-vielen (Fan-out). Nachrichten werden über ein Thema von einem einzelnen Publisher an mehrere Consumer übermittelt. Um sicherzustellen, dass mindestens ein Consumer die Nachricht liest, kann eine „At-Least-Once“-Zustellungsgarantie eingesetzt werden. Um jedoch zu gewährleisten, dass alle Subscriber die Nachricht erhalten und verarbeiten (Atomarität), sind einige zusätzliche Schritte erforderlich, die als Zwei-Phasen-Muster (2PC) oder Saga-Muster bekannt sind.
• Viele-zu-Eins (Fan-In). Bei einem Viele-zu-Eins-Muster werden Nachrichten über ein Thema von mehreren Publishern an einen einzigen Consumer übermittelt. Dieses Muster wird typischerweise verwendet, wenn mehrere Systeme Datenströme erzeugen, wie z. B. Logs oder Datenbankänderungen, die in einem einzigen System gesammelt und gespeichert werden.
• Viele-zu-viele (mit Lastenausgleich). Schließlich werden bei einem Viele-zu-viele-Muster Nachrichten über ein Thema von mehreren Publishern an mehrere Consumer übermittelt. Wie beim Eins-zu-viele-Muster erfordert die Gewährleistung der Atomarität einige zusätzliche technische Maßnahmen.

Beliebte Technologien für Nachrichtenqueues

Bevor wir zu den Anwendungsfällen aus der Praxis übergehen, wollen wir einige beliebte Technologien für Nachrichtenqueues besprechen.

RabbitMQ

RabbitMQ ist ein ausgereiftes Produkt und wird in IoT-Umgebungen weit verbreitet eingesetzt. Obwohl die Einrichtung nur wenige Minuten dauert, ist es für seine sehr geringe Latenz bekannt. Außerdem unterstützt es komplexe Routing-Anwendungsfälle. RabbitMQ ist open source und wird, obwohl es in Erlang geschrieben ist, von den meisten Programmiersprachen unterstützt.

ActiveMQ

Genau wie RabbitMQ ist ActiveMQ ein ausgereiftes und weit verbreitetes Produkt. Es ist komplett in Java geschrieben und eignet sich besonders gut für Java-basierte Unternehmensumgebungen. Zwar erreicht es nicht die niedrige Latenz von RabbitMQ und ist in Bezug auf Routing-Features nicht ganz so fortschrittlich, eignet sich aber aufgrund seiner horizontalen Skalierbarkeit besser für Anwendungen mit hohem Durchsatz. Es ist ebenfalls open source und wird von vielen Programmiersprachen unterstützt.

Apache Kafka

Kafka ist ein modernes Warteschlangensystem mit Echtzeitverarbeitung und Datenmanipulation. Es hat sich in den letzten Jahren als die erste Wahl für Streaming-Anwendungen etabliert. Dank seiner verteilten Architektur weist es eine geringe Latenz auf, unterstützt hohen Durchsatz und ist fehlertolerant. Der Nachteil ist, dass es aufgrund seines verteilten Aufbaus schwieriger einzurichten und teurer zu warten ist. Kafka ist zwar open source, wird aber von vielen Anbietern als Service angeboten, darunter auch vom ursprünglichen Entwickler bei Confluent.

Message queues als Service: Amazon SQS, Azure Service Bus und GCP Pub/Sub

Das bringt uns zu den Managed Services. Jeder der drei größten Cloud-Dienstleister verfügt über eine eigene Message-Queue-Technologie. Allen gemeinsam ist, dass sie sich nahtlos in Dutzende anderer Cloud-Dienste ihres jeweiligen Anbieters integrieren lassen. Allerdings zeichnen sie sich jeweils durch einen bestimmten Aspekt aus. Der Azure Service Bus ist funktionsreich und unterstützt komplexe Anwendungsfälle. Amazon SQS ist kostengünstig. Es glänzt weder durch Geschwindigkeit und Durchsatz noch durch Features, bietet aber das beste Preis-Leistungs-Verhältnis. Schließlich hat GCP Pub/Sub die geringste Latenz und den höchsten Durchsatz, doch sein Preismodell ist komplex und kann zu unerwarteten Kosten führen.

Message queues in the practice

Nachdem wir uns nun einen Überblick über Nachrichtenqueues und ihre Features verschafft haben, ist es an der Zeit, verschiedene Anwendungsfälle aus unterschiedlichen Branchen zu skizzieren.

Anwendungsfall 1: Zahlungsabwicklung

Zahlungsabwicklungssysteme wie Stripe nutzen eine queue, um die asynchrone Kommunikation zwischen verschiedenen Komponenten der Zahlungsabwicklungspipeline zu verwalten. Wenn ein Kunde eine Zahlung auslöst, veröffentlicht die Webanwendung eine „payment_request“-Nachricht in der queue. Diese Nachricht enthält wichtige Details wie die Kunden-ID, die Bestell-ID, den Betrag und die Zahlungsmethode.

Ein geeigneter Routing-Schlüssel für dieses Szenario könnte „payment.process“ sein, was bei Bedarf eine Filterung und Priorisierung ermöglicht. Da möglicherweise mehrere Dienste auf eine erfolgreiche Zahlung reagieren müssen (zum Beispiel Lagerverwaltung, Versand und Buchhaltung), ist ein „One-to-Many“-Messaging-Muster angebracht, eventuell mit einem Broker, um die Datenkonsistenz zu gewährleisten. Ein Saga-Muster kann im Falle von Fehlern in nachgelagerten Diensten alle Änderungen rückgängig machen. Schließlich benötigt das System eine „At-Least-Once“-Zustellungsgarantie, um sicherzustellen, dass keine Zahlungsanfragen verloren gehen, selbst bei vorübergehenden Ausfällen.

Anwendungsfall 2: Mobile Multiplayer-Spiele

In mobilen Spielen veröffentlicht jeder Spielserver in der Regel Ereignisse aus dem Spiel – wie Spieleraktionen, Aktualisierungen des Spielzustands und Chat-Nachrichten – an die Nachrichtenqueue unter Verwendung geeigneter Routing-Schlüssel wie "game.{game_id}.event" or "player.{player_id}.action"

So würde das funktionieren:

• Wenn Spieler an einem Online-Event teilnehmen, wie zum Beispiel einem Dungeon-Raid, abonnieren sie die Ereignisse für diese bestimmte Dungeon-Instanz.
• Jedes Mal, wenn Spieler interagieren – sei es, dass sie sich auf derselben Karte begegnen, sich Textnachrichten schicken oder in einen Kampf verwickelt werden –, abonnieren sie die Ereignisse des jeweils anderen.
• Ein „notification_service“ würde relevante Themen abonnieren, um Ereignisse zu erfassen, die Benachrichtigungen auslösen, wie zum Beispiel das Erreichen eines Highscores, das Erhalten einer Freundschaftsanfrage oder den Start eines neuen Spiels. Dieser Dienst würde dann Benachrichtigungen generieren und über einen Push-Benachrichtigungsdienst an die Geräte der Spieler senden.

Für dieses Szenario ist eine „At-Least-Once“-Zustellungsgarantie entscheidend, um sicherzustellen, dass wichtige Spielereignisse und Benachrichtigungen nicht verloren gehen. Das Messaging-Muster wäre „Viele-zu-Viele“, da mehrere Spieler miteinander und mit dem Spielserver interagieren. Im Gaming spielt Latenz eine große Rolle, daher ist ein 2PC-Muster nicht geeignet. Ein Saga-Muster kann jedoch die Datenkonsistenz über verschiedene Spieledienste hinweg gewährleisten.

Anwendungsfall 3: Lastenausgleich

Ein Load Balancer würde zunächst alle eingehenden Anfragen empfangen. Anstatt sie direkt an Backend-Server weiterzuleiten, würde der Load Balancer jede Anfrage als Nachricht in die Queue stellen. Mehrere Worker-Instanzen würden diese Queue abonnieren, die Nachrichten abrufen und die Anfragen verarbeiten. Die Queue verteilt die Arbeitslast effektiv auf die verfügbaren Worker und stellt so sicher, dass kein einzelner Server überlastet wird. Dieser Ansatz sorgt zudem für Ausfallsicherheit: Wenn ein Worker ausfällt, verbleibt die Nachricht in der Queue, bis ein anderer Worker sie übernimmt.

Ein geeigneter Routing-Schlüssel für dieses Szenario könnte „request.process“ sein, was in Zukunft eine mögliche Priorisierung oder Filterung von Anfragen ermöglicht. Eine „At-Least-Once“-Zustellungsgarantie ist notwendig, um sicherzustellen, dass keine Anfrage aufgrund von Worker-Ausfällen verloren geht. Das Messaging-Muster ist hier eindeutig „Eins-zu-Viele“, da eine einzelne Anfrage-Nachricht von einem von vielen verfügbaren Workern verarbeitet wird.

Anwendungsfall 4: Daten-Streaming

Angenommen, du möchtest alle Datenbankänderungen nachverfolgen: Ein Debezium-Konnektor wird neben einer Datenbank bereitgestellt, um deren Änderungen zu erfassen. Diese Änderungen werden in Ereignisse umgewandelt und in eine queue veröffentlicht. Die queue fungiert als zentraler Knotenpunkt für die Verteilung dieser Änderungsereignisse an verschiedene Verbraucher. Eine Streaming-Plattform wie Kafka kann genutzt werden, um die Ereignisse in Echtzeit zu transformieren und sie für Echtzeitanalysen in das Data Warehouse zu laden.

Eine geeignete Strategie für den Routing-Schlüssel könnte „database.{db_name}.{table_name}.{operation}“ lauten, wodurch Abonnenten Ereignisse anhand der jeweiligen Datenbank, Tabelle oder des Operationstyps (create, update, delete) filtern können.  Eine „At-Least-Once“-Zustellungsgarantie ist wichtig, um sicherzustellen, dass dem Data Warehouse keine Datenbankänderungen entgehen. Das Messaging-Muster ist hier typischerweise „Eins-zu-Viele“, da ein einzelnes Datenbankänderungsereignis neben dem Data Warehouse auch für mehrere Abnehmer relevant sein kann.

Wie Upsun die Verwaltung von Nachrichtenqueues vereinfacht

Das Einrichten und Betreiben von Nachrichten-Queues sollte kein spezielles DevOps-Team erfordern. Upsun verwandelt komplexe Vorgänge rund um Nachrichten-Queues in einfache, entwicklerfreundliche Workflows, sodass du dich auf die Entwicklung von Features konzentrieren kannst, statt die Infrastruktur zu verwalten.

In wenigen Minuten bereitstellen

Die herkömmliche Einrichtung von Nachrichtenqueues umfasst Dutzende von Konfigurationsschritten, Sicherheitshärtung und umfangreiche Tests. Du verbringst Tage damit, Software zu installieren, Benutzerberechtigungen zu konfigurieren, SSL-Zertifikate einzurichten, Clustering für Hochverfügbarkeit einzurichten, Überwachung und Benachrichtigungen zu konfigurieren, automatisierte backups einzurichten und Sicherheitshärtungsmaßnahmen durchzuführen.

Mit Upsun definierst du einfach deine Anforderungen in einer Konfigurationsdatei, und wir kümmern uns um alles andere. Innerhalb weniger Minuten hast du eine produktionsbereite Message-Queue mit bereits konfiguriertem automatischem Clustering, SSL-Verschlüsselung, Überwachung, backups und Sicherheitspatches.

Testen mit echten Produktionsdaten in der Produktivumgebung

Die größte Herausforderung bei Nachrichtenqueues besteht darin, dass lokale Entwicklungsumgebungen das Verhalten in der Produktivumgebung nicht nachbilden können. Nachrichten, die auf deinem Laptop einwandfrei funktionieren, können bei echten Datenmengen und -mustern spektakulär fehlschlagen.

Upsun löst das durch perfektes Klonen der Umgebung. Du kannst sofort eine vollständige Kopie deiner Produktionsumgebung erstellen – einschließlich exakter queue-Konfigurationen, echter Nachrichtenmuster und -volumina, identischer Performance-Merkmale sowie produktionsähnlicher Daten, die optional anonymisiert werden können.

Beispiel: Ein E-Commerce-Unternehmen musste während seiner Hochsaison ein neues Auftragsabwicklungssystem testen. Anstatt zu raten, wie es funktionieren würde, klonte es seine Produktionsumgebung mit echten Black-Friday-Nachrichtenvolumina. So entdeckte und behob das Unternehmen drei Performance-Engpässe noch vor der Bereitstellung und vermied so mögliche Ausfallzeiten an seinem umsatzstärksten Tag.

Intelligente Überwachung 

Die meisten Überwachungstools zeigen dir zwar an, dass etwas nicht stimmt, sagen dir aber nicht, was du dagegen tun kannst. Herkömmliche Überwachungstools melden dir vielleicht „Queue-Entiefeung: 10.000 Nachrichten“ oder „Verzögerung beim Consumer: 5 Minuten“, ohne zu erklären, was das bedeutet oder wie man das Problem behebt.

Die integrierte Observability von Upsun liefert umsetzbare Erkenntnisse. Statt kryptischer Metriken erhältst du klare Problembeschreibungen wie „Zahlungsnachrichten werden nicht in der richtigen Reihenfolge verarbeitet“ mit Lösungsvorschlägen wie „Single-Active-Consumer-Modus aktivieren“ und Ein-Klick-Lösungsoptionen.

Automatische Skalierung 

Der Datenverkehr in Nachrichtenqueues ist unvorhersehbar. Ein viraler Social-Media-Beitrag oder ein Blitzverkauf kann dein System sofort überlasten. Upsun skaliert deine Nachrichtenqueues automatisch entsprechend der Echtzeit-Nachfrage.

Bei normalem Datenverkehr laufen deine queues mit minimalen Ressourcen, um die Kosten niedrig zu halten. Bei Datenverkehrsspitzen skaliert das System sofort nach oben, um die Last zu bewältigen. Sobald die Spitze vorbei ist, werden die Ressourcen automatisch wieder heruntergefahren. Dir wird nur das berechnet, was du tatsächlich nutzt.

Integration in deinen Entwicklungs-Workflow

Upsun-Nachrichtenqueues lassen sich nahtlos in deine bestehenden Tools und Prozesse integrieren.

Jede Änderung an deiner Queue-Konfiguration durchläuft deinen normalen Code-Review-Prozess mithilfe einer Git-basierten Konfiguration, wodurch „Konfigurationsabweichungen“ zwischen den Umgebungen vermieden werden. Die Verbindungsdaten der Queues werden automatisch als Umgebungsvariablen in deine Anwendungen eingefügt, sodass keine fest codierten Anmeldedaten oder manuelle Konfigurationsaktualisierungen mehr erforderlich sind.

Du kannst deine Anwendungsmetriken, die Datenbankperformance und den Zustand der Nachrichtenqueue in einem einheitlichen Dashboard einsehen, sodass du nicht mehr zwischen mehreren Überwachungstools hin- und herwechseln musst.

Fazit

Nachrichtenqueues sind zum Rückgrat moderner, skalierbarer Anwendungen geworden – doch ihre Implementierung und Verwaltung sollte deinen Entwicklungsprozess nicht verlangsamen. Auch wenn die Konzepte einfach sind, kann die operative Komplexität des Betriebs von Nachrichtenqueues in der Produktivumgebung schnell überwältigend werden.

Die Verwaltung von Zustellgarantien, Dauerhaftigkeit, Persistenz und Reihenfolge über verschiedene Queues hinweg ist komplex und fehleranfällig. Jeder Broker hat seine eigenen Konfigurationsnuancen, Überwachungsanforderungen und Ausfallmodi, deren korrekte Handhabung spezielles Fachwissen erfordert.

Hier kommt Upsun ins Spiel. Als entwicklerorientierte cloud-basierte Anwendungsplattform nimmt Upsun dir den betrieblichen Aufwand ab, indem es vorkonfigurierte, praxiserprobte Setups sowohl für RabbitMQ als auch für Kafka bereitstellt, die Probleme hinsichtlich Dauerhaftigkeit, Persistenz und Reihenfolge von Haus aus lösen. Egal, ob du RabbitMQ für komplexe Routing-Szenarien oder Kafka für Streaming mit hohem Durchsatz benötigst – Upsun bietet vollständig verwaltete Dienste mit automatischer Skalierung, Überwachung und Wartung.

Die integrierte Überwachung von Upsun geht über einfache Metriken hinaus: Sie zeigt dir genau, wann Nachrichten in falscher Reihenfolge verarbeitet werden oder wann Garantien zur Dauerhaftigkeit verletzt werden – noch bevor deine Kunden es bemerken. Mit dem Git-basierten Workflow und dem sofortigen Klonen von Umgebungen bei Upsun kannst du deine Nachrichtenqueues vor der Bereitstellung mit produktionsnahen Daten testen und so das Rätselraten vermeiden, das oft zu Problemen in der Produktivumgebung führt.

Bist du bereit, Nachrichtenqueues ohne betriebliche Kopfschmerzen zu implementieren? Fang noch heute mit Upsun an und konzentriere dich auf das Wesentliche: deine Anwendungslogik, nicht das Infrastrukturmanagement.