AMQP: Das Advanced Message Queuing Protocol vor­ge­stellt

Dienste müssen mit­ein­an­der kom­mu­ni­zie­ren können. In­for­ma­tio­nen werden aus­ge­tauscht, Daten über­mit­telt. Das klingt für viele einfacher, als es tat­säch­lich ist, denn bei solchen Ge­sprä­chen ver­schie­de­ner An­wen­dun­gen un­ter­ein­an­der sind gleich mehrere Schwie­rig­kei­ten zu über­win­den: Auch in der IT gibt es bei­spiels­wei­se Sprach­bar­rie­ren (in Form von ver­schie­de­nen Pro­gram­mier­spra­chen) und man muss sich an ein Protokoll halten, damit es nicht zum Chaos kommt.

Eine Lösung ver­spricht das Advanced Message Queuing Protocol – kurz AMQP: ein ge­mein­sa­mes Protokoll, das die In­for­ma­tio­nen über einen Mittler trans­por­tie­ren kann. Wie funk­tio­niert das? Und was kann AMQP noch?

Das Advanced Message Queuing Protocol wird seit 2003 ent­wi­ckelt und stammt aus­nahms­wei­se nicht aus einem de­zi­dier­ten Tech-Un­ter­neh­men, sondern wurde zunächst bei JPMorgan Chase erdacht, einer US-ame­ri­ka­ni­schen Bank. Dort entschied man sich, das Projekt mit anderen zusammen wei­ter­zu­ge­stal­ten. Neben IT-Un­ter­neh­men wie Cisco in­ter­es­siert sich aber weiterhin vor allem die Fi­nanz­bran­che für AMQP. Warum ist das so? Weil Zeit dort Geld ist: Die In­for­ma­ti­ons­über­mitt­lung spielt bei einer Bank, einer Kre­dit­kar­ten­ge­sell­schaft oder einer Börse eine große Rolle. Hier werden mehrere hun­dert­tau­send Nach­rich­ten pro Sekunde aus­ge­tauscht. Kommen Nach­rich­ten zu spät oder gar nicht an, kann das teuer werden.

Da zum damaligen Zeitpunkt kein kom­mer­zi­el­les Produkt in der Lage war, mit den An­for­de­run­gen zu­frie­den­stel­lend zurecht zu kommen, entschied man sich (na­ment­lich Pro­jekt­lei­ter John O’Hara) für ein eigenes Protokoll. O’Hara ori­en­tier­te sich an offenen Standards wie TCP/IP und entschied sich, auch AMQP frei zur Verfügung zu stellen, um so die Ent­wick­lung an dem Protokoll vor­an­zu­trei­ben. In­zwi­schen arbeitet eine OASIS-Ar­beits­grup­pe (eine ge­mein­nüt­zi­ge Or­ga­ni­sa­ti­on) an der Ent­wick­lung des Pro­to­kolls.

AMQP löst gleich mehrere Probleme: Zum einen sorgt das Protokoll (in Zu­sam­men­ar­beit mit einem Messaging Broker) für eine robuste Da­ten­über­tra­gung, zum anderen er­mög­licht AMQP, Nach­rich­ten in einer War­te­schlan­ge zu lagern. Dies wiederum lässt eine asyn­chro­ne Kom­mu­ni­ka­ti­on zu: Sender und Empfänger müssen nicht im gleichen Rhythmus agieren. Der Empfänger (Konsument) der Nachricht muss die In­for­ma­ti­on nicht direkt annehmen, ver­ar­bei­ten und dem Sender (Pro­du­zen­ten) den Empfang be­stä­ti­gen. Statt­des­sen holt er sich die Nachricht aus der War­te­schlan­ge, wenn er Ka­pa­zi­tä­ten dazu zur Verfügung hat. Das gibt dem Pro­du­zen­ten un­ter­des­sen die Mög­lich­keit wei­ter­zu­ar­bei­ten – es entsteht also kein Leerlauf.

Der Erfolg, den das noch relativ junge Protokoll erfährt, hat auch mit der In­ter­ope­ra­bi­li­tät zu tun. Das Advanced Message Queuing Protocol stellt eine ge­mein­sa­me Basis von sich aus her. Das er­mög­licht sogar, dass die ver­schie­de­nen An­wen­dun­gen in un­ter­schied­li­chen Pro­gram­mier­spra­chen verfasst sein können. Auf diese Weise ver­stän­di­gen sich auch Programme in un­ter­schied­li­chen Or­ga­ni­sa­tio­nen pro­blem­los mit­ein­an­der. Und da AMQP frei zur Verfügung steht, kann jedes Un­ter­neh­men das Protokoll ohne zu­sätz­li­che Kosten nutzen.

Im OSI-Modell agiert AMQP auf der An­wen­dungs­schicht: Es hat damit direkten Kontakt zu den ver­schie­de­nen Pro­gram­men. Auch IMAP (für E-Mails), FTP (für die Über­tra­gung von Dateien) und IRC (für Instant Messaging) sind auf dieser Schicht aktiv. Zur Über­mitt­lung der Nach­rich­ten setzt das Protokoll auf Mittler – so­ge­nann­te Messaging Broker. Diese über­neh­men die Ver­tei­lung der Nach­rich­ten an ver­schie­de­ne Empfänger und nach fest­ge­leg­ten Regeln. AMQP regelt auch das Verhalten dieser Ver­mitt­lungs­ser­ver.

Das Advanced Message Queuing Protocol bezieht sich also sowohl auf die Kom­mu­ni­ka­ti­on zwischen den ver­schie­de­nen Teil­neh­mern als auch auf das Verhalten der Broker selbst. Diese enthalten ihre An­wei­sun­gen aus den Nach­rich­ten.

Im Kosmos von AMQP gibt es drei Akteure und ein Objekt:

• Die Nachricht ist das Kern­ele­ment der ganzen Kom­mu­ni­ka­ti­on.
• Der Produzent (Producer) erstellt eine Nachricht und versendet diese.
• Der Messaging Broker verteilt die Nachricht nach de­fi­nier­ten Regeln in ver­schie­de­ne War­te­schlan­gen (Queue).
• Der Konsument (Consumer) nimmt sich die Nachricht aus der War­te­schlan­ge, auf die er zugreifen kann, und be­ar­bei­tet sie.

Im Broker wird die Ver­mitt­lung der Nachricht noch einmal auf­ge­bro­chen: Die Exchange nimmt die Nach­rich­ten entgegen und routet die Daten in die korrekte War­te­schlan­ge. In welche Queue die Nachricht gehört, erfährt die Exchange über das Binding. Man kennt vier ver­schie­de­ne Arten, wie eine Exchange Nach­rich­ten wei­ter­lei­tet.

Die erste Art, die Direct Exchange, schickt Nach­rich­ten an genau einen Empfänger und arbeitet dafür mit Routing Keys. Ein solcher Schlüssel wird der Nachricht mit­ge­ge­ben. Eine War­te­schlan­ge wiederum besitzt einen Binding Key. Dieser iden­ti­fi­ziert die Queue gegenüber der Exchange. Wenn Routing Key und Binding Key über­ein­stim­men, kann die Nachricht an die War­te­schlan­ge und damit den Empfänger der Nachricht wei­ter­ge­lei­tet werden. Es ist auch möglich, dass eine Queue mehrere Binding Keys besitzt und so auch für mehrere Routing Keys in Frage kommt. An­ders­her­um können sich mehrere Queues auch einen Binding Key teilen, was man als Multiple Binding be­zeich­net. Die Exchange ver­viel­fäl­tigt die Nachricht und sendet diese an mehrere Empfänger.

Ähnlich funk­tio­niert die Fanout Exchange. Al­ler­dings ignoriert der Broker hierbei den Routing Key voll­stän­dig. Statt­des­sen routet die Exchange eine Nachricht an alle ver­füg­ba­ren Queues und ver­viel­fäl­tigt die In­for­ma­tio­nen dabei. Auf eine andere Weise funk­tio­niert die Topic Exchange. Ähnlich zur Direct Exchange werden Routing Key und Binding Keys ge­gen­ein­an­der ab­ge­gli­chen, aber es muss keine exakte Über­ein­stim­mung vorliegen. Statt­des­sen verwendet man Platz­hal­ter. So ist es möglich, Nach­rich­ten gezielt für mehrere Queues be­reit­zu­stel­len.

Die Headers Exchange schließ­lich agiert statt mit einem Routing Key mit dem Header einer Nachricht. Dort befinden sich Werte, die mit dem Binding ab­ge­gli­chen werden. Das Argument mit der Be­zeich­nung x-match bestimmt, ob alle Werte über­ein­stim­men müssen (Wert: all) oder nur einer dem Binding ent­spre­chen muss (Wert: any). Während ersteres der Direct Exchange ent­spricht, kann mit letzterem der gleiche Effekt wie bei einer Topic Exchange erzeugt werden.

Ein Frame ist bei AMQP die grund­le­gen­de Einheit. Eine Ver­bin­dung besteht aus der ge­ord­ne­ten Abfolge von Frames. Ordnung bedeutet in diesem Fall, dass der letzte Frame nicht beim Empfänger ankommen darf, bevor nicht auch alle anderen Frames zuvor ihr Ziel erreicht haben. Jeder Frame lässt sich (in der Version 1.0) in drei Segmente un­ter­tei­len:

• Frame Header: Dieser ob­li­ga­to­ri­sche Header hat eine Größe von 8 Byte. Hier finden sich In­for­ma­tio­nen, die das Routing der Nachricht bestimmen.
• Extended Header: Dieser Bereich ist optional und hat auch keinen fest­ge­leg­ten Umfang. Er dient dazu, zukünftig den Header um weitere In­for­ma­tio­nen zu erweitern.
• Frame Body: Im Body befinden sich die ei­gent­lich zu über­tra­gen­den Daten. Die Größe ist frei wählbar. Dieser Bereich kann al­ler­dings auch leer bleiben, dann fungiert der Frame nur dazu, die Ver­bin­dung auf­recht­zu­er­hal­ten.

Der Body eines Frames wiederum kann neun ver­schie­de­ne Formen annehmen:

• open: Ver­han­delt die Ver­bin­dungs­pa­ra­me­ter zwischen Broker und Client.
• begin: Gibt an, dass eine Ver­bin­dung startet.
• attach: Der Nachricht wird ein Link angehängt, der notwendig ist, um den Da­ten­trans­fer nutzen zu können.
• flow: Ändert den Status eines Links.
• transfer: Mit dem Transfer Frame wird die ei­gent­li­che Nachricht über­mit­telt.
• dis­po­si­ti­on: Ein Dis­po­si­ti­on Frame in­for­miert über Än­de­run­gen an der In­for­ma­ti­ons­lie­fe­rung.
• detach: Entfernt den Link.
• end: Gibt an, dass die Ver­bin­dung beendet wird.
• close: Beendet die Ver­bin­dung und erklärt, dass keine weiteren Frames mehr gesendet werden.

Jede Queue hat einen eigenen Namen, der sie gegenüber den anderen Teil­neh­mern iden­ti­fi­ziert. Entweder legt ein Client oder der Broker die Be­zeich­nung fest. Eine War­te­schlan­ge wird durch einen Speicher rea­li­siert. Dieser kann entweder dauerhaft auf einer Fest­plat­te liegen oder flüchtig in einem Ar­beits­spei­cher. Die dau­er­haf­te Variante ga­ran­tiert, dass auch nach dem Neustart eines Brokers die War­te­schlan­ge weiterhin besteht. Es ga­ran­tiert aber nicht, dass auch Nach­rich­ten dauerhaft gesichert sind: Hier hängt es von der Nachricht ab, ob diese auch nach einem Neustart noch zur Verfügung stehen.

Was passiert, wenn ein Consumer die Nachricht in der War­te­schlan­ge nicht abrufen kann, weil bei­spiels­wei­se der Client oder die Ver­bin­dung zu­sam­men­ge­bro­chen ist? Man kann ent­schei­den, ob ein Consumer den Erhalt einer Nachricht or­dent­lich quit­tie­ren muss oder die reine Aus­lie­fe­rung zum Erfolg ausreicht. Sollte die erste Variante gewählt werden und der Consumer keine Nachricht zu­rück­sen­den, versucht der Broker die Nachricht an einen anderen Consumer zu senden oder den ei­gent­li­chen Empfänger erneut zu erreichen. Ist al­ler­dings die Variante ohne Be­stä­ti­gung ein­ge­schal­tet und der Consumer ruft die Nachricht nicht ab, geht diese verloren.

Es ist aber auch möglich, dass ein Client die Annahme einer Nachricht bewusst ablehnt. Dies kann sinnvoll sein, wenn die Ver­ar­bei­tung der Nachricht nicht funk­tio­niert. Die Rück­mel­dung des Consumers ver­an­lasst den Broker, die Nachricht entweder komplett zu löschen oder erneut in die War­te­schlan­ge ein­zu­glie­dern.

Es gibt derzeit zwei voll­stän­dig un­ab­hän­gi­ge Versionen des Advanced Message Queuing Protocols. Die Version 1.0 wird von der OASIS-Gruppe ent­wi­ckelt. Besonders bei RabbitMQ kommt aber die etwas ältere Fassung 0-9-1 zum Einsatz. Beide sind nicht mit­ein­an­der kom­pa­ti­bel. Die 1.0-Fassung un­ter­schei­det sich in erster Linie durch die ge­min­der­te Bedeutung von Brokern, Bindings und Exchanges. 0-9-1 benötigt diese nicht, verbietet es aber auch nicht, solche Mit­tels­män­ner ein­zu­set­zen.