Was ist RabbitMQ?
RabbitMQ ist ein Message Broker. Er sitzt zwischen den Teilen eines Systems, die Arbeit erzeugen, und denen, die sie erledigen, hält Nachrichten, bis jemand bereit ist, und sorgt dafür, dass jede bearbeitet wird.
Er setzt AMQP 0-9-1 samt Erweiterungen um, unterstützt Publish/Subscribe, Arbeitsqueues und Request/Reply und steht unter MPL-2.0. Begonnen hat er bei Rabbit Technologies, gepflegt wird er heute unter Broadcom.
Das Problem, das er löst
Ohne Broker ruft ein Dienst einen anderen direkt auf und wartet. Das funktioniert, bis es das nicht mehr tut:
- Der zweite Dienst ist ausgefallen, also fällt der erste mit aus, und jemand sieht eine Fehlermeldung zu etwas, wonach er nie gefragt hat.
- Der zweite Dienst ist langsam, also blockiert der erste, und die Langsamkeit breitet sich durchs System aus.
- Arbeit kommt schneller herein, als sie verarbeitet wird, und für den Überschuss gibt es keinen Platz ausser dem Arbeitsspeicher.
Ein Broker macht aus dem Aufruf eine Übergabe. Der Erzeuger schreibt eine Nachricht und macht weiter. Der Verbraucher nimmt sie, wenn er kann. Ist der Verbraucher ausgefallen, hält die Queue. Kommt Arbeit stossweise, fängt die Queue sie ab. Reicht ein Verbraucher nicht, kommt ein zweiter dazu und beide teilen sich die Queue.
Die übliche erste Anwendung ist genau das: eine Operation, die Sekunden dauert und nicht passieren muss, während jemand wartet. Die Bestätigungsmail versenden, das PDF erzeugen, den Datensatz neu indizieren. Auf eine Queue legen und die Seite sofort ausliefern.
Er gibt dir ausserdem etwas, worauf du skalieren kannst
Dieser Teil fällt später auf und ist oft mehr wert als die Entkopplung.
Sobald Arbeit über eine Queue läuft, sind Erzeuger und Verbraucher getrennte Installationen und skalieren unabhängig voneinander. Eine Lastspitze bringt zusätzliche Erzeuger, ohne die Worker anzufassen, ein Rückstau zusätzliche Worker, ohne die Webschicht anzufassen.
Nützlicher noch: die Queue liefert ein ehrliches Signal zum Skalieren. Autoscaling nach CPU ist ein Ersatzmass für Auslastung, und ein schlechtes: ein Worker, der auf eine langsame externe API wartet, sieht untätig aus und ist vollständig beschäftigt. Die Queue-Tiefe ist das tatsächliche Mass unerledigter Arbeit. Wächst sie, kommen die aktuellen Worker nicht nach, was auch immer ihre CPU sagt. Leert sie sich, hast du mehr Kapazität als nötig und kannst sie zurückgeben.
Damit wird die Skalierungsregel einfach genug, um sie aufzuschreiben und ihr zu trauen: Verbraucher hinzufügen, solange der Rückstau wächst, und wegnehmen, sobald er abgebaut ist.
Queues und Streams sind verschiedene Dinge
Diese Unterscheidung entscheidet, ob RabbitMQ deine Antwort ist, und hier liegt die meiste Verwirrung.
Eine Queue verteilt Arbeit. Jede Nachricht geht an einen Verbraucher, der sie bestätigt, danach ist sie weg. Mehr Verbraucher heisst geteilte Arbeit. Die Queue ist ein Puffer und kein Archiv.
Ein Stream führt ein Log. Nachrichten bleiben nach dem Lesen bestehen, mehrere unabhängige Verbraucher lesen jeweils das Ganze an ihrer eigenen Position, und ein neuer Verbraucher kann von vorn beginnen. Das Log ist das Archiv.
RabbitMQ ist um das Erste herum gebaut und hat Funktionen fürs Zweite dazubekommen. Kafka ist um das Zweite herum gebaut. Wenn deine Anforderung lautet, dass viele Systeme jedes Ereignis verarbeiten und ein nächstes Jahr hinzugefügter Verbraucher das letzte Jahr nachspielen kann, beschreibst du ein Log und solltest dir eines ansehen. Wenn deine Anforderung lautet, Arbeit vom Anfrageweg zu nehmen und über Worker zu verteilen, ist ein Broker die kleinere und einfachere Antwort.
Wann du einen brauchst
- Langsame Arbeit auf dem Anfrageweg. Der klarste Fall, und der, der sich sofort auszahlt.
- Dienste, die nicht gemeinsam ausfallen dürfen. Eine Queue ist der Stossdämpfer dazwischen.
- Stossweise Last. Die Queue-Tiefe wächst und fällt, statt dass das System umkippt, und sie ist das Signal, auf das du die Worker skalierst.
- Fan-out. Ein Ereignis, mehrere interessierte Abnehmer, ohne dass der Erzeuger sie kennen muss.
Wann nicht
Eine einzelne Anwendung mit schnellen Operationen braucht keinen. Ein Broker ist eine weitere Komponente zum Betreiben, Überwachen und Durchdenken, und ihn einzuführen, bevor ein Warteschlangenproblem existiert, kauft Komplexität ohne Nutzen.
Wenn "nimm doch die Datenbank" ehrlich ist. Eine kleine Arbeitsqueue in einer Tabelle in PostgreSQL ist bei geringem Volumen ein legitimer Entwurf. Bei hohem Volumen hört sie auf, es zu sein, und viele Systeme kommen nie dorthin.
Wenn du das Log brauchst. Siehe oben. Einen Broker für eine Streaming-Anforderung zu wählen heisst, ein Log schlecht nachzubauen.
Was der Betrieb eines Clusters verlangt
- Dauerhaftigkeit ist eine Entscheidung, die du triffst. Nachrichten, Queues und Exchanges sind je einzeln dauerhaft oder nicht, und Publishes lassen sich bestätigen oder blind absetzen. Standardwerte wissen nicht, wie wichtig deine Nachrichten sind.
- Queues brauchen eine Obergrenze. Eine unbegrenzte Queue mit einem hängenden Verbraucher wächst, bis sie den Broker mitreisst. Längenlimits und Dead-Letter-Queues halten den Fehler lokal.
- Clustering hat echte Semantik. Ein Cluster dient der Verfügbarkeit, und was bei einer Netzwerkpartition passiert, ist eine Konfigurationsentscheidung mit Folgen für den Datenverlust, in beide Richtungen.
- Tiefe und Rate zusammen beobachten. Eine stetig wachsende Queue heisst, dass die Verbraucher hinterherhinken, und das ist lange sichtbar, bevor etwas bricht, sofern jemand hinschaut.
- Upgrades sind abgestimmt. Broker und Clients haben Versionserwartungen, und einen Cluster mit aktiven Verbindungen durchzurollen braucht einen Plan.
Der Fehlerfall ist selten der abstürzende Broker. Es ist eine Queue, die niemand begrenzt hat und die über ein Wochenende volläuft, weil ein Verbraucher am Freitag still gestorben ist.
Wo VSHN ins Bild kommt
VSHN betreibt RabbitMQ auf Schweizer Cloud-Infrastruktur, mit Betrieb rund um die Uhr, auf Cloudscale und auf Enterprise Private Cloud, mit AMQP, MQTT und STOMP und mit täglichen Backups. Servala nimmt Bestellungen in Selbstbedienung entgegen.
Wenn bei dir noch offen ist, ob es ein Broker oder ein Log werden soll, klär das zuerst: es ist später schwerer zu ändern als die Frage, wer es betreibt. Unser Hosting-Vergleich behandelt die Anbieterfrage, sobald du dort ankommst.