Wer Message-Systeme für das industrielle IoT vergleicht, stößt schnell auf eine irreführende Gegenüberstellung. MQTT vs RabbitMQ klingt nach zwei gleichartigen Konkurrenten. Doch die beiden gehören in unterschiedliche Kategorien. MQTT ist ein leichtgewichtiges Publish/Subscribe-Protokoll. RabbitMQ ist ein Message-Broker, der das Protokoll AMQP nativ spricht. Wer ein Protokoll direkt mit einem Broker vergleicht, vergleicht also Äpfel mit Birnen.
Diese Kategorienverwirrung ist der häufigste Fehler in der Diskussion. Sie lässt sich aber sauber auflösen. Dieser Artikel ordnet den Vergleich MQTT vs RabbitMQ richtig ein. Er stellt das Routing-Modell, die Zustellgarantien, den Footprint und die Design-Absicht gegenüber. Und er zeigt: In vielen Industriearchitekturen ist es kein Entweder-oder. MQTT und RabbitMQ übernehmen getrennte Rollen und arbeiten zusammen.
MQTT vs RabbitMQ: Protokoll gegen Broker
Der erste Schritt ist eine klare Trennung der Begriffe. MQTT (Message Queuing Telemetry Transport) ist ein Protokoll. Es definiert, wie Nachrichten zwischen einem Sender und einem Broker fließen. MQTT sagt nichts darüber aus, welche Broker-Software zum Einsatz kommt. Bekannte MQTT-Broker sind etwa Mosquitto, EMQX oder HiveMQ.
RabbitMQ dagegen ist konkrete Broker-Software. Sie spricht von Haus aus AMQP 0-9-1 (Advanced Message Queuing Protocol). AMQP ist damit das native Protokoll von RabbitMQ. MQTT unterstützt RabbitMQ nur über ein zusätzliches Plugin. Der saubere Vergleich lautet deshalb nicht MQTT gegen RabbitMQ, sondern MQTT gegen AMQP. Also Protokoll gegen Protokoll.
Diese Unterscheidung ist mehr als Wortklauberei. Sie bestimmt, worüber man überhaupt spricht. Ein Protokoll legt die Regeln der Kommunikation fest. Ein Broker ist das Produkt, das diese Regeln umsetzt. Der Rest dieses Artikels vergleicht deshalb die beiden Protokolle MQTT und AMQP. RabbitMQ steht dabei als der verbreitetste AMQP-Broker stellvertretend für die AMQP-Welt.
Woher kommt die Verwirrung? Genau daher, dass RabbitMQ auch MQTT sprechen kann. Über das MQTT-Plugin nimmt der Broker MQTT-Clients an. Das lässt die beiden auf den ersten Blick wie Alternativen wirken. Technisch bleibt MQTT aber ein Protokoll und RabbitMQ eine Software. Wer das im Kopf behält, stellt von Anfang an die richtigen Fragen.
Das Routing-Modell im Vergleich
Der deutlichste technische Unterschied im Duell MQTT vs RabbitMQ liegt im Routing. Beide Protokolle bringen eine Nachricht vom Sender zum Empfänger. Doch der Weg dorthin ist grundverschieden. AMQP routet explizit über konfigurierte Bausteine. MQTT routet implizit über einen Topic-Baum. Die folgende Grafik stellt beide Modelle nebeneinander.
AMQP: Exchanges, Bindings und Queues
AMQP kennt drei zentrale Bausteine. Ein Producer sendet eine Nachricht nicht direkt an eine Queue. Er sendet sie an ein Exchange. Das Exchange verteilt die Nachricht anhand von Regeln, den Bindings, an eine oder mehrere Queues. Aus den Queues lesen dann die Consumer.
Das Verhalten hängt vom Exchange-Typ ab. Ein direct-Exchange leitet nach exaktem Routing-Key weiter. Muster mit Platzhaltern erlaubt dagegen der topic-Exchange. Ein fanout-Exchange kopiert die Nachricht an alle gebundenen Queues, während der headers-Exchange nach Nachrichten-Attributen routet. Diese Struktur ist mächtig. Sie erlaubt komplexe Verteillogik direkt im Broker, ist aber auch aufwändiger zu planen und zu betreiben.
MQTT: Topics und Wildcards
MQTT geht schlanker vor. Es gibt keine Exchanges und keine Bindings. Ein Publisher sendet auf ein Topic, etwa plant/line1/temp. Der Broker verwaltet einen hierarchischen Topic-Baum. Subscriber abonnieren Topics direkt oder über Wildcards.
MQTT kennt zwei Wildcards. Das + steht für genau eine Ebene. Das # steht für alle darunterliegenden Ebenen. Ein Subscriber auf plant/line1/# empfängt alles zur Linie 1. Ein Subscriber auf plant/+/temp empfängt alle Temperaturen über alle Linien. Das Routing ergibt sich allein aus der Topic-Struktur. Es braucht keine vorab konfigurierte Verteillogik. Genau das macht MQTT leicht und flexibel.
Der Kontrast lässt sich auf einen Satz bringen. Bei AMQP definiert der Betreiber die Verteilung im Broker. Er legt Exchanges an, verdrahtet Bindings und bindet Queues. Bei MQTT ergibt sich die Verteilung aus der Benennung der Topics. Wer die Frage RabbitMQ oder MQTT beantwortet, wählt damit auch zwischen expliziter und impliziter Routing-Kontrolle. Explizites Routing bietet mehr Steuerung. Implizites Routing bietet weniger Konfigurationsaufwand.
Zuverlässigkeit, QoS und Nachrichten-Semantik
Auch bei den Zustellgarantien trennen sich die Wege. MQTT definiert drei QoS-Stufen (Quality of Service). Stufe 0 (QoS 0) liefert höchstens einmal aus. Mit QoS 1 liefert der Broker mindestens einmal aus. QoS 2 garantiert über einen vierstufigen Handshake genau eine Zustellung. Der Entwickler wählt die Stufe passend zum Anwendungsfall. Details erklärt unser Artikel zu MQTT Quality of Service (QoS).
AMQP verfolgt einen anderen Ansatz. Es kennt zwei grundlegende Zustellstufen für Nachrichten. Darüber hinaus bietet es Publisher Confirms, Consumer-Acknowledgements und Transaktionen. Damit lassen sich transaktionale Abläufe im Broker absichern. Eine Nachricht gilt erst als verarbeitet, wenn der Consumer sie ausdrücklich bestätigt. Dieser Fokus auf transaktionale Sicherheit ist eine klare Stärke von RabbitMQ.
Auch die Zustands-Features unterscheiden sich. MQTT bringt persistente Sessions, das Last Will and Testament und Retained Messages mit. Das Last Will meldet einen unerwarteten Verbindungsabbruch. Eine Retained Message liefert neuen Subscribern sofort den letzten bekannten Wert. RabbitMQ setzt stattdessen auf langlebige Queues, Message-TTL, Dead-Letter-Queues und Prioritäten. Beide Ansätze lösen ähnliche Probleme, aber mit unterschiedlicher Philosophie.
Footprint und Design-Absicht
Am Ende führt der Vergleich MQTT vs AMQP auf die ursprüngliche Design-Absicht zurück. Die Protokolle wurden für verschiedene Welten entworfen. Das erklärt die meisten Unterschiede in Routing, QoS und Zustand.
MQTT entstand für beschränkte Umgebungen. Der feste Header beginnt bei nur 2 Byte. Das Protokoll ist ideal für Sensoren, Edge-Geräte und Mobilfunknetze. Seine Stärke ist die Verteilung vieler kleiner Telemetriedaten an viele Empfänger. Genau diese hohe Fan-out-Fähigkeit macht MQTT zum Rückgrat des Unified Namespace (UNS).
AMQP und RabbitMQ zielen auf das Enterprise-Messaging. Sie wurden für komplexes Routing, Task-Queues und geschäftskritische Workflows entworfen. Der Footprint ist schwerer, das Feature-Set breiter. Eine Bank verteilt damit Transaktionen. Ein Backend verteilt damit Hintergrundjobs an Worker. Die folgende Matrix fasst die Unterschiede kompakt zusammen.
| Kriterium | MQTT | RabbitMQ / AMQP |
|---|---|---|
| Kategorie | Protokoll | Broker (spricht AMQP) |
| Routing | Topics und Wildcards (+, #) | Exchanges, Bindings, Queues |
| QoS / Zustellung | 3 Stufen (0, 1, 2) | 2 Stufen plus Transaktionen |
| Footprint | leichtgewichtig (ab 2 Byte) | schwerer, feature-reich |
| Zustands-Features | Retained, Last Will, Sessions | Queues, TTL, Dead-Letter |
| Design-Absicht | IoT, Edge, hoher Fan-out | Enterprise, Routing, transaktional |
| Typischer Einsatz | Telemetrie im UNS | Task-Queues, Workflows, ERP |
Ein breiterer Überblick über weitere Broker hilft bei der Einordnung. Wie sich MQTT, Kafka, AMQP und NATS insgesamt unterscheiden, zeigt unser Vergleich der Message Broker. Für die reine Protokollfrage im UNS lohnt zudem der Blick auf NATS vs. MQTT und auf Kafka im industriellen IoT gegenüber MQTT.
MQTT und RabbitMQ kombinieren: nicht entweder-oder
Die spannendste Erkenntnis im Vergleich MQTT vs RabbitMQ ist die Kombination. In vielen Industriearchitekturen konkurrieren die beiden nicht. Sie ergänzen sich. Jedes Protokoll spielt seine Stärke in der Zone aus, für die es gebaut wurde.
Am Edge und im UNS dominiert MQTT. Sensoren, PLCs und Maschinen publizieren ihre Daten leichtgewichtig an einen zentralen MQTT-Broker. Dieser Broker bildet das Telemetrie-Rückgrat der Fertigung. Mehr dazu erklärt unser Artikel zu MQTT im Unified Namespace.
Im Enterprise-Backend übernimmt RabbitMQ. Dort laufen komplexe Workflows, Task-Queues und transaktionale Prozesse. Genau dafür ist AMQP gebaut. Zwischen beiden Welten sitzt eine Bridge. Sie leitet ausgewählte Daten aus dem UNS gezielt in RabbitMQ weiter. So landet nur das im Enterprise-System, was dort gebraucht wird. Die folgende Grafik zeigt diese Rollenteilung.
Dieses Muster ist bewährt. MQTT sammelt und verteilt Maschinendaten nah am Prozess. RabbitMQ verarbeitet die daraus abgeleiteten Geschäftsvorgänge im IT-Backend. Die Bridge entkoppelt beide Zonen sauber. Weder muss die OT die Enterprise-Last tragen, noch muss die IT jedes Telemetrie-Paket sehen. Genau so entsteht eine geschichtete, skalierbare Architektur.
Ein Beispiel macht das greifbar. Eine Maschine meldet über MQTT laufend ihren Zustand an den UNS. Dashboards und Historian lesen diese Daten direkt mit. Wechselt die Maschine in einen Fehlerzustand, erkennt eine Bridge dieses Ereignis. Sie erzeugt daraus einen Auftrag und legt ihn in eine RabbitMQ-Queue. Ein Worker im Backend holt den Auftrag ab und startet den Wartungsprozess. MQTT liefert das Ereignis, RabbitMQ steuert den Workflow. Beide Protokolle spielen ihre jeweilige Stärke aus.
Fazit: Wann MQTT, wann RabbitMQ
Der Vergleich MQTT vs RabbitMQ führt nicht zu einem Sieger. Er führt zu einer klaren Zuordnung. MQTT ist ein Protokoll für leichtgewichtige Telemetrie mit hohem Fan-out. RabbitMQ ist ein Broker für komplexes Enterprise-Routing und transaktionale Workflows. Beide lösen unterschiedliche Probleme. In einer geschichteten Architektur ergänzen sie sich sogar. Drei zentrale Erkenntnisse:
- Kategorien trennen: MQTT ist ein Protokoll, RabbitMQ ein Broker. Der saubere Vergleich lautet MQTT vs AMQP.
- Routing entscheidet: MQTT routet implizit über Topics und Wildcards, AMQP explizit über Exchanges, Bindings und Queues.
- Kein Entweder-oder: MQTT am Edge und im UNS, RabbitMQ im Enterprise-Backend, verbunden über eine Bridge.
Häufig gestellte Fragen (FAQ)
Ist RabbitMQ ein MQTT-Broker? RabbitMQ ist in erster Linie ein AMQP-Broker. MQTT unterstützt es nur über ein zusätzliches Plugin. Wer MQTT als Kernprotokoll braucht, greift meist zu spezialisierten Brokern wie Mosquitto, EMQX oder HiveMQ. Diese sind von Grund auf für MQTT gebaut.
Ist MQTT vs RabbitMQ überhaupt ein fairer Vergleich? Nicht direkt. MQTT ist ein Protokoll, RabbitMQ ein Broker. Der faire Vergleich lautet MQTT gegen AMQP, also Protokoll gegen Protokoll. RabbitMQ dient dabei als der bekannteste Vertreter der AMQP-Welt.
Wann sollte ich MQTT statt RabbitMQ wählen? MQTT passt für leichtgewichtige Telemetrie mit vielen Sensoren und Empfängern. Es ist die richtige Wahl am Edge und im Unified Namespace. RabbitMQ passt für komplexes Routing, Task-Queues und transaktionale Workflows im IT-Backend.
Kann ich MQTT und RabbitMQ zusammen einsetzen? Ja, und oft ist genau das die beste Lösung. MQTT sammelt die Maschinendaten am Edge. RabbitMQ verarbeitet die Geschäftsvorgänge im Backend. Eine Bridge verbindet beide Zonen und leitet nur relevante Daten weiter.
