Asynchrones Messaging mit RabbitMQ

Einordnung — der klassische Message-Broker

RabbitMQ ist der Inbegriff eines klassischen Message-Brokers: ein Server-Programm, das Nachrichten aus einem System entgegennimmt, anhand definierter Regeln in Warteschlangen einsortiert und sie an wartende Consumer ausliefert. Geschrieben in Erlang/OTP — der Sprache, die Ericsson für hochverfügbare Telefonvermittlungen entwickelt hat —, basierend auf AMQP 0-9-1 als Hauptprotokoll, seit 2007 produktiv im Einsatz und unter der Mozilla Public License 2.0 verfügbar.

Wer RabbitMQ kennt, hat das gesamte Vokabular des klassischen Messagings im Kopf: Exchange, Binding, Routing-Key, Queue, Acknowledgement. Dieses Vokabular ist auch in zeitgemäßeren Werkzeugen oft als mentales Modell unterlegt — wer es verstanden hat, versteht mit kleinem Restaufwand ein gutes Drittel jeder anderen Messaging-Plattform mit.

Im Artikel zu Apache Kafka haben wir den Unterschied zwischen einem Streaming-System und einem klassischen Broker bereits skizziert: Kafka ist ein persistenter, partitionierter Commit-Log, in dem Events tagelang oder länger bereitstehen; RabbitMQ ist ein „ich nehme Ihre Nachricht entgegen, liefere sie aus und dann ist sie weg"-Werkzeug. Dieser Artikel beleuchtet RabbitMQ aus eigener Perspektive — was es gut macht, wie es aufgebaut ist, und wo seine Stärken liegen, die ein Streaming-Werkzeug prinzipbedingt nicht erreicht.

Drei klassische Anwendungsfälle ziehen sich durch praktisch jede produktive RabbitMQ-Installation. Erstens: Task-Queues und Worker-Patterns. Eine Anwendung legt eine Aufgabe in eine Queue, ein Pool von Worker-Prozessen arbeitet sie ab — Bildverkleinerung, Mailversand, Report-Generierung, asynchrone API-Aufrufe an externe Systeme, die ihrerseits langsam oder unzuverlässig sind. Zweitens: Pub-Sub-Verteilung. Eine Nachricht wird in einen Exchange geschrieben und an mehrere unabhängige Consumer fan-out verteilt — Benachrichtigungssysteme, Audit-Logs, Webhook-Auslieferungen. Drittens: RPC-ähnliche asynchrone Kommunikation. Ein Service stellt eine Frage und wartet — über eine eindeutige Correlation-ID auf einer eigens dafür geöffneten Reply-Queue —, bis die Antwort zurückkommt. RabbitMQ ist hier der Klassiker, weil das Muster idiomatisch unterstützt wird und nicht erst um andere Werkzeuge herumgebogen werden muss.

Reife und Verbreitung sind unauffällig hoch: VMware (heute Broadcom) trägt die kommerzielle Entwicklung, die Open-Source-Variante ist die Standardwahl in Tausenden produktiver Setups. Bei Cloud-Anbietern existiert RabbitMQ als gemanagter Dienst (CloudAMQP, AWS-Brokered-Services), bei den großen Hyperscalern fehlt eine direkt vergleichbare native Alternative — was die Position des Werkzeugs in Multi-Cloud- und On-Premise-Setups eher stärkt.

Kernkonzepte — Exchange, Binding, Queue

Vier Konzepte halten RabbitMQ zusammen. Wer sie verstanden hat, hat das mentale Modell — der Rest ist Konfiguration.

Queue, Exchange, Binding, Routing-Key

Eine Queue ist eine geordnete Liste von Nachrichten. Nachrichten kommen vorne hinein, werden hinten herausgenommen — FIFO mit kleinen Einschränkungen (Priority-Queues mischen die Reihenfolge nach Priorität, Lazy-Queues halten Inhalte auf Disk statt im RAM). Eine Queue hat einen Namen, ein paar Eigenschaften (durable, exclusive, auto-delete) und wird typischerweise von genau dem Service angelegt, der sie auch liest.

Ein Exchange ist nicht eine Queue, sondern der Verteilmechanismus, der entscheidet, in welche Queues eine Nachricht landet. Producer schreiben immer in Exchanges, niemals direkt in Queues. Diese Trennung ist konzeptionell wichtig: der Producer kennt die Queues nicht, er kennt nur den Exchange und das Routing-Schema. Wer später eine neue Queue für einen neuen Use-Case ergänzt, muss am Producer-Code nichts ändern — eine andere Komponente erstellt einfach ein neues Binding.

Ein Binding verbindet einen Exchange mit einer Queue, optional mit einem Routing-Pattern. „Diese Queue interessiert sich für alle Nachrichten, die mit dem Routing-Key order.* eintreffen" ist ein klassisches Binding. Erst durch Bindings weiß der Exchange, wohin er Nachrichten überhaupt routen soll. Ohne Bindings landet eine Nachricht im Nirwana — sie wird verworfen oder, bei aktiviertem alternate exchange, in eine alternative Auffangstruktur umgeleitet.

Der Routing-Key ist eine Zeichenkette, die der Producer beim Veröffentlichen mitschickt. Der Exchange entscheidet anhand seines Typs, wie der Routing-Key gegen die Bindings ausgewertet wird.

Die vier Exchange-Typen

• Direct Exchange — exakter String-Vergleich. Routing-Key order.created landet in genau jenen Queues, deren Binding diesen Wert hat. Das einfachste Modell, geeignet für punktgenaue Verteilung.
• Topic Exchange — Pattern-Matching mit den Wildcards * (genau ein Wort) und # (null oder mehr Wörter). Binding order.* matcht order.created und order.cancelled, aber nicht order.created.urgent. Binding order.# matcht alle drei. Der Topic Exchange ist der mit Abstand am häufigsten genutzte — flexibel genug für fast jedes praktische Routing, ohne in die Komplexität der Header-Variante zu kippen.
• Fanout Exchange — der Routing-Key wird ignoriert. Jede Nachricht geht in jede gebundene Queue. Das klassische Broadcast-Muster, ideal für Pub-Sub-Szenarien, in denen jeder Consumer unabhängig vom Inhalt jede Nachricht sehen soll.
• Headers Exchange — Routing nicht über den Routing-Key, sondern über Message-Headers (Schlüssel-Wert-Paare). Bindings spezifizieren erforderliche Header-Werte. Selten gebraucht, aber für komplexe Klassifikationen mächtig, in denen mehrere unabhängige Dimensionen kombiniert werden müssen.

Acknowledgements — die Sicherheits­schicht

Wenn ein Consumer eine Nachricht erhält, ist sie nicht aus der Queue gelöscht — sie befindet sich im Zwischenzustand unacked. Erst wenn der Consumer einen Ack schickt, gilt die Nachricht als verarbeitet und wird endgültig entfernt. Stirbt der Consumer in der Zwischenzeit, weil er abstürzt oder die TCP-Verbindung abbricht, geht die Nachricht zurück in die Queue und wird einem anderen Consumer erneut zugestellt. Das ist der Mechanismus, der at-least-once-Zustellung garantiert — kombiniert mit idempotenter Verarbeitung wird daraus effektive Exactly-once-Semantik.

Architektur, Cluster und Plugins

Der RabbitMQ-Server ist ein einzelner Erlang-Prozess oder, im produktiven Einsatz, ein Cluster aus mehreren Knoten. Producer und Consumer kommunizieren über AMQP 0-9-1 — ein binäres Protokoll mit Verbindungen, Channels und Frames. Eine einzige TCP-Verbindung kann mehrere Channels multiplexen; eine Anwendung öffnet typischerweise eine Verbindung pro Prozess und arbeitet darauf mit mehreren Channels parallel.

Über das native AMQP hinaus unterstützt RabbitMQ per Plugin auch AMQP 1.0, MQTT (für IoT-Szenarien), STOMP (für Webclients), HTTP (Management-API) und Streams (das eigene Binärprotokoll für die neueren Stream-Queues). Diese Polyglottie ist eines der Argumente für RabbitMQ in heterogenen Umgebungen: ein Broker, mehrere Protokolle, ein einheitliches Routing-Modell.

Cluster und Quorum Queues

Mehrere RabbitMQ-Knoten lassen sich zu einem logischen Cluster zusammenfassen. Metadaten (Vhosts, Exchanges, Bindings, Benutzer) werden über den Raft-Konsens auf allen Knoten konsistent gehalten. Queues hatten historisch eine Heimat-Node — sie lebten auf einem konkreten Knoten und wurden bei dessen Ausfall unverfügbar. Mit Quorum Queues, eingeführt in RabbitMQ 3.8 und seit 3.10 als Standard für Produktion empfohlen, hat sich das geändert: eine Quorum Queue wird auf mehreren Knoten repliziert und übersteht einen Knoten-Ausfall ohne Datenverlust. Wer heute neu aufsetzt, sollte fast immer Quorum Queues nutzen — die klassischen Mirrored Queues sind in Version 4 als deprecated geführt und werden mittelfristig entfernt.

Vhost, Management-UI, Federation

Ein Vhost (virtueller Host) ist eine logische Trennung innerhalb eines Brokers — eigene Exchanges, eigene Queues, eigene Benutzerrechte. Wird in Multi-Tenant-Setups oder als Trennung zwischen Umgebungen (dev/prod) genutzt. Ein Vhost ist im Wesentlichen ein Namespace.

Das Management-Plugin bringt ein Web-Frontend und eine HTTP-API mit. Nach Aktivierung steht auf Port 15672 eine vollwertige Operator-Oberfläche zur Verfügung: Cluster-Status, Queue-Inhalte, Verbindungen, Channels, Statistiken. Über dieselbe HTTP-API lassen sich diese Daten automatisiert lesen und schreiben — Provisioning per CI/CD ist damit ohne separates Werkzeug möglich.

Federation und Shovel sind zwei Plugins für Multi-Cluster-Szenarien. Federation verbindet Exchanges oder Queues über Cluster-Grenzen: Nachrichten, die auf Cluster A in einem föderierten Exchange landen, werden automatisch auf Cluster B repliziert. Shovel ist die brutalere Variante — ein konfigurierbarer Helfer-Prozess, der Nachrichten aus einer Queue eines Clusters in eine Queue eines anderen Clusters schaufelt, mit explizit konfigurierbarer Quellen- und Zielangabe. Beide Werkzeuge sind die Antwort auf das Cluster-Topologie-Problem in geografisch verteilten Setups.

Datenfluss im Bild

Die folgende Abbildung zeigt das zentrale Muster: ein Producer veröffentlicht in einen Topic Exchange mit einem konkreten Routing-Key. Drei Queues sind an den Exchange gebunden — jede mit ihrem eigenen Pattern — und nehmen die für sie relevanten Nachrichten an. An jeder Queue hängt ein Consumer, der die Nachrichten abholt und nach erfolgreicher Verarbeitung quittiert.

Setup und ein erstes Beispiel

Ein lauffähiges RabbitMQ-Setup ist in einer einzelnen Zeile gestartet. Für Produktion sind drei Knoten plus passende Quorum-Queue-Konfiguration nötig; das hier gezeigte Single-Node-Setup eignet sich für Entwicklung und das schnelle Durchspielen der Konzepte.

Schritt 1 — Broker mit aktiviertem Management-UI starten:

docker run -d --name rabbit \
  -p 5672:5672 -p 15672:15672 \
  -e RABBITMQ_DEFAULT_USER=admin \
  -e RABBITMQ_DEFAULT_PASS=admin \
  rabbitmq:3.13-management

Port 5672 ist AMQP für Producer und Consumer, Port 15672 das Web-Frontend. Anmeldung im Browser: http://localhost:15672 mit admin/admin. Im UI lassen sich Exchanges, Queues und Bindings direkt anlegen — für eine erste Erkundung ist das oft der schnellste Weg.

Schritt 2 — ein Python-Producer über die Bibliothek pika:

import pika, json

params = pika.ConnectionParameters(
    host        = 'localhost',
    credentials = pika.PlainCredentials('admin', 'admin'))
connection = pika.BlockingConnection(params)
channel    = connection.channel()

# Exchange anlegen (idempotent)
channel.exchange_declare(
    exchange      = 'orders.events',
    exchange_type = 'topic',
    durable       = True)

# Nachricht veröffentlichen
channel.basic_publish(
    exchange    = 'orders.events',
    routing_key = 'order.created',
    body        = json.dumps({
        'order_id':    1001,
        'customer_id': 42,
        'total':       99.95,
    }),
    properties  = pika.BasicProperties(
        delivery_mode = pika.spec.PERSISTENT_DELIVERY_MODE,
        content_type  = 'application/json',
        message_id    = 'msg-1001'))

connection.close()

Die Zeile delivery_mode=PERSISTENT_DELIVERY_MODE ist entscheidend: ohne sie überlebt die Nachricht keinen Broker-Restart, weil sie nur im RAM gehalten wird. Für jede Nachricht, deren Verlust nicht egal ist, gehört dieser Schalter gesetzt — kombiniert mit durable=True beim Exchange und der Queue.

Schritt 3 — der passende Consumer mit Quorum-Queue, Binding und manuellem Ack:

import pika, json

connection = pika.BlockingConnection(
    pika.ConnectionParameters(
        host        = 'localhost',
        credentials = pika.PlainCredentials('admin', 'admin')))
channel = connection.channel()

# Quorum Queue + Binding deklarieren (idempotent)
channel.queue_declare(
    queue     = 'billing.q',
    durable   = True,
    arguments = {'x-queue-type': 'quorum'})

channel.queue_bind(
    queue       = 'billing.q',
    exchange    = 'orders.events',
    routing_key = 'order.*')

# Prefetch: maximal 16 unacked Nachrichten gleichzeitig (Backpressure)
channel.basic_qos(prefetch_count=16)

def callback(ch, method, properties, body):
    order = json.loads(body)
    try:
        process_invoice(order)          # idempotent!
        ch.basic_ack(delivery_tag = method.delivery_tag)
    except Exception:
        ch.basic_nack(
            delivery_tag = method.delivery_tag,
            requeue      = False)       # → Dead Letter Exchange

channel.basic_consume(
    queue               = 'billing.q',
    on_message_callback = callback)

channel.start_consuming()

Drei Eigenschaften dieses Codes sind in der Praxis wichtig. Erstens: auto_ack=False (Default in pika) — der Consumer entscheidet selbst, wann eine Nachricht als verarbeitet gilt. Zweitens: prefetch_count=16 — RabbitMQ schickt höchstens 16 Nachrichten pro Channel im Voraus, bevor er auf Acks wartet. Backpressure ist damit eingebaut: ein langsamer Consumer hält den Broker nicht von der Verteilung an andere Consumer ab. Drittens: requeue=False bei einem Fehler — die fehlgeschlagene Nachricht wird nicht endlos in die Queue zurückgeworfen, sondern (mit Dead-Letter-Konfiguration, siehe nächster Abschnitt) in eine Quarantäne-Queue verschoben. Wer das vergisst, baut sich Endlosschleifen mit allen verbundenen Konsequenzen für CPU-Last und Logvolumen.

Erweiterte Features — DLX, TTL, Priority, Streams

Über die vier Grundkonzepte hinaus bietet RabbitMQ eine Reihe von Bausteinen, die in produktiven Setups regelmäßig gebraucht werden.

Dead Letter Exchange (DLX)

Eine Queue lässt sich so konfigurieren, dass abgewiesene oder abgelaufene Nachrichten nicht verloren gehen, sondern in einen anderen Exchange umgeleitet werden. Damit entsteht ein Quarantäne-Pfad für fehlgeschlagene Verarbeitungen:

channel.queue_declare(queue='billing.q', durable=True, arguments={
    'x-queue-type':              'quorum',
    'x-dead-letter-exchange':    'orders.dlx',
    'x-dead-letter-routing-key': 'billing.failed',
})

Dahinter steht typischerweise eine eigene parking- oder quarantine-Queue, in der fehlgeschlagene Nachrichten landen — sie wird manuell oder über ein dediziertes Werkzeug inspiziert, korrigiert und ggf. erneut eingespielt. Wer DLX nicht aktiviert hat, verliert fehlgeschlagene Nachrichten still und unauffällig.

Message-TTL und Queue-TTL

Pro Nachricht oder pro Queue lässt sich eine Lebenszeit konfigurieren. Nach Ablauf wandert die Nachricht ins Dead-Letter-Exchange (falls konfiguriert) oder wird verworfen. In Kombination mit DLX ist das ein häufiges Muster für „Bearbeitungstimeout": eine Nachricht muss innerhalb von 30 Sekunden konsumiert sein, sonst landet sie in der Fehler-Queue zur manuellen Sichtung.

Priority Queues

Eine Queue mit dem Argument x-max-priority erlaubt Priority-Werte pro Nachricht zwischen 0 und N. Höhere Priorität wird zuerst ausgeliefert. Nützlich für „dringende Bestellung zuerst"-Szenarien — eine Eigenschaft, die Apache Kafka prinzipbedingt nicht hat, weil dort innerhalb einer Partition strikt FIFO gilt.

Plugins und Polyglottie

Über die Standardarchitektur hinaus existieren offizielle Plugins für MQTT (IoT-Geräte), STOMP (Webclients), AMQP 1.0 (das modernere Geschwisterprotokoll von AMQP 0-9-1), LDAP-Auth, OAuth2, Shovel und Federation. Plugins werden zur Laufzeit aktiviert und deaktiviert (rabbitmq-plugins enable …). Die Plugin-Architektur ist eine der stillen Stärken von RabbitMQ gegenüber moderneren Werkzeugen — sie erlaubt es, den Broker auf die jeweilige Umgebung zuzuschneiden, ohne den Code anzufassen.

Streams — die Antwort auf Kafka

Mit Version 3.9 hat RabbitMQ einen neuen Queue-Typ eingeführt: Streams. Dahinter steckt ein append-only Log nach Kafka-Vorbild. Streams können wiederholt gelesen werden, halten Nachrichten unabhängig vom Konsum vor und nutzen ein eigenes Binärprotokoll für höheren Durchsatz. RabbitMQ Streams werden Kafka nicht ersetzen — die operative Tiefe und das Ökosystem (Connect, Schema Registry, Streams-Bibliothek) sind eine andere Klasse —, aber sie schließen die größte Funktionslücke für Setups, in denen RabbitMQ sonst aus rein streamfähigen Gründen verlassen worden wäre.

Wann RabbitMQ passt — und wann das Streaming-Werkzeug

Aus den Stärken ergibt sich das Anwendungsprofil. Ein klares Bild hilft bei der Werkzeugwahl mehr als jede Feature-Liste.

Passend, wenn …

• klassische Task-Queues und Worker-Pools abgebildet werden — Bilder verarbeiten, Mails versenden, lange Reports berechnen, asynchrone Aufrufe an externe Systeme;
• das Routing fachlich komplex ist und sich gut über Exchange-Typen, Routing-Keys und Header abbilden lässt;
• RPC-ähnliche Request-Reply-Muster gebraucht werden — Reply-Queue mit Correlation-ID, idiomatisch in RabbitMQ, mühsam in Streaming-Werkzeugen;
• Priority Queues, Per-Message-TTL oder Dead-Letter-Queues mit fein einstellbarer Politik nötig sind;
• das System polyglott angebunden wird — AMQP, MQTT, STOMP, HTTP nebeneinander, im selben Broker;
• das absehbare Volumen die Kapazität des Brokers nicht annähernd ausschöpft und der operative Aufwand minimal sein soll.

Weniger geeignet, wenn …

• Events dauerhaft gehalten und mehrfach konsumiert werden sollen — dann ist Apache Kafka die richtige Antwort. Den Vergleich haben wir im Kafka-Artikel ausführlich beleuchtet;
• der Durchsatz dauerhaft über mehreren zehntausend Nachrichten pro Sekunde liegt — RabbitMQ skaliert hier nicht so weit wie ein Streaming-System;
• Replay-Mechanismen Teil der Anforderung sind — die klassischen Queues kennen das Konzept nicht; die neuen Streams sind ein Kompromiss, aber kein vollständiger Kafka-Ersatz;
• Stream-Processing direkt am Broker erwartet wird — Aggregationen, Joins, Zeitfenster über Live-Daten sind eine Kafka-Streams- oder Flink-Domäne.

In den meisten Plattformen, mit denen wir arbeiten, kommen RabbitMQ und Kafka nebeneinander zum Einsatz — nicht gegeneinander. RabbitMQ als pragmatische Task-Queue für die operativen Hintergrundarbeiten, Kafka als zentrales Event-Backbone für die fachlichen Ereignisse einer Plattform. Die zwei Werkzeuge konkurrieren weniger, als es ihre Vergleichstabellen oft vermuten lassen — sie ergänzen sich, wenn man ihre Stärken sauber trennt. Wer beide kennt und ihre Rollen klar zuweist, baut Architekturen, die schneller liefern, leichter skalieren und sich operativ ehrlich verteidigen lassen.