MQTT vs. AMQP — Geräte-Protokoll oder Backend-Messaging?

MQTT: gut geeignet für

• ✓Viele Geräte, kleine Nachrichten: Ein Broker verteilt mühelos Messwerte von Tausenden Sensoren gleichzeitig.
• ✓Schmale Bandbreite: Der Verwaltungsanteil pro Nachricht (Overhead) ist extrem klein, eine komplette Datennachricht kommt mit wenigen Bytes plus Topic-Name aus, ein Bruchteil eines HTTP-Requests.
• ✓Instabile Verbindungen: Quittungsmechanismen (QoS) und die Abschiedsnachricht Last Will fangen Verbindungsabbrüche sauber ab.
• ✓Entkopplung: Sender und Empfänger kennen sich nicht, dadurch lassen sich neue Abonnenten jederzeit ergänzen, ohne die Sender anzufassen.
• ✓Firewall-freundlich: Der Client (so heisst jedes angeschlossene Gerät oder Programm) baut die Verbindung immer selbst nach aussen zum Broker auf. Auf der Geräteseite muss keine Tür in der Firewall (ein sogenannter Port) von aussen geöffnet werden; erreichbar sein muss nur der Broker.

MQTT: weniger geeignet für

• ✗Harte Echtzeit im Maschinentakt: Wenn jede Millisekunde zählt, etwa bei der Steuerung von Maschinenachsen, sind spezialisierte Maschinen-Netzwerke die richtige Wahl (Fachbegriffe: Feldbusse oder Industrial Ethernet, etwa PROFINET und EtherCAT).
• ✗Grosse Dateien: MQTT ist für kurze Meldungen gebaut, für Firmware-Updates, Bilder oder Videos eignet sich ein Dateitransfer über HTTP oder ein spezialisiertes Protokoll besser.
• ✗Klassisches Frage-Antwort-Muster: Wer gezielt eine Antwort auf eine Anfrage braucht, etwa eine App, die auf Knopfdruck Daten abruft, fährt mit HTTP, der gewohnten Web-Technik, meist einfacher.
• ✗Direktverbindungen ohne Infrastruktur: MQTT braucht immer einen Broker, für eine simple Punkt-zu-Punkt-Verbindung zwischen zwei Geräten ist das zu viel des Guten.

AMQP: gut geeignet für

• ✓Für zuverlässige Zustellung, weil Empfangsbestätigungen (ACK), persistente Queues und Publisher Confirms sicherstellen, dass keine Nachricht verloren geht – auch nicht bei einem Broker-Neustart.
• ✓Für komplexe Verteilregeln, weil Exchanges mit den Typen direct, topic, fanout und headers eine Nachricht flexibel an eine oder viele Queues leiten können.
• ✓Für die Entkopplung von Systemen, weil Absender und Empfänger nie gleichzeitig verfügbar sein müssen – die Queue puffert dazwischen.
• ✓Für faire Lastverteilung, weil sich mehrere Arbeitsprozesse eine Queue teilen können und Prefetch dafür sorgt, dass niemand überlastet wird (Competing Consumers).
• ✓Für den Umgang mit Fehlern, weil nicht verarbeitbare Nachrichten über Dead-Letter-Queues (Fehler-Warteschlangen) aussortiert und später gezielt untersucht werden können.

AMQP: weniger geeignet für

• ✗Für stromsparende IoT-Sensoren mit wackliger Funkverbindung, weil AMQP verhältnismässig schwergewichtig ist; besser passt hier MQTT, das für schmale Bandbreite und Batteriebetrieb entworfen wurde.
• ✗Für sehr hohe Durchsätze mit langer Aufbewahrung und erneutem Abspielen von Ereignis-Strömen (Event-Log), weil klassische AMQP-Queues Nachrichten nach der Verarbeitung entfernen; besser passt hier Apache Kafka.
• ✗Für einfache Punkt-zu-Punkt-Aufrufe, bei denen sofort eine Antwort erwartet wird, weil ein Broker dazwischen unnötige Komplexität bringt; besser passt hier ein direkter HTTP-/REST-Aufruf oder gRPC.
• ✗Für Umgebungen ohne Betriebsressourcen, weil ein Broker eine eigene Komponente ist, die betrieben, überwacht und aktuell gehalten werden muss.