Was sind gängige RabbitMQ-Nachrichtenmuster und wann werden sie verwendet?

RabbitMQ-Nachrichtenmuster entscheiden, ob ein Worker einen Job erledigt, jeder Abonnent ein Ereignis erhält oder ein Dienst auf eine Antwort wartet. Wenn Sie das falsche Muster wählen, kann Ihr System Arbeit duplizieren, nützliche Ereignisse verlieren oder bei Aufrufen blockieren, die asynchron hätten bleiben sollen.

RabbitMQ bietet Ihnen Exchanges, Queues, Bindings, Bestätigungen und Nachrichteneigenschaften. Die nützliche Entwurfsarbeit besteht darin, zu wählen, wie diese Teile zu Ihrer Anwendung passen. Die gängigen Muster sind Work Queues, Publish/Subscribe, Direct- oder Topic-Routing und Request/Reply.

---

Work Queues: Jobs auf Worker verteilen

Das Work-Queue-Muster, oft auch als Task Queue bezeichnet, ist das einfachste und häufigste Nachrichtenmuster zur Verteilung zeitaufwändiger Aufgaben auf mehrere Worker-Prozesse (Consumer).

Funktionsweise

1. Ein Producer sendet Aufgaben (Nachrichten) an eine einzelne Queue.
2. Mehrere Consumer (Worker) hören auf dieselbe Queue.
3. RabbitMQ liefert jede Nachricht an einen Consumer, sodass die Worker den Rückstand teilen.

Standardmäßig verteilt RabbitMQ Nachrichten im Round-Robin-Verfahren auf die aktiven Consumer. Diese Verteilung ist nicht immer fair, wenn ein Worker langsame Jobs erhält, während ein andere schnelle Jobs bekommt. Daher wird dieses Muster normalerweise mit Bestätigungen und einem Prefetch-Limit kombiniert.

Bestätigungen verwenden

Mit manuellen Bestätigungen teilt ein Worker RabbitMQ mit, wann eine Aufgabe abgeschlossen ist. Wenn der Worker stirbt, bevor er basic_ack sendet, kann RabbitMQ diese Nachricht erneut in die Queue einreihen und an einen anderen Consumer zustellen. Das macht eine Work Queue nützlich für Berichtserstellung, Bildverarbeitung, Abrechnungsjobs oder jede Aufgabe, die Sie nicht stillschweigend verlieren möchten.

Prefetch-Anzahl festlegen

basic.qos steuert, wie viele unbestätigte Nachrichten ein Consumer gleichzeitig halten kann. Ein prefetch_count von 1 ist ein sicherer Ausgangspunkt für langsame, ungleichmäßige Jobs, da RabbitMQ diesem Consumer keinen zweiten Job sendet, bis er den ersten bestätigt hat. Bei schnelleren Jobs können Sie den Wert nach Messung von Durchsatz und Speichernutzung erhöhen.

Implementierungsbeispiel (Konzeptionell)

# Consumer-Einrichtung für faire Verteilung
channel.basic_qos(prefetch_count=1)
channel.basic_consume(queue='task_queue', on_message_callback=worker_function)

# Worker-Logik muss nach erfolgreicher Verarbeitung eine Bestätigung senden
worker_function(ch, method, properties, body):
    # Aufgabe verarbeiten...
    ch.basic_ack(delivery_tag=method.delivery_tag)

Publish/Subscribe: Ereignisse senden

Das Pub/Sub-Muster dient zum gleichzeitigen Senden von Nachrichten an mehrere interessierte Consumer. Im Gegensatz zu Work Queues, bei denen jede Nachricht nur von einem Worker konsumiert wird, stellt Pub/Sub sicher, dass jeder verbundene Abonnent eine Kopie der Nachricht erhält.

Einen Fanout-Exchange verwenden

Ein Producer veröffentlicht an einen Fanout-Exchange. Der Exchange ignoriert Routing-Keys und kopiert die Nachricht an jede daran gebundene Queue. Jeder Abonnent hat normalerweise seine eigene Queue, sodass ein Logging-Dienst, ein Metrik-Dienst und ein Audit-Dienst dasselbe Ereignis erhalten können, ohne darum zu konkurrieren.

Anwendungsfälle

• Echtzeit-Benachrichtigungen: Senden Sie ein Wartungsmodus-Ereignis an alle App-Instanzen.
• Logging-Verteilung: Senden Sie dasselbe Log-Ereignis an einen Archivdienst und einen Alarmierungsdienst.
• Cache-Invalidierung: Teilen Sie allen Dienstinstanzen mit, einen lokalen Cache nach einer Datenbankänderung zu leeren.

Implementierungstipp

Erstellen Sie für kurzlebige Abonnenten eine exklusive, automatisch löschbare Queue und binden Sie sie an den Fanout-Exchange. Verwenden Sie für dauerhafte Abonnenten eine dauerhafte Queue, damit der Abonnent zurückkommen und Nachrichten lesen kann, die während seiner Abwesenheit eingetroffen sind.

Direct- und Topic-Routing: Ereignisse selektiv senden

Während der Fanout-Exchange blindes Senden ermöglicht, bietet AMQP Exchanges für selektives Veröffentlichen, die das Pub/Sub-Modell erweitern.

Direct-Exchange

Nachrichten werden basierend auf einer exakten Übereinstimmung zwischen dem Routing-Key der Nachricht und dem Binding-Key der Queue an Queues weitergeleitet. Dies ist nützlich, wenn Sie verschiedene Arten von Consumern gezielt ansprechen müssen.

Beispielsweise kann Ihr Log-Publisher Nachrichten mit Routing-Keys wie error, warning und info senden. Eine Alarmierungs-Queue kann nur an error binden, während eine Archiv-Queue an alle drei Schweregrade binden kann.

Topic-Exchange

Dies ist der flexibelste Exchange-Typ, der Platzhalter in Binding- und Routing-Keys erlaubt. Der Routing-Key wird als Liste mit Trennzeichen behandelt (z. B. mit Punkten .).

• * entspricht genau einem Wort.
• # entspricht null oder mehr Wörtern.

Ein Routing-Key wie orders.us.created kann an eine Betrugs-Queue gebunden an orders.*.created und eine US-Operations-Queue gebunden an #.us.# gehen. Verwenden Sie Topic-Exchanges, wenn Ihre Routing-Regeln echte Geschäftskategorien sind, nicht nur ein einzelnes festes Feld.

Request/Reply: Nach einer spezifischen Antwort fragen

Das Request/Reply-Muster ermöglicht es einer Client-Anwendung, eine Anfragenachricht zu senden und synchron auf eine Antwort von einem Worker (Server) zu warten. Obwohl Messaging inhärent asynchron ist, simuliert dieses Muster traditionelle Remote Procedure Calls (RPC) über den Message Bus.

reply_to und correlation_id verwenden

1. Der Client sendet eine Anfrage an eine Queue wie rpc_queue.
2. Der Client setzt reply_to auf eine Callback-Queue, von der er konsumiert.
3. Der Client setzt eine eindeutige correlation_id.
4. Der Worker verarbeitet die Anfrage und veröffentlicht die Antwort an die reply_to-Queue.
5. Der Client ordnet die Antwort der ursprünglichen Anfrage zu, indem er die correlation_id überprüft.

Anwendungsfälle

• Service-Lookups: Rufen Sie ein Benutzerprofil oder ein Feature-Flag von einem anderen Dienst ab.
• Kurze Entscheidungen: Überprüfen Sie den Bestand, bevor Sie eine Bestellung annehmen.

Vorsichtig verwenden

Request/Reply ist nützlich, bringt aber synchrones Warten in Ihr Messaging-System zurück. Setzen Sie Client-Timeout, behandeln Sie doppelte Antworten und vermeiden Sie RPC für langlaufende Jobs. Veröffentlichen Sie bei langsamer Arbeit einen Befehl, geben Sie eine Job-ID zurück und senden Sie Fortschritts- oder Abschlussereignisse separat.

Konzeptioneller RPC-Ablauf

graph TD
    A[Client (Anforderer)] -->|1. Anfragenachricht (inkl. reply_to, correlation_id)| B(RPC-Anfrage-Queue);
    B --> C[Server (Worker)];
    C -->|2. Anfrage verarbeiten|
D[Ergebnis];
    D -->|3. Antwortnachricht (über reply_to, unter Beibehaltung von correlation_id)| A;

---

Gängige RabbitMQ-Muster auf einen Blick

Muster	Exchange-Typ	Routing-Mechanismus	Hauptmerkmal	Primärer Anwendungsfall
Work Queues	Standard oder Direct	Eine Queue, von Workern geteilt	Eine Nachricht, ein Consumer	Lastverteilung langlaufender Aufgaben
Publish/Subscribe	Fanout	Ignoriert Routing-Key	Eine Nachricht, alle gebundenen Queues	System-Broadcasts, Logging
Direct Routing	Direct	Exakte Routing-Key-Übereinstimmung	Gezielte Ansprache von Consumern	Routing basierend auf Schweregrad oder Typ
Topic Routing	Topic	Platzhalter-Übereinstimmung (*, #)	Flexibles, komplexes Routing	Microservice-Kommunikation, Ereignisströme
Request/Reply (RPC)	Direct (für Antwort)	Verwendet reply_to & correlation_id	Simuliert synchrone API-Aufrufe	Sofortige Service-Lookups, kleine Transaktionen

Fazit

Beginnen Sie mit der Form der Kommunikation. Verwenden Sie Work Queues, wenn genau ein Worker einen Job erledigen soll, Pub/Sub, wenn jeder Abonnent ein Ereignis sehen soll, Direct- oder Topic-Routing, wenn nur einige Abonnenten es sehen sollen, und Request/Reply nur, wenn der Aufrufer wirklich eine sofortige Antwort benötigt.