Ich werte gerade Nachrichtenwarteschlangen-Systeme aus und RabbitMq scheint ein guter Kandidat zu sein, also grabe ich etwas mehr hinein.
Um ein wenig Kontext zu geben, suche ich nach etwas wie einem Austausch, der die Nachrichtenveröffentlichung auf mehrere Warteschlangen verteilt. Ich möchte die Nachrichten nicht replizieren, daher ist ein Fanout-Austausch keine Option.
Auch der Grund, warum ich über mehrere Warteschlangen im Vergleich zu einer Warteschlange nachdenke, die das Round-Robin mit den Konsumenten behandelt, ist, dass ich nicht möchte, dass unser einzelner Fehlerpunkt auf der Warteschlangenebene liegt.
Klingt so, als könnte ich auf der Publisher-Seite etwas Logik hinzufügen, um dieses Verhalten zu simulieren, indem ich den Routing-Schlüssel bearbeite und die entsprechenden Bindungen an Ort und Stelle habe. Aber das ist eine Art passiver Ansatz, bei dem der Nachrichtenverbrauch in jeder Warteschlange nicht berücksichtigt wird, was möglicherweise dazu führt, dass eine Warteschlange aufgefüllt wird, wenn die Verbraucheranwendungen für diese Warteschlange inaktiv sind.
Ich suchte nach einem proaktiveren Weg von der Exchange-Entity-Seite, die entscheiden würde, wohin die nächste Nachricht basierend auf jeder Warteschlangengröße oder etwas dieser Art gesendet werden soll.
Ich habe über Alice und die verfügbaren RESTful-APIs gelesen, aber das scheint eine schwere Lösung zu sein, um schnelle Routing-Entscheidungen zu implementieren.
Wer weiß, ob Round-Robin zwischen dem Austausch der Warteschlangen within RabbitMQ dann machbar ist? Danke.
Austauschvorgänge sind im AMQP-Modell im Allgemeinen zustandslos, obwohl es kürzlich einige Experimente im Stateful-Exchange gab, da es jetzt ein System zum Verwalten von RabbitMQ-Plugins und zum Bereitstellen neuer experimenteller Austauschtypen gibt.
Es gibt nichts, was Sie wirklich wollen, denke ich nicht, obwohl ich nicht ganz sicher bin, ob ich die Anforderung verstehe. Könnte es sein, dass eine einzige Queue mit Arbeitern, die von ihr lesen, neben dem Punkt mit dem einzigen Fehlerpunkt Ihr Problem löst? Wenn dies der Fall ist, reduziert sich Ihr Problem auf die Konfiguration von RabbitMQ in einer HA-Konfiguration, die Ihnen die Verwendung dieser Lösung ermöglicht. Dazu gibt es mehrere Möglichkeiten: Entweder verwenden Sie HALinux und einen gemeinsamen Speicher, um aktive / passive HA mit schnellem Failover zu erhalten, oder richten Sie mehr als einen parallelen Broker ein und deduplizieren Sie sie auf dem Client, vielleicht mit redis oder ähnlichem.
Ich schlage vor, dass Sie Ihre Frage erneut in der Mailingliste rabbitmq-discuss stellen, wo mehr Leute Vorschläge machen können und wo die Diskussion für die Nachwelt archiviert werden kann.
Eine Möglichkeit, um den Austausch von Formularen für Warteschlangen, aber nicht für Round Robin, zu nutzen, ist Consistent Hashing. rabbitmq_consistent_hash_exchange
Wie auch Ссылка
Papier zur Erklärung, es legt Warteschlangen in einer gewichteten Verteilung auf einem Kreis und dann durch Senden zufälliger Routing-Schlüssel wird es an die nächste Warteschlange senden. Ссылка
Tags und Links rabbitmq message-queue messaging