AMQP (Advanced Message Queuing Protocol) ist ein standardisiertes Protokoll für zuverlässiges Messaging zwischen Anwendungen. Es kommt zum Einsatz, wenn Systeme Daten und Ereignisse asynchron, entkoppelt und mit Zustellgarantien austauschen sollen – statt direkter API-Calls, die sofortige Verfügbarkeit beider Seiten voraussetzen.
Wie funktioniert AMQP?
AMQP läuft über einen Message Broker, der als Mittler zwischen Sender und Empfänger agiert. Der Producer erzeugt Nachrichten und sendet sie an den Broker. Der Broker nimmt sie an, puffert sie in Queues und verteilt sie an Consumer, die die Nachrichten verarbeiten.
Entscheidend für die Praxis: AMQP unterstützt Acknowledgements (Ack/Nack). Eine Nachricht gilt erst als verarbeitet, wenn der Consumer dies bestätigt. Bleibt die Bestätigung aus – etwa wegen eines Neustarts oder Netzwerkfehlers – stellt der Broker die Nachricht erneut zu. Das macht AMQP robust in instabilen Umgebungen.
Delivery Guarantees: Was wirklich zählt
AMQP-Systeme werden typischerweise im At-least-once-Modus betrieben: Eine Nachricht kann unter Umständen mehrfach ankommen, geht aber nicht verloren. Der Consumer muss daher idempotent gebaut sein – doppelte Verarbeitung darf keinen Schaden anrichten.
At-most-once (keine Duplikate, aber möglicher Verlust) ist selten gewollt. Exactly-once ist in verteilten Systemen kein Broker-Feature, sondern ein Architekturthema: Es erfordert Idempotenz plus Transaktionslogik auf Anwendungsebene.
AMQP 1.0 vs. AMQP 0-9-1
In der Praxis existieren zwei Welten. AMQP 1.0 ist der moderne, herstellerübergreifende Standard mit klarer Interoperabilität. AMQP 0-9-1 ist das weit verbreitete Protokoll des RabbitMQ-Ökosystems – umgangssprachlich oft einfach „AMQP" genannt, aber nicht kompatibel mit AMQP 1.0. Wer Interoperabilität zwischen verschiedenen Implementierungen braucht, sollte explizit nach AMQP 1.0 fragen.
Typische Use Cases in Industrie und OT/IT
AMQP eignet sich für event-driven Integration zwischen MES, ERP und Qualitätssystemen – etwa für Status-Events wie „Auftrag gestartet", „Charge gesperrt" oder „Prüfung bestanden". Es wird außerdem eingesetzt, um OT-Datenpipelines zu entkoppeln: Ein Edge-Gateway publiziert Daten, mehrere Dienste wie Historian, Reporting und Alerting konsumieren sie unabhängig voneinander. Und es federt Lastspitzen ab, weil die Queue Nachrichten puffert, während Consumer im eigenen Tempo skalieren.
AMQP vs. MQTT vs. Kafka
AMQP ist stark bei zuverlässigem Enterprise-Messaging mit Queues, Acknowledgements und flexiblem Routing über einen Broker. MQTT ist leichtgewichtiger, vor allem für Telemetrie und IoT-Szenarien ausgelegt und hat weniger umfangreiche Messaging-Semantik. Kafka ist eine Log- und Stream-Plattform für hohen Durchsatz und Event-Streaming mit einem anderen Konsummodell auf Basis von Topics und Offsets – kein direkter Ersatz für AMQP, sondern eine andere Architekturentscheidung.
FAQ
Wann sollte man AMQP statt einer REST API verwenden? REST eignet sich für kontrollierte Abfragen mit klarer Request/Response-Semantik. AMQP ist sinnvoll, wenn Systeme entkoppelt bleiben sollen, Zustellgarantien nötig sind oder Empfänger nicht permanent verfügbar sein können.
Ist RabbitMQ dasselbe wie AMQP? Nein. RabbitMQ ist ein Message Broker, der primär AMQP 0-9-1 implementiert. AMQP ist das Protokoll. RabbitMQ unterstützt inzwischen auch AMQP 1.0, aber der Kern basiert auf 0-9-1.
Was ist ein Dead-Letter-Exchange? Ein Dead-Letter-Exchange ist ein Mechanismus, der Nachrichten auffängt, die nicht verarbeitet werden konnten – etwa wegen wiederholter Fehler oder abgelaufener TTL. Er verhindert Endlosschleifen und macht Fehler sichtbar, statt sie still zu verwerfen.
Wie wird AMQP in OT-Umgebungen abgesichert? Mindeststandard sind TLS-Verschlüsselung, Authentifizierung am Broker und granulare Berechtigungen für Publish und Subscribe. In Produktionsumgebungen kommen Netzsegmentierung und Broker-Härtung hinzu – der Broker darf kein offener Durchleitungspunkt zwischen OT und IT werden.
