AMQP
Broker-basiertes Messaging-Protokoll für zuverlässige, entkoppelte Nachrichtenzustellung zwischen Systemen.
Das ist der Aufbau: ein Producer, ein Broker mit einem Exchange und zwei Queues, dahinter zwei Consumer. Bindings verbinden den Exchange mit den Queues.
In 30 Sekunden
AMQP (Advanced Message Queuing Protocol) ist ein Protokoll, mit dem Programme sich über einen Vermittler (Broker) Nachrichten schicken, ohne direkt miteinander verbunden zu sein. Der Absender legt seine Nachricht beim Broker ab, der sie in eine Warteschlange (Queue) einsortiert und an den passenden Empfänger ausliefert. So arbeiten Systeme entkoppelt: Der Empfänger muss nicht online sein, wenn gesendet wird – die Nachricht wartet. Verbreitet wurde AMQP vor allem durch die Broker-Software RabbitMQ. Eingesetzt wird es überall dort, wo Aufträge zuverlässig und ohne Verlust zwischen Backend-Diensten übergeben werden müssen.
AMQP funktioniert wie ein Postamt mit Sortieranlage. Man wirft einen Brief mit einer Zieladresse (dem Routing-Key) ein; das Postamt (der Exchange) entscheidet anhand fester Sortierregeln (der Bindings), in welche Postfächer (Queues) der Brief kommt. Die Empfänger leeren ihre Fächer, wann sie Zeit haben – und bestätigen mit einer Empfangsquittung (ACK), dass der Brief angekommen ist. Geht die Quittung nicht ein, wird der Brief erneut zugestellt.
Wo trifft man AMQP an?
Auftragsverarbeitung im Hintergrund
Zeitaufwändige Aufgaben werden nicht sofort erledigt, sondern in eine Queue gelegt und von separaten Arbeitsprozessen abgearbeitet. Beispiel: Ein Webshop nimmt eine Bestellung an und legt den Auftrag «Rechnung erstellen» in eine Queue – der Kunde wartet nicht, bis das PDF fertig ist.
Entkopplung von Microservices
Einzelne Dienste tauschen Ereignisse aus, ohne sich gegenseitig direkt aufzurufen. Beispiel: Der Dienst «Zahlung» meldet «Zahlung eingegangen»; die Dienste «Versand» und «Buchhaltung» reagieren darauf unabhängig voneinander.
Lastspitzen abfedern (Puffer)
Kommen mehr Anfragen herein, als sofort verarbeitet werden können, staut die Queue sie auf und gibt sie im machbaren Tempo weiter. Beispiel: Bei einer Rabattaktion treffen tausende Bestellungen ein – die Queue puffert sie, statt dass die Datenbank überlastet wird.
Industrielle Telemetrie / OT-Anbindung
Messwerte und Statusmeldungen aus der Produktion werden gesammelt und an Auswertungssysteme verteilt. Beispiel: Anlagendaten laufen über einen AMQP-Broker in ein Leitsystem, das sie an Dashboard, Archiv und Alarmierung weiterverteilt.
Cloud-Integration
Grosse Cloud-Dienste bieten AMQP-1.0-fähige Message-Broker an, um Anwendungen lose zu koppeln. Beispiel: Microsoft Azure Service Bus spricht AMQP 1.0, sodass Anwendungen herstellerunabhängig anbinden können.
Verteilung an mehrere Empfänger (Fan-out)
Eine Nachricht wird gleichzeitig an mehrere interessierte Dienste verteilt. Beispiel: Ein «Benutzer registriert»-Ereignis geht zeitgleich an Willkommens-Mail, Statistik und Bereitstellung des Kontos.
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.
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.
Fakten
- Advanced Message Queuing Protocol
- Broker-basiertes Messaging-Protokoll (Nachrichtenwarteschlangen)
- AMQP 0-9-1 (Broker-Modell mit Exchanges, geprägt von RabbitMQ) und AMQP 1.0 (OASIS-/ISO-Standard, reines Wire-Protokoll)
- AMQP 1.0 ist OASIS-Standard (2012) und ISO/IEC 19464 (2014)
- TCP; Standard-Port 5672, verschlüsselt (TLS) 5671
- Producer → Exchange → (Bindings/Routing-Key) → Queues → Consumer
- direct, topic, fanout, headers
- ACK, persistente Queues/Messages, Publisher Confirms, Dead-Letter-Queues, Prefetch
Im Detail
Das Grundmodell: Exchange, Queue, Binding
Im weit verbreiteten AMQP 0-9-1 schickt ein Absender (Producer) seine Nachricht nie direkt an eine Warteschlange, sondern immer an einen Exchange (Verteiler). Der Exchange ist eine Art Sortierstelle: Anhand von Regeln, den Bindings, und einem mitgeschickten Routing-Key (einer Art Zieladresse) entscheidet er, in welche Queues die Nachricht kopiert wird. Aus den Queues holen die Empfänger (Consumer) die Nachrichten ab. Diese Trennung ist der Kern: Absender kennen nur den Exchange, Empfänger nur ihre Queue – ändert sich die eine Seite, muss die andere nichts wissen.
Die vier Exchange-Typen
direct liefert an Queues, deren Binding-Schlüssel exakt zum Routing-Key passt – gut für gezielte Zustellung. topic erlaubt Muster mit Platzhaltern (etwa «sensor.halle1.*»), sodass Empfänger sich für ganze Themengruppen anmelden können. fanout ignoriert den Routing-Key und schickt jede Nachricht an alle gebundenen Queues – das ist das Rundsenden (Broadcast). headers routet nicht über den Routing-Key, sondern über frei definierbare Kopffelder der Nachricht.
Warum Nachrichten nicht verloren gehen
AMQP ist auf Zuverlässigkeit ausgelegt. Ein Consumer bestätigt jede erfolgreich verarbeitete Nachricht mit einem ACK (Acknowledgement, Quittung); bleibt die Quittung aus – etwa weil der Prozess abstürzt – stellt der Broker die Nachricht erneut zu. Werden Queues und Nachrichten als «persistent» markiert, schreibt der Broker sie auf die Festplatte, sodass sie einen Neustart des Brokers überstehen. Zusätzlich melden Publisher Confirms dem Absender, dass der Broker die Nachricht wirklich angenommen hat. Nachrichten, die wiederholt fehlschlagen, wandern in eine Dead-Letter-Queue (Fehler-Warteschlange), statt endlos im Kreis zu laufen.
Faire Verteilung auf viele Arbeiter
Teilen sich mehrere Consumer eine Queue, verteilt der Broker die Nachrichten unter ihnen (Competing Consumers) – so lässt sich die Verarbeitung einfach durch mehr Arbeitsprozesse skalieren. Damit ein schneller Consumer nicht mit Arbeit überschüttet wird und langsame leerlaufen, begrenzt der Prefetch-Wert, wie viele unbestätigte Nachrichten ein Consumer gleichzeitig halten darf. So bekommt jeder nur so viel, wie er gerade schafft.
AMQP 0-9-1 gegen AMQP 1.0 – ein wichtiger Unterschied
«AMQP» meint in der Praxis zwei verschiedene Dinge. AMQP 0-9-1 ist das Modell, das RabbitMQ bekannt gemacht hat: Es schreibt Exchanges, Queues und Bindings fest vor. AMQP 1.0 ist dagegen ein offizieller OASIS- und ISO-Standard und definiert nur, wie zwei Partner Nachrichten über die Leitung austauschen (ein reines Wire-Protokoll) – ohne ein bestimmtes Broker-Modell vorzuschreiben. Beide teilen den Namen, sind aber nicht kompatibel. Wer «AMQP» sagt, sollte darum klarstellen, welche Version gemeint ist. AMQP 1.0 findet sich unter anderem in Cloud-Brokern wie Azure Service Bus.
Abgrenzung zu MQTT und Kafka
MQTT ist bewusst leichtgewichtig und auf einfaches Publish/Subscribe für IoT und Edge-Geräte mit schmaler Bandbreite ausgelegt – es hat kein Exchange-Modell und weniger eingebaute Zustellgarantien. AMQP ist mächtiger und zielt auf zuverlässiges Enterprise-Messaging zwischen Backend-Diensten. Apache Kafka wiederum ist keine klassische Queue, sondern ein aufbewahrender Ereignis-Strom (Log): Nachrichten bleiben erhalten und können mehrfach gelesen und erneut abgespielt werden – ideal für hohe Datenströme und Streaming. Als Faustregel: MQTT an der IoT-Kante, AMQP für zuverlässige Backend-Aufträge, Kafka für grosse Ereignis-Ströme und Analyse.