RabbitMQ: Exchange, Warteschlangen und Bindungen - wer macht was?

Question

Wenn Sie RabbitMQ zum Senden von Nachrichten verwenden, haben Sie grundsätzlich Austausch, Warteschlangen und Bindungen. Ich habe ihre Idee und ihre Beziehung zueinander verstanden, aber ich bin mir nicht sicher, wer was aufbaut.

Grundsätzlich habe ich drei Szenarien in meiner Anwendung.

Szenario 1: Ein Verleger, mehr Worker-Prozesse

Was ich erreichen will, ist eine Komponente, die Nachrichten an eine Warteschlange sendet, und es wird mehrere Arbeitsprozesse sein, die Elemente in der Warteschlange verarbeiten. Das scheint mir ziemlich einfach zu sein. Der Aufbau ist wie folgt:

• Austausch: 1-Austausch mit dem Typ 'direkte'
• Queue: 1 Warteschlange
• Bindung: Die Warteschlange an die Vermittlungsstelle gebunden ist

wenn eine Nachricht ist An die Vermittlungsstelle gesendet, wird sie an die Warteschlange übermittelt, und die Worker-Prozesse erhalten ihre Aufgaben.

Alles soll haltbar sein.

Also wer richtet was ein? Meiner Meinung nach:

• Produzent schafft Austausch
• Producer Queue (wie es derzeit läuft keine Arbeitsprozesse sein können, und die Nachricht würde sonst verloren gehen, wenn es keine Warteschlange war)
• Produzent hat die Bindung der Warteschlange den Austausch
• Verbraucher hören einfach auf die Warteschlange

Recht?

Szenario 2: Ein Verlag, mehrere Teilnehmer, flüchtige Nachrichten

Das zweite Szenario ist ganz anders. Grundsätzlich ist es ein Pub/Sub-Szenario, bei dem jede Nachricht an jeden derzeit zuhörenden Client gesendet wird. Wenn ein Client offline geht, erhält er keine Nachrichten mehr und sie werden nirgendwo für ihn gespeichert. Das bedeutet, den folgenden Aufbau:

• Austausch: 1-Austausch mit dem Typ ‚Fan-Out‘
• Queue: n-Warteschlangen, einen für jeden Verbraucher
• Bindung: Jede Warteschlange muss den Vermittlungs

gebunden sein,

Also wer richtet was ein?Meiner Meinung nach:

• Produzent schafft Austausch
• Consumer Queue (wie es seine eigene Warteschlange, und der Produzent kann nicht wissen, wer auch immer in den Nachrichten interessiert ist)
• Consumer schafft für seine Warteschlange Bindung an der Austausch
• Consumer hört auf seine Warteschlange

Recht?

Szenario 3: Ein Verlag, mehrere Teilnehmer, dauerhafte Nachrichten-

Grundsätzlich entspricht Szenario 2, aber die Nachrichten nicht verloren gehen, wenn ein Verbraucher offline geht. Meiner Meinung nach sollte das nichts ändern - oder?

Answer 1

Ich denke, was Sie sagen, ist richtig außer Szenario 3.

Wenn Nachrichten nicht verloren gehen, wenn ein Verbraucher offline geht, dann müssen Sie dauerhafte Warteschlangen und die Warteschlangen nicht auto_delete'd werden können.

Alles andere scheint mir richtig.

Im Fall von Szenario 2 können Sie RabbitMQ auch automatisch Warteschlangennamen für Sie generieren lassen und diese Warteschlangen automatisch löschen lassen, sobald der Kunde die Verbindung getrennt hat.