MQTT-Broker vs. Message Queue ist eine Unterscheidung, über die viele Teams stolpern, weil beide „Message Broker“ sind, die zwischen Produzenten und Konsumenten sitzen. Der Unterschied liegt in der Zustellsemantik: Ein MQTT-Broker kopiert jede Nachricht sofort an jeden interessierten Subscriber, während eine Message Queue jede Nachricht so lange hält, bis genau ein Konsument die Verantwortung dafür übernimmt. Dieser Leitfaden erklärt beide Modelle, vergleicht sie mit Queues im Stil von RabbitMQ und SQS und zeigt, wann ein Cloud-MQTT-Broker der richtige Baustein ist.
Zwei Zustellmodelle
Topic-basiertes Publish/Subscribe (MQTT). Ein Publisher sendet eine Nachricht an ein Topic wie plant1/line2/press4/temperature. Der Broker prüft alle aktuellen Subscriptions, findet diejenigen, deren Filter passen, und stellt jeder eine Kopie zu. Abonnieren fünf Services, gehen fünf Kopien hinaus. Abonniert niemand, wird die Nachricht verworfen – es sei denn, sie wird als letzter Wert des Topics gespeichert (retained) oder in einer persistenten Session vorgehalten. Die Aufgabe des Brokers ist Routing, nicht Speicherung. Einen tieferen Einblick in das Modell bietet das MQTT-Publish/Subscribe-Modell.
Point-to-Point-Queues (RabbitMQ, SQS und Ähnliche). Ein Produzent sendet eine Nachricht an eine Queue. Dort wartet sie dauerhaft, bis ein Konsument sie empfängt. Hängen mehrere Konsumenten an derselben Queue, geht jede Nachricht nur an einen von ihnen; sie konkurrieren um die Arbeit. Der Konsument bestätigt nach der Verarbeitung, und stürzt er vor der Bestätigung ab, wird die Nachricht für einen anderen Konsumenten wieder sichtbar. Die Aufgabe der Queue ist sicherzustellen, dass jede Arbeitseinheit einmal von irgendjemandem erledigt wird.
Kurz gesagt: MQTT beantwortet „Wer muss davon erfahren?“, eine Queue beantwortet „Wer erledigt diesen Job?“.
MQTT-Broker und Message Queue im Vergleich
| Aspekt | MQTT-Broker | Message Queue (Stil RabbitMQ, SQS) |
|---|---|---|
| Zustellung | Kopie an jeden passenden Subscriber | Jede Nachricht an einen Konsumenten |
| Adressierung | Hierarchische Topics, Wildcards + und # |
Benannte Queues (in RabbitMQ zusätzlich Exchanges und Bindings) |
| Nachricht ohne Konsumenten | Verworfen, außer retained oder für eine persistente Session vorgehalten | Gespeichert bis zum Konsum oder Ablauf |
| Speicherung | Letzter Retained-Wert pro Topic, Session-Queues pro Client | Dauerhafte Queues, oft mit langer Aufbewahrung |
| Bestätigung | QoS 1 und 2 zwischen Client und Broker | Konsumenten-Ack nach Verarbeitung, erneute Zustellung bei Fehlern |
| Arbeitsverteilung | Shared Subscriptions in MQTT 5 | Native Competing Consumers |
| Dead-Letter-Behandlung | Nicht Teil von MQTT | Gängige Funktion (Dead-Letter-Queues und -Exchanges) |
| Reihenfolge | Pro Topic pro Client-Session | Pro Queue, mit Einschränkungen bei erneuter Zustellung |
| Zustellart | Push an verbundene Clients | Push (RabbitMQ) oder Pull/Long Polling (SQS) |
| Client-Ressourcenbedarf | Winzig, läuft auf Mikrocontrollern | SDKs für Serverklasse |
| Präsenz und Zustand | Keep Alive, Last Will, Retained Messages | Nicht zutreffend |
| Typischer Einsatz | Gerätetelemetrie, Befehle, Live-Zustand, Dashboards | Hintergrundjobs, Auftragsverarbeitung, entkoppelte Microservices |
Wo sich die Modelle überschneiden
Die Grenze ist nicht völlig scharf, was zur Verwirrung beiträgt.
MQTT hat zwei Queue-ähnliche Funktionen. Eine persistente Session lässt den Broker QoS-1- und QoS-2-Nachrichten für einen Client vorhalten, solange dieser offline ist; mit MQTT 5 begrenzen Sie das über ein Session Expiry Interval. Shared Subscriptions ($share/group/filter) lassen mehrere Clients einer Gruppe die Nachrichten eines Topics aufteilen, sodass jede Nachricht genau ein Gruppenmitglied erreicht – exakt das Competing-Consumer-Verhalten. Details finden Sie unter MQTT Shared Subscriptions und MQTT Persistent Session.
Queue-Systeme bieten ihrerseits Pub/Sub. Fanout- und Topic-Exchanges in RabbitMQ kopieren eine Nachricht in mehrere Queues, und Cloud-Dienste kombinieren ein Benachrichtigungs-Topic mit mehreren Queues für Fan-out. Jeder Subscriber braucht dabei aber weiterhin eine eigene, vorab deklarierte Queue.
Die eigentliche Frage ist also nicht, welche Funktionen existieren, sondern welches Modell nativ ist. MQTT ist natives Fan-out mit leichtgewichtigen, dynamischen Subscriptions; Queues sind native, dauerhafte Arbeitsverteilung.
Den Unterschied in zwei Minuten sehen
Fan-out können Sie mit den Mosquitto-Clients auf dem kostenlosen öffentlichen MQTT-Broker beobachten. Verwenden Sie ein eindeutiges Präfix, damit Sie keine Nachrichten anderer sehen.
PREFIX="connectmq/demo/$(openssl rand -hex 4)"
# Fan-out: in zwei Terminals ausführen, jeweils mit eigener Client ID
mosquitto_sub -h broker.connectmq.com -V mqttv5 -i fan-$RANDOM \
-t "$PREFIX/orders/new" -v
# Fünf Nachrichten publizieren, langsam genug für das Rate-Limit pro Client
for i in 1 2 3 4 5; do
mosquitto_pub -h broker.connectmq.com -V mqttv5 -i pub-$RANDOM -q 1 \
-t "$PREFIX/orders/new" -m "order $i"
sleep 0.5
done
Beide Subscriber geben alle fünf Bestellungen aus. Für das Queue-ähnliche Verhalten brauchen Sie einen Broker-Plan mit Shared Subscriptions, etwa einen kostenpflichtigen Serverless-Broker bei ConnectMQ. Starten Sie zwei Worker mit Ihren eigenen Zugangsdaten (jeder Worker braucht eine eigene Client ID und passende Zugangsdaten aus dem Portal) und publizieren Sie erneut:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -V mqttv5 \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-t '$share/workers/orders/new' -v
Die beiden Worker mit Shared Subscription teilen sich die Nachrichten, sodass jeder nur einen Teil ausgibt. Stoppen Sie dann beide Worker, publizieren Sie erneut und starten Sie sie wieder: Die Bestellungen, die während ihrer Abwesenheit publiziert wurden, sind weg. Nur eine persistente Session hätte sie vorgehalten, und auch dann nur für diesen einen Client und nur innerhalb des Session Expiry Interval. Genau diese Lücke füllt eine echte Queue.
Wann Sie einen MQTT-Broker einsetzen
Ein MQTT-Broker ist der richtige Baustein, wenn:
- die Produzenten Geräte sind. Sensoren, SPS-Gateways, Fahrzeuge, mobile Apps und Browser brauchen kleine Clients und eine tolerante Verbindungsbehandlung.
- viele Konsumenten dieselben Daten brauchen. Ein Messwert geht gleichzeitig an ein Dashboard, einen Historian-Writer und einen Alarmierungsdienst, und ein vierter Konsument erfordert keine Änderung beim Produzenten.
- der aktuelle Zustand wichtiger ist als die Historie. Retained Messages geben jedem neuen Subscriber sofort den letzten bekannten Wert. In der Fertigung ist genau das die Idee des Unified Namespace (UNS): Der Broker hält den aktuellen Zustand des Unternehmens in einer Topic-Struktur nach der ISA-95-Hierarchie (Enterprise, Site, Area, Line, Cell), etwa
acme/werk-stuttgart/presswerk/linie-2/presse-4/temperatur, und MES, SCADA und Historian abonnieren, was sie brauchen. Mehr dazu unter Sparkplug B und Unified Namespace. - Sie Präsenz brauchen. Keep Alive und Last Will melden Ihnen, wenn ein Gerät offline geht.
- Sie Befehle pushen müssen – an bestimmte Geräte hinter NAT oder in Mobilfunkverbindungen.
Wenn Brokers für Sie generell neu sind, erklärt Was ein MQTT-Broker macht die Grundlagen, und das MQTT-Tutorial führt durch Topics, QoS und Sessions.
Wann Sie eine Message Queue einsetzen
Eine Queue ist der richtige Baustein, wenn:
- jede Nachricht ein Job ist, der von genau einem Worker genau einmal verarbeitet werden muss, etwa das Erstellen einer Rechnung oder das Skalieren eines Bildes.
- Arbeit lange Ausfälle der Konsumenten überstehen muss, über Stunden oder Tage.
- Sie Wiederholungen und Dead-Letter-Behandlung für Nachrichten brauchen, die wiederholt fehlschlagen.
- Produzenten und Konsumenten Backend-Services in zuverlässigen Netzwerken sind.
Beide zusammen nutzen
Die meisten IoT-Plattformen landen bei beidem. Geräte publizieren an einen MQTT-Broker. Ein Konsumenten-Service abonniert – typischerweise über eine Shared Subscription, damit er horizontal skalieren kann –, filtert den Strom auf die Ereignisse herunter, die verarbeitet werden müssen, etwa „Alarm ausgelöst“ oder „Charge abgeschlossen“, und stellt diese als Jobs in RabbitMQ oder SQS ein, etwa für die Rückmeldung einer abgeschlossenen Charge an MES oder ERP. Live-Telemetrie fließt weiter über MQTT an Dashboards, während dauerhafte Geschäftsabläufe über die Queue laufen. Der Artikel MQTT vs. AMQP enthält eine funktionierende Bridge in Python.
Bei der MQTT-Seite entscheiden Sie, ob Sie den Broker selbst betreiben oder einen Cloud-MQTT-Broker nutzen. ConnectMQ ist ein verwalteter MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS, Retained Messages, Session Expiry und im kostenpflichtigen Serverless-Plan Shared Subscriptions, dazu Mandantenisolation und Kontingente je Plan. Es ist ein Broker, keine Queue: Eine integrierte Queue-Bridge gibt es nicht, die Übergabe erledigt also Ihr Konsumenten-Service – das hält die Grenze explizit.
Starten Sie mit ConnectMQ
Setzen Sie einen MQTT-Broker für das ein, was er am besten kann – Fan-out, Live-Zustand und Gerätekonnektivität –, und kombinieren Sie ihn mit einer Queue, wenn Sie dauerhafte Jobs brauchen. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, und probieren Sie die obige Demo zu Fan-out und Shared Subscriptions auf Ihrem eigenen privaten Broker aus.
Häufig gestellte Fragen
Ist ein MQTT-Broker eine Message Queue?
Nicht im klassischen Sinn. Ein MQTT-Broker routet Kopien jeder Nachricht an alle aktuellen Subscriber, während eine Queue jede Nachricht speichert, bis ein Konsument sie verarbeitet. MQTT hat Queue-ähnliche Funktionen, ist im Kern aber Pub/Sub.
Kann MQTT garantieren, dass eine Nachricht nur einmal verarbeitet wird?
QoS 2 garantiert Exactly-once-Zustellung zwischen einem Client und dem Broker, nicht die Ende-zu-Ende-Verarbeitung. Für die einmalige Verarbeitung von Jobs setzen Sie idempotente Konsumenten ein oder übergeben die Arbeit an eine Message Queue.
Was passiert mit MQTT-Nachrichten, wenn niemand abonniert hat?
Sie werden verworfen – es sei denn, die Nachricht ist retained, dann behält der Broker sie als letzten Wert des Topics, oder es existiert eine persistente Session für einen Offline-Subscriber.
Sollte ich für IoT-Geräte RabbitMQ oder einen MQTT-Broker verwenden?
Verbinden Sie Geräte mit einem MQTT-Broker, der für viele leichtgewichtige, zeitweise verbundene Clients gebaut ist. Setzen Sie RabbitMQ dahinter für Backend-Work-Queues ein, falls Ihre Abläufe sie brauchen.
