RabbitMQ Spiegelung Warteschlangen und Austausch

Question

Ist es möglich, Föderationen oder Schaufeln zu verwenden, um die Erstellung von Austauschen und Warteschlangen auf einem Server zu einem anderen zu spiegeln?

Alle Beispiele, die ich bei der Verwendung von Schaufeln und Föderationen gesehen habe, verwenden Austauschknoten und Warteschlangen, die bereits auf den Servern vorhanden sind. Was ich tun möchte, ist einen Austausch auf Server A zu erstellen und eine Föderation oder Schaufel erstellen Sie es auf Server B neu und starten Sie, um Nachrichten an es zu senden.

Wenn dies mit einem Verbund oder einer Schaufel nicht möglich ist, ohne Clustering zu verwenden, ist die Verbindung zwischen den beiden Servern nicht konsistent, so dass Clustering nicht möglich ist.

Ich benutze RabbitMQ unter Windows.

Answer 1

Sie können das Föderations-Plug-In verwenden.

sie den Austausch exchange und die queue Föderation, unterstützt, um Sie die Warteschlangen und den Austausch zu spiegeln eine Richtlinien konfigurieren können (mit der Management-Konsole oder Befehlszeile), zum Beispiel mit diesem Parameter:

Name: my_policy 
Pattern: ^mirr\. <---- mirror exchanges and queues with prefix “mirr.” 
Definition: federation-upstream-set:all 

Das Muster polic: Sie können die Konfiguration für den Austausch und die Warteschlangen, wie anwenden y unterstützt reguläre Ausdruck

Auf diese Weise wird jedes neue oder alte Austausch oder Warteschlange, die mit dem Präfix beginnt „mirr.“ wird an den anderen broker gespiegelt werden.

Ich denke, das könnte Ihr Problem lösen.

Answer 2

Leider ist es auf diese Weise nicht möglich, da die Verbindung eine Punkt-zu-Punkt-Verbindung ist. Sie müssen einen Exchange mit einem Remote-Exchange verknüpfen und in Ihrer Topologie kann dies nicht automatisch erstellt werden.

Ich hatte auch dieses Problem in der Vergangenheit. Und wie ich das Problem gelöst habe, war über eine Business-Logik-Seite. Wenn ein neues Exchange/Queue "on the fly" benötigt wurde, erkannte mein Dateneingabe-Gateway dies und erstellte auf der lokalen und der Remote-Exchange den neuen Exchange und die Warteschlangen mit der Verbindung, bevor die Nachricht an RabbitMQ gesendet wurde.