RabbitMQ Konzepte

Literatur

Elemente

  1. Queue

    erhält Nachrichten

  2. Exchange

    Nimmt Nachrichten entgegen

  3. Binding

    Verbindet Queue mit Exchange, leitet Nachrichten weiter (routing)

Direct Exchange

  1. routing

    leitet Nachrichten an die Queue weiter, deren routing key zur Nachricht passt

  2. default

    Neue Queues werden automatisch an Default Exchange mit Namen "" gebunden, die den Queue-Namen als routing key verwendet.

  3. eigene

    Falls komplexeres Verhalten gewünscht, können eigene DirectExchanges angelegt werden

Fanout Exchange

  1. routing

    leitet Nachrichten an alle gebundenen Queues weiter

  2. Entkopplung

    Producer weiss nichts darüber, wie wann und an wen seine Nachrichten weitergeleitet werden

  3. Flexibilität

    Consumer können nachträglich ohne Programmänderung hinzugefügt werden, z.B. für Monitoring

Topic Exchange

  1. routing

    leitet Nachrichten an alle Queues weiter, die das Thema haben wollen

  2. Entkopplung

    Consumer weiss nichts darüber, woher die Nachrichten kommen

  3. Flexibilität

    Producer können nachträglich ohne Programmänderung hinzugefügt werden

Persistente Nachrichten

  1. Queues und Exchanges

    werden bei Neustart des Servers wieder angelegt, falls durable Attribut gesetzt

  2. Message

    Message mit persistent delivery mode wird auf Platte gespeichert (persistency log) und übersteht Ausfall, wenn die zugehörige Queue und Exchange durable sind

  3. Performance

    etwa Faktor 10 weniger Durchsatz bei persistenten Nachrichten. Ausserdem Probleme bei Clustern

Hard drive corruption, buggy behavior by a consumer, or other extreme events can trash/black-hole persistent messages. It’s ultimately up to you to ensure your messages arrive where they need to go, and persistent messaging is a great tool to help you get there.

RabbitMQ in Action

1 "Hello World!"

"The simplest thing that does something"

Producer erzeugt Nachrichten, diese werden direkt an eine Queue geliefert, ein Consumer liest Nachrichten aus

Architektur

Connect zu rabbitMQ

Connection

Eine Connection ist die TCP-verbindung zum RabbitMQ-Server (factory.setHost(...)).

Channel

Eine Connection kann mehrere Channels enthalten. Ein Channel stellt die Verbindung eines Threads zum RabbitMQ-Server dar. Würde jeder Thread eine eigene TCP-Verbindung aufmachen, würde dies unter Umständen eine erhebliche Last für den Server bedeuten (bei sagen wir mal 1000 Threads ....)

Queue erzeugen

Queue

Die Queue wird (nur) dann erzeugt, wenn sie noch nicht existiert.
name: Der (eindeutige) Name der Queue
durable: queue wird bei Neustart des Servers wieder angelegt
exclusive: queue wird bei disconnect des erzeugenden Clients gelöscht
auto_delete: queue wird gelöscht, wenn kein Client mehr connected ist
arguments: zusätzliche Argumente (null --> keine Argumente)

Nachricht senden

Nachricht verschicken, der Body ist ein byte[]
exchange: Name der exchange, "" wählt die default exchange
routing_key: Bei Verwendung der default-Exchange der Name der Queue
properties: Properties der Nachricht (z.B. routing keys) body: byte[] das die Nachricht enthält

Nachricht empfangen

Callback

Callback-Funktion wird aufgerufen, sobald Nachricht eintrifft. Vereinfachung: QueueingConsumer stellt Callback zur Verfügung und kann über nextDelivery() ausgewertet werden.

Alternative: Expliziter Poll

polling

Der Client holt Nachrichten explizit ab. Versand und Empfang können so zeitlich entkoppelt werden.

Sinnvoll etwa bei Worker-Threads.

Zusammengefasst: Producer

Consumer

Oder einfacher:

Ein serverloser Chat:

Architektur

Konzept

Jeder Client schickt Nachricht an die gleiche Fanout-Exchange

Jeder Client erzeugt und bindet eine Queue an diese Exchange, liest alle Nachrichten von dieser Queue und gibt sie aus.

Wie verhindert man, dass die selber gesendete Nachricht ebenfalls ausgegegeben wird ?
Will man das überhaupt ?

Architektur Logistik-Simulation

  1. Quelle schickt auf fanout Exchange

    leitet Nachrichten an alle Queues weiter, die im Broker konfiguriert sind

  2. bind auf Queue(s)

    Wird nicht vom Producer ausgeführt, sondern im Admin-Interface festgelegt.

    Producer (Quelle) weiss nichts darüber, wer die Nachrichten bekommt

Quelle

Senke

Im Beispiel Steuerung durch EventMachine, normalerweise Steuerung durch Applikation. (Ansonsten besser Realisierung durch Callback)

Monitor

← →

/

#