RabbitMQ: Schneller Nachrichtenversand
IONOS Redaktion5 mins
In der IT müssen ständig Nachrichten von einem Dienst zum anderen geleitet werden. Das muss auf eine kontrollierte Weise geschehen, sonst blockieren sich Nachrichten gegenseitig, es entsteht ein Stau und Prozesse können nicht optimal ablaufen. Damit Anwendungen problemlos miteinander kommunizieren, ist es sinnvoll, einen Mittelsmann einzuschalten – einen Dienst, der die Verteilung der Nachrichten übernimmt. Diesen nennt man Messaging Broker. Einen der bekanntesten stellen wir hier vor: RabbitMQ.
- Inklusive Wildcard-SSL-Zertifikat
- Inklusive Domain Lock
- Inklusive 2 GB E-Mail-Postfach
Was ist RabbitMQ?
RabbitMQ basiert auf der Idee des Advanced Message Queuing Protocols (AMQP). Der große Vorteil von AMQP: Sender und Empfänger müssen nicht die gleiche Programmiersprache verstehen. Inzwischen hat sich der Messaging Broker etwas von AMQP gelöst und geht dank Plug-ins auch mit anderen Nachrichtenprotokollen wie STOMP oder MQTT um – die Idee bleibt aber die gleiche: Zwischen dem Produzenten und dem Konsumenten einer Nachricht liegt eine Warteschlange. In dieser werden die Messages zwischengelagert.
Der Begriff „Nachricht“ wird in diesem Kontext sehr offen verwendet. Nachrichten können Anweisungen an andere Programme oder tatsächliche Textnachrichten sein. Jegliche Form der Informationsvermittlung kann über RabbitMQ oder andere Messaging Broker stattfinden.
Der Vorteil von RabbitMQ liegt darin, dass der Produzent der Nachricht den Versand nicht selbst übernehmen muss. Der Messaging Broker nimmt die Nachricht ab und gibt dem Produzenten so die Möglichkeit, eine neue Aufgabe zu beginnen. Der Sender muss nicht warten, bis der Empfänger die Nachricht empfangen hat. Die Nachricht sitzt bei diesem Verfahren in der Warteschlange und kann dann vom Konsumenten abgeholt werden. Der Sender ist zu diesem Zeitpunkt schon mit einer neuen Aufgabe beschäftigt. Es handelt sich also um ein asynchrones Verfahren: Sender und Empfänger müssen nicht im gleichen Rhythmus agieren.
Ablauf mit RabbitMQ
Bei der Nachrichtenübermittlung gibt es vier Stationen:
- Producer: erzeugt Nachrichten
- Exchange: leitet Nachrichten weiter
- Queue: lagert Nachrichten
- Consumer: verarbeitet die Nachricht
Der Producer veröffentlicht eine Nachricht, sendet diese aber nicht direkt an den Consumer, sondern übergibt sie an die Exchange. Diese Position ist dafür verantwortlich, die Nachrichten auf verschiedene Warteschlangen zu verteilen. Aus denen bedienen sich Consumer mit Nachrichten. Sowohl die Exchange als auch die Queues sind Teil von RabbitMQ und werden von der Software verwaltet. Damit Nachrichten den richtigen Adressaten erreichen, verwendet man Routing Keys. Der Sender gibt der Nachricht einen Routing Key mit, der wie eine Adresse funktioniert. Die Exchange erkennt anhand des Schlüssels, wie die Nachricht geroutet werden muss.
Zwischen Exchange und Queue besteht ein sogenanntes Binding. Über dieses ist jede einzelne Warteschlange mit dem Exchange verbunden. Das Binding definiert zudem, nach welchen Kriterien eine Nachricht weitergeleitet werden soll. Es gibt vier verschiedene Grundarten, wie Nachrichten verteilt werden können.
Direct Exchange
Eine Direct Exchange ist eine direkte Verbindung zwischen Sender und Empfänger. Der Producer stattet die Nachricht mit einem Routing Key aus, der einem entsprechenden Binding Key der Queue entspricht. Das bedeutet, dass auch nur eine Queue in Frage kommt, an der wiederum in der Regel nur ein Consumer hängt.
Topic Exchange
Dieser Exchange-Typ erweitert das Konzept der Direct Exchange. Statt nur eines Kriteriums (Routing Key = Binding Key) können mehrere Queues angesprochen werden. Dies funktioniert über Platzhalter. So können bestimmte Queues bzw. Binding Keys akzeptiert werden, andere bleiben aber ausgeschlossen.
Fanout Exchange
Die Fanout Exchange ist ein Broadcast. Man verteilt dabei eine Nachricht an alle verfügbaren Queues. Es findet keine Sortierung statt. Ein Routing Key wird ignoriert.
Header Exchange
Auch bei Header Exchanges ignoriert das System einen Routing Key. Stattdessen spielt der Header der Nachricht eine wichtige Rolle. In diesem findet die Exchange die Attribute, um die korrekten Queues anzusteuern. Insofern funktioniert eine Header Exchange analog zu Topic Exchanges, da auch in diesem Fall mehrere Queues, aber nicht alle angesprochen werden können.
Consumer, also die empfangende Software, registrieren sich auf bestimmte Queues und beziehen von diesen die Nachrichten. Deshalb ist auch pro Queue nur ein Consumer vorgesehen. Sollten mehrere Consumer Nachrichten aus einer Warteschlange ziehen, kann die korrekte Verteilung nicht garantiert werden. Optional entscheidet man für jede Nachricht, ob der Empfänger den Erhalt quittieren muss oder ob dies nicht notwendig ist.
RabbitMQ im Einsatz
RabbitMQ ist ein Open-Source-Server, in der Programmiersprache Erlang geschrieben und kann für Linux, BSD, Unix, Windows und macOS von der offiziellen Website heruntergeladen werden. Zusätzlich sind Plug-ins empfehlenswert, die die Arbeit mit dem Messaging Broker erleichtern und den Funktionsumfang erweitern. An erster Stelle dürfte hier das Management-Plug-in stehen, das Teil der Standardinstallation ist, aber aktiviert werden muss. Damit können Nutzer RabbitMQ über ein GUI verwalten, haben den Überblick über Nachrichten in Warteschleifen und können Statistiken einsehen.
Wichtig kann zudem das Plug-in Shovel sein: Hiermit ist es möglich, zwei Broker-Instanzen miteinander zu verbinden. Dies ist sinnvoll, um beispielsweise die Last besser zu verteilen. Außerdem verschiebt man so sensible oder sehr umfangreiche Datenmengen, etwa aus Sicherheitsgründen, in ein komplett anderes Netzwerk.
Die Kommunikation funktioniert über TCP, weshalb RabbitMQ Ports benötigt. Diese dürfen nicht geschlossen oder durch andere Anwendungen blockiert werden. Eine Liste aller verwendeten Ports findet man in der Dokumentation von RabbitMQ.
RabbitMQ überzeugt vor allem durch seine schlanke Konstruktion. Der Messaging Broker lässt sich schnell aufbauen und ist in vielen Situationen nützlich. In größeren Szenarien greifen Entwickler und Admins allerdings lieber zu Apache Kafka.
