In RabbitMQ, die teurer ist, mehrere Warteschlangen pro Austausch oder mehrere Austausche und weniger Warteschlangen pro Stück?
Also entschieden wir uns für RabbitMQ als Nachrichten- / Event-Bus in unserer Migration zu Micro-Services-Architektur, aber wir konnten keine definitive Antwort auf die Frage finden, wie wir unsere Warteschlangen am besten gestalten können, wir haben zwei Möglichkeiten gehen Sie mit:
-
Ein Hauptaustausch, bei dem es sich um einen Fanout-Austausch handelt, der wiederum Nachrichten an eine Hauptwarteschlange zur Protokollierung und zu anderen Zwecken und einen anderen Subaustausch fächert, der die Nachrichten an jede gewünschte Warteschlange weiterleitet Verwenden des Nachrichten-Routing-Schlüssels. Wir erwarten, dass die Anzahl der Warteschlangen hinter dem Sub-Exchange einige wie eine große Anzahl sein wird. Dies kann durch diese Grafik erklärt werden:
-
Ein Hauptaustausch, bei dem es sich um einen Themenaustausch handelt, mit noch einer Hauptwarteschlange, die über den Routingschlüssel "#" an diesen Austausch gebunden ist. Diese Haupt-Vermittlungsstelle wird auch das Haupt-Routing zu anderen Unter-Vermittlungsstellen handhaben, so dass Vermittlungsschlüssel "Vereinbarungen. #", "Zuweisungen. #", "Nachrichten. #" Sein können, die dann verwendet werden, um mehrere Sub-Austauschknoten zu binden Englisch: www.openbsd.dk/faq/pf//queueing.html Sub - exchange kann also alle "Zuweisungen" verarbeiten und Warteschlangen, die an diesen Austausch gebunden sind, könnten durch Routing - Schlüssel wie "assignments.accepted", "assignment.deleted" ... gebunden sein eine große Anzahl von Warteschlangen wird weniger pro Austausch sein, sie werden irgendwie zwischen den Vermittlungsstellen verteilt.
Also, welches dieser Szenarien könnte der beste Ansatz sein? Schneller auf RabbitMQ, weniger Overhead.
Wenn Sie daran denken, werden alle Warteschlangen, Austausche und Bindungen sofort von dem Dienst ausgeführt, der entweder veröffentlicht oder abonniert wird.
1 Antwort
Ich fasse zuerst zusammen, was ich denke, ist deine Frage, da ich sicher bin, dass sie irgendwo in deinem Post vergraben ist.
Es ist wünschenswert, zusätzlich zu einer Reihe von arbeitsspezifischen Warteschlangen für die eigentliche Nachrichtenverarbeitung eine Tracer / Logging-Warteschlange zu haben. Welche Austauschtopologie eignet sich am besten für dieses Szenario?
Zunächst einmal macht keine der beiden Optionen bei Ihrer Bewerbung viel Sinn. Option 1 erstellt einen Austausch, der unabhängig davon eine Nachricht an jede daran gebundene Warteschlange sendet. Das ist eindeutig nicht das, was du willst. Option 2 wird Ihnen eine ziemlich komplexe Routing-Topologie geben, für die der Nutzen unklar ist, und der Nachteil ist schmerzhafte Wartung und eine steile Lernkurve. (Nur weil Sie etwas tun können, bedeutet das nicht, dass Sie tun sollten.)
Was ist zu tun?
Es ist wichtig, daran zu denken, dass in RabbitMQ die Warteschlangen die Ressourcen des Brokers verbrauchen. Austausche verbinden nur Warteschlangen mit Publishern. Der Austausch ist ein Mittel zum Zweck, während die Warteschlange das Ende selbst ist.
Was Sie stattdessen tun sollten, ist einen einzelnen Themenaustausch einzurichten. Binden Sie die Ablaufverfolgungswarteschlange an den Routingschlüssel # , damit Sie alle Nachrichten erhalten. Binden Sie dann Ihre Arbeitswarteschlangen entsprechend, sodass sie nur die Nachrichten erhalten, die in sie fließen müssen. Zum Beispiel ist es üblich, Nachrichten nach Nachrichtentyp zu leiten, wobei jede Warteschlange genau einen Nachrichtentyp enthält. Dies ist sowohl einfach als auch effektiv.
Der Vorteil eines einzelnen Themenaustauschs besteht darin, dass Sie abhängig von dem verwendeten Bindungsschlüssel die Vorteile eines direkten Austauschs und eines Fanout-Austauschs erhalten. Darüber hinaus sind Konfigurationsänderungen leicht zu erreichen und können oft durchgeführt werden, ohne jegliche Systemverarbeitung zu stören (sagen wir, dass Sie die Verfolgung bestimmter Nachrichten stoppen möchten - dies kann problemlos mit einem Themenaustausch durchgeführt werden, vorausgesetzt, Ihre Routing-Schlüssel sind rational) .