MQTT vs AMQP: Unterschiede, Einsatz und Performance

MQTT vs AMQP wird immer dann zum Thema, wenn ein Team, das vernetzte Geräte entwickelt, zugleich Backend-Dienste auf einem Message Broker wie RabbitMQ betreibt. Beide Protokolle arbeiten mit Brokern, beide laufen über TCP und beide bieten Zustellbestätigungen, doch sie wurden für sehr unterschiedliche Aufgaben entworfen. Dieser Leitfaden vergleicht Broker-Modelle, Routing, Garantien und Client-Footprint und endet mit einer praktischen Regel, wann welches Protokoll in Ihre Architektur gehört.

Woher die beiden Protokolle stammen

MQTT wurde für Telemetrie von entfernten Anlagen über unzuverlässige Verbindungen mit geringer Bandbreite entworfen. Seine Prioritäten sind ein winziger Client, ein kleines Paketformat und ein einfaches Modell: Clients publizieren auf hierarchische Topics und abonnieren mit Wildcards. Es ist ein OASIS-Standard, und die Versionen 3.1.1 und 5.0 sind weit verbreitet.

AMQP (Advanced Message Queuing Protocol) stammt aus der Finanzbranche, wo zuverlässiges, interoperables Messaging zwischen Geschäftssystemen im Vordergrund stand. Es hat zwei recht unterschiedliche Linien. AMQP 0-9-1 ist das Modell, das die meisten Entwickler von RabbitMQ kennen, mit Exchanges, Bindings und Queues. AMQP 1.0 ist der OASIS- und ISO-Standard, ein allgemeineres Peer-to-Peer-Übertragungsprotokoll, das von Diensten wie Azure Service Bus genutzt und von Brokern wie Apache ActiveMQ Artemis unterstützt wird. Wenn jemand „AMQP“ sagt, lohnt es sich nachzufragen, welches gemeint ist.

MQTT vs. AMQP im Überblick

Aspekt	MQTT	AMQP 0-9-1 (RabbitMQ-Stil)	AMQP 1.0
Kernmodell	Topics mit Publish/Subscribe	Exchanges routen über Bindings zu Queues	Links zwischen Knoten; Broker-Semantik durch Implementierung definiert
Routing	Hierarchische Topics, Wildcards `+` und `#`	Direct-, Topic-, Fanout-, Headers-Exchanges	Adressen und Filter, broker-spezifisch
Queues	Keine expliziten Queues (Session-Queues pro Client)	Explizite, benannte, dauerhafte Queues	Vom Broker definierte Knoten
Zustellgarantien	QoS 0, 1, 2	Acks, Publisher Confirms, Transaktionen	Settlement-Modi, höchstens einmal und mindestens einmal
Arbeitsverteilung	Shared Subscriptions (MQTT 5)	Konkurrierende Konsumenten an einer Queue	Konkurrierende Empfänger an einem Knoten
Flusskontrolle	Receive Maximum (MQTT 5)	Prefetch (basic.qos)	Kreditbasierte Link-Flusskontrolle
Header-Größe	Sehr klein, mindestens 2 Byte fester Header	Größere Frames und Properties	Größere, reich typisierte Kodierung
Client-Footprint	Passt auf Mikrocontroller	Komfortabel auf Servern und Gateways	Komfortabel auf Servern und Gateways
Typisches Einsatzfeld	Geräte, Gateways, Browser, mobile Apps	Backend-Microservices, Task-Queues	Enterprise-Integration, Cloud-Messaging-Dienste

Broker-Modell und Routing

Ein MQTT-Broker routet ausschließlich nach Topic. Ein Publisher sendet an plant1/line2/press4/temperature, und jeder Client, dessen Subscription-Filter passt, erhält eine Kopie. Es gibt keine separate Routing-Konfiguration; die Topic-Hierarchie ist die Routing-Tabelle. Das macht MQTT leicht einführbar und leicht nachvollziehbar, besonders in einem Unified Namespace (UNS): Dort wird die ISA-95-Ausrüstungshierarchie (Enterprise → Site → Area → Line → Cell) zur Topic-Struktur auf dem Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und jedes System im Werk, vom MES bis zum Historian, findet Daten an einer vorhersagbaren Adresse. Ein vergleichbares, gemeinsam genutztes Adressmodell für Geräte- und Maschinendaten gibt es in AMQP nicht; dort ist Routing eine Frage der Broker-Konfiguration. Wie ein UNS aufgebaut wird, zeigt der Leitfaden zu Sparkplug B und Unified Namespace. Der Artikel zum MQTT-Publish/Subscribe-Modell erklärt die Entkopplung ausführlicher.

AMQP 0-9-1 trennt, wohin Nachrichten gesendet werden (ein Exchange), davon, wo sie gespeichert werden (Queues). Bindings verbinden beides mit Regeln. Ein Topic-Exchange verhält sich ein wenig wie MQTT-Wildcards, ein Fanout-Exchange kopiert an jede gebundene Queue, und ein Direct-Exchange routet nach einem exakten Schlüssel. Diese Flexibilität ist mächtig für Backend-Workflows, etwa um ein Bestellereignis an Queues für Abrechnung, Versand und Analyse zu verteilen, jede mit eigener Aufbewahrung und eigenen Konsumenten. Der Preis sind mehr Konzepte, die man lernen, und mehr Konfiguration, die man verwalten muss.

Zustellgarantien

MQTT bietet drei QoS-Stufen: höchstens einmal (QoS 0), mindestens einmal (QoS 1) und genau einmal zwischen Client und Broker (QoS 2). Persistente Sessions erlauben dem Broker, QoS-1- und QoS-2-Nachrichten für einen vorübergehend offline befindlichen Subscriber aufzubewahren. Zur Auffrischung lesen Sie MQTT-QoS-Stufen erklärt.

AMQP bietet Konsumentenbestätigungen, negative Bestätigungen mit Requeue, Publisher Confirms und in 0-9-1 Transaktionen. Nachrichten liegen in einer dauerhaften Queue, bis ein Konsument sie explizit bestätigt. Genau das wünschen Sie sich für Aufträge wie „diese Rechnung erzeugen“, die von genau einem Worker verarbeitet und bei Fehlschlag wiederholt werden müssen.

In der Praxis können beide zuverlässig zustellen. Der Unterschied liegt in der Gewichtung: MQTT ist für Ströme von Zuständen und Ereignissen an viele Subscriber optimiert, AMQP für dauerhafte Arbeitsaufträge, die von konkurrierenden Konsumenten abgearbeitet werden.

Performance und Footprint

Keines der beiden Protokolle ist abstrakt betrachtet „schneller“. Der Durchsatz hängt weit mehr von der Broker-Implementierung, den Persistenzeinstellungen, der Nachrichtengröße und dem Bestätigungsmodus ab als vom Leitungsformat.

Deutlich unterscheiden sich die Protokolle beim Footprint. Eine MQTT-Client-Bibliothek passt problemlos auf einen ESP32 oder einen ähnlichen Mikrocontroller, und der Paket-Overhead pro Nachricht ist winzig, was bei Mobilfunk- und Satellitenverbindungen zählt. AMQP-Clients sind schwerer, Frames tragen mehr Metadaten, und der Verbindungsaufbau erfordert mehr Aushandlung. Auf einem Server ist dieser Unterschied irrelevant; auf einem batteriebetriebenen Sensor ist er entscheidend.

MQTT kommt außerdem gut mit sehr vielen überwiegend inaktiven Verbindungen zurecht, was die normale Gestalt einer IoT-Flotte ist. AMQP-Broker sind meist auf weniger, aber geschäftigere Verbindungen von Diensten abgestimmt.

Typische Architekturen

Die häufigste Praxisantwort auf MQTT vs AMQP lautet „beides, auf unterschiedlichen Ebenen“:

Geräte, Gateways (etwa OPC-UA-zu-MQTT-Gateways an der SPS) und Dashboards verbinden sich mit einem MQTT-Broker.
Ein Backend-Dienst abonniert die relevanten MQTT-Topics, zum Beispiel plant1/+/+/telemetry.
Dieser Dienst validiert und reichert die Daten an und publiziert dann Arbeitsaufträge in eine AMQP-Queue zur nachgelagerten Verarbeitung, etwa für Abrechnung, Ticketing oder ERP-Aktualisierungen.

Hier ist eine minimale Bridge in Python, die per MQTT abonniert und mit pika in eine RabbitMQ-Queue publiziert. Sie läuft als eigener Prozess, sodass Sie Batching, Filterung und Fehlerbehandlung selbst steuern.

import json
import uuid

import paho.mqtt.client as mqtt
import pika

PREFIX = "connectmq/demo/replace-me"

amqp = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
channel = amqp.channel()
channel.queue_declare(queue="telemetry", durable=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("MQTT connected:", reason_code)
    client.subscribe(f"{PREFIX}/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    try:
        body = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("skipping invalid payload on", msg.topic)
        return
    body["topic"] = msg.topic
    channel.basic_publish(
        exchange="",
        routing_key="telemetry",
        body=json.dumps(body),
        properties=pika.BasicProperties(delivery_mode=2),  # persistent
    )

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"amqp-bridge-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Für die Produktion verbinden Sie sich über TLS auf 8883 mit Ihrem privaten Broker, mit client.tls_set() und client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"), und verwenden die mit diesen Zugangsdaten ausgegebene Client-ID. Da die blockierende Verbindung von pika nicht threadsicher ist, halten Sie alle AMQP-Aufrufe wie gezeigt im Thread der MQTT-Netzwerk-Loop oder übergeben Sie Nachrichten an eine Queue, die ein eigener AMQP-Thread abarbeitet.

Wann Sie MQTT wählen sollten

Clients sind Mikrocontroller, Gateways, mobile Apps oder Browser.
Verbindungen sind unzuverlässig, volumenbasiert abgerechnet oder haben hohe Latenz.
Viele Konsumenten brauchen denselben Strom an Telemetrie oder Zuständen.
Sie brauchen Online-/Offline-Erkennung (Keep Alive und Last Will) und letzte bekannte Werte (Retained Messages).
Sie möchten ein einfaches Modell, das Feldtechniker und Integratoren allein anhand der Topic-Namen verstehen.

Wann Sie AMQP wählen sollten

Nachrichten sind Arbeitseinheiten, die genau ein Konsument verarbeiten und bestätigen muss.
Sie brauchen ausgefeilte Routing-Regeln, Dead-Letter-Queues und Richtlinien pro Queue.
Alle Produzenten und Konsumenten sind Backend-Dienste in einem Rechenzentrum oder in der Cloud.
Sie integrieren Unternehmenssysteme, die bereits AMQP 1.0 sprechen.

Warum ein verwalteter MQTT-Broker oft die einfachere Wahl ist

Auf der geräteseitigen Seite gewinnt meist die betriebliche Einfachheit. Ein verwalteter MQTT-Broker nimmt Ihnen Patches, Zertifikatserneuerung, die Skalierung der Verbindungszahlen und die Mandantenisolation ab, sodass sich Ihr Team auf Topic-Design und Konsumenten konzentrieren kann. ConnectMQ unterstützt MQTT 3.1.1 und 5.0, TLS mit einem Let's-Encrypt-Zertifikat, Shared Subscriptions im kostenpflichtigen Serverless-Plan sowie Kontingente pro Plan mit Flood-Schutz. Eine AMQP-Bridge ist nicht enthalten, Sie betreiben die Bridge also als eigenen Dienst, genau wie oben gezeigt. Um Hosting-Optionen breiter zu vergleichen, lesen Sie den Leitfaden zum Cloud-MQTT-Broker, und zur Auffrischung zu Topics und Sessions das MQTT-Tutorial. Wenn Sie Queues und Broker konzeptionell abwägen, geht MQTT-Broker vs. Message Queue tiefer.

Starten Sie mit ConnectMQ

Bringen Sie Ihre Geräte per MQTT auf ConnectMQ und behalten Sie AMQP für die Backend-Workflows, in denen es am stärksten ist. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, übernehmen Sie die generierten Zugangsdaten und richten Sie Ihre Geräte und Ihren Bridge-Dienst in wenigen Minuten darauf aus.

Häufig gestellte Fragen

Ist MQTT besser als AMQP für das IoT?

Für Geräte meist ja: MQTT-Clients sind kleiner, Pakete leichter, und das Modell kommt gut mit vielen zeitweiligen Verbindungen zurecht. AMQP eignet sich besser für Backend-Work-Queues.

Kann RabbitMQ MQTT sprechen?

RabbitMQ bietet ein MQTT-Plugin, das MQTT-Topics auf sein Exchange-Modell abbildet. Ein dedizierter MQTT-Broker bietet in der Regel eine umfassendere Unterstützung der MQTT-Funktionen und einfacheren Betrieb für große Geräteflotten.

Hat MQTT Queues wie AMQP?

Nicht explizit. Der Broker hält für persistente Sessions eine Session-Queue pro Client, und Shared Subscriptions in MQTT 5 erlauben mehreren Konsumenten, die Nachrichten eines Topics untereinander aufzuteilen, was viele Queue-ähnliche Anwendungsfälle abdeckt.

Kann ich MQTT und AMQP zusammen nutzen?

Ja, und das ist üblich. Geräte publizieren per MQTT, und ein Bridge-Dienst abonniert und leitet ausgewählte Nachrichten zur Backend-Verarbeitung in AMQP-Queues weiter.

MQTT vs. AMQP: Unterschiede, Anwendungsfälle und Performance