Rabbitmq und alle Warteschlangen fangen

Question

In meiner Firma laufen eine Reihe von Tests auf verschiedenen Android-Geräten.

Heute werden Tests (das sind Aufgaben) in einer einzigen Warteschlange mit mehreren Arbeitern ausgeführt.

Ich möchte diese einzelne Warteschlange in mehrere Warteschlangen aufteilen, eine für jedes Gerät, um Tests zu optimieren, je nachdem wie viele X-Geräte meine Firma hat (dh wenn meine Firma 2 A-Geräte hat, möchte ich Tests auf Geräten senden A in einer Warteschlange mit einem einzelnen Worker mit --concurrency = 2, so dass ich maximal zwei Tests in Folge starten kann.

Ich möchte nicht alle auf einmal migrieren, also mache ich einen ersten Schritt zur Implementierung einer Hybrid-Version und Logik, die ich gerne implementieren würde, ist das Folgende.

Geräte A (es gibt zwei von ihnen) und B (es ist nur eine) gehen auf Warteschlange A und Warteschlange B während alle anderen in der alten Vermächtnis ein.

Mein Problem ist mit Vermächtnis Warteschlange. Wenn ich einen Test an ein Gerät C sende, was ich tue, sendet die Aufgabe an die Warteschlange C, da die Warteschlange catch_all Legacy die Aufgabe nicht erhalten wird. Ich suche einen Weg zu sagen: "bitte Rabbitmq verwenden Warteschlange Legacy, wenn ein bestehender Queue-Name nicht mit dem Gerätenamen übereinstimmt".

Es gibt einen Weg, dies zu erreichen?

Answer 1

Sie können mit einer Kombination von Alternate Austausch tun dies (https://www.rabbitmq.com/ae.html) und Bindungen mit Routing

Ihre Setup-Schlüssel würde queuea und QueueB durch Ihren Austausch gebunden haben, einen verbindlichen Schlüssel, der das Gerät darstellt.

 
| exchange| binding | queue | 
|---------|----------|--------| 
| my.ex | device.a | QueueA | 
| my.ex | device.b | QueueB | 

, wenn Sie eine Nachricht von Gerät A zu veröffentlichen, wäre es einen Routing-Schlüssel von device.a hat und zu queuea gehen würde.

Jetzt würden Sie für alle Legacy-Geräte einen alternativen Austausch für die Exchange-Konfiguration einrichten. Dies würde Nachrichten, die nicht device.a oder device.b Routing-Schlüssel entsprechen, an den alternativen Austausch liefern.

Die alternative Vermittlungsstelle würde dann alle Nachrichten an die Legacy-Warteschlange weiterleiten.