Hallo RabbitMQ - 2. Routing

Im nächsten Schritt geht es jetzt darum ein Gesamtkonzept für das aktuelle System zu finden. Dieses umfasst folgende Komponenten (abstrahiert):

• Die UI-Applikation, über welche die Benutzer Daten anzeigen, erstellen, ändern und löschen können.
• Eine Dokumenten-API, über welche Dokumente angelegt, gelöscht und bearbeitet werden können. Außerdem kann jedes Dokument 1-n Versionen enthalten
• Ein Renderservice, der zu jeder Dokumentversion eine Vorschau rendert
• Ein Backupservice, der die erste Version jedes Dokumentes nochmal extra wegspeichert
• Ein Synchronisationsservice, der jede Dokumentänderung mit einem externen System synchronisiert

Aktuell unterteilen sich die Event-Producer und Consumer in folgende Gruppen:

Um diese Struktur umzusetzen, bietet RabbitMQ einige weitere Möglichkeiten an, um unsere Queues aus dem ersten Teil flexibler zu machen:

Routing

https://www.rabbitmq.com/tutorials/tutorial-four-dotnet.html

Für das Routing bietet RabbitMQ diverse Möglichkeiten an, um unsere Queues zu befüllen.

Direct exchange

Aus Teil 1 kennen wir ja bereits die Bindings mit dem RoutingKey. Direct exchange bedeutet also:

Finde alle Queues mit dem gleichen Key wie die Nachricht und schreibe sie dort hinein.

Es dürfen natürlich auch mehrere Queues mit demselben BindingKey vorhanden sein:

Topic Exchange

Topic Exchange ist ähnlich zum Direct exchange, bietet aber die Möglichkeit mehrere Kriterien zu verwenden.

Ein Topic ist ein Textwert der 1 oder mehrere durch . getrennte Wörter, sowie ggf. Platzhalter enthält. Ohne Platzhalter verhält sich Topic Exchange exakt wie Direct Exchange.

Es gibt nur zwei Platzhalter:

• * (Stern) steht für genau 1 beliebiges Wort
• # (Raute) steht für 0 bis n Wörter

Wir könnten also z.B. die Konvention einführen, dass Binding Keys folgendes Format haben müssen:

<Kontext>.<Aktion>.

Es wäre in unserem Fall also möglich z.B. die Topic version.created, sowie document.* zu verwenden.

• Alle Änderungen an einem Dokument gelangen immer an die UI, damit diese sich ggf. aktualisieren kann
• Alle neuen Versionen gehen an die Render-Queue, damit eine neue Vorschau gerendert wird

Wichtig:

• Der Binding Key muss trotzdem genau gematched werden, sonst gibt es keinen Treffer. document oder document.created.today wären somit von obigen Filtern nicht erkannt.
• # als Filter matched alles

Umsetzungsmöglichkeit

Fügen wir jetzt die Teile mit den neuen Möglichkeiten zusammen, könnte sich folgendes Bild ergeben.

Topics

• document
  • created
  • restored
  • deleted
  • metadata_changed
  • version.created
• preview
  • created
  • failed

Beispielprojekt

Ich habe mal versucht das beispielhaft mit dem minimalen Setup umzusetzen. Das vollständige Projekt findet man hier: https://github.com/weidmanngabriel/rabbitmq_topics_poc

Man kann jetzt einfach auf der Kommandozeile eingeben welches Event die Dokument-API abschicken soll. Die Events verhalten sich dann so wie im obigen Bild definiert.

---

Mit diesem Wissen kommen wir schonmal ein ganzes Stück weiter. Im nächsten Teil können wir uns dann Details wie Sende- und Empfangsbestätigung, Callbacks, etc. ansehen.