Ist RabbitMQ Clustering auch Skalierbarkeit?

Ich möchte ein RabbitMQ-System bauen, das aus Gründen der Leistung skaliert werden kann.Ist RabbitMQ Clustering auch Skalierbarkeit?

Ich bin durch das offizielle Dokument von RabbitMQ Clustering gegangen. Das Clustering scheint jedoch die Skalierbarkeit nicht zu unterstützen. Das liegt daran, dass wir nur über die Master-Warteschlange veröffentlichen/konsumieren können, obwohl die Master-Warteschlange von jedem Knoten eines Clusters aus erreichbar ist. Anders als der Knoten, auf dem sich eine Masterwarteschlange befindet, können wir Publish/Consume nicht verarbeiten.

Warum clustern wir dann?

Quelle

2016-04-21 choiapril

ich resovled dieses Problem Loadbalancer Look mit: http://stackoverflow.com/questions/36650061/how-to-make-rabbitmq-scalable/36747717#36747717 –

Warum clustern wir dann?

Um die Verfügbarkeit zu gewährleisten.
Um die Datenreplikation zu erzwingen.
Um die Last/Daten über Warteschlangen auf verschiedenen Knoten zu verteilen. Master-Warteschlangen können auf verschiedenen Knoten gespeichert und mit einem Faktor von < Clusterknoten repliziert werden.

Andere als der Knoten, auf dem eine Master-Warteschlange befindet, können wir nicht verarbeiten jede Publish/verbrauchen.

Der Client kann an jeden Knoten des Clusters angeschlossen werden. Dieser Knoten überträgt "die Anfrage" an den Master-Queue-Knoten und umgekehrt. Als Nachteil wird es zusätzlichen Hopfen erzeugen.

Quelle

2016-04-21 10:38:05

Durchsatz zu verbessern, können Originalkopien von Daten, die Logisch angenommen, dass sie sich in einer einzigen Warteschlange befinden, die über mehrere Knoten verteilt ist? Ist es das, was du sagst? Übrigens, danke für deine freundlichen Antworten. – choiapril

Sie können einen Lastenausgleich mit [föderierte Warteschlange] (https://www.rabbitmq.com/federated-queues.html) erreichen. Sie können auch den Lastausgleich auf der Client-Seite erreichen: Hersteller veröffentlichen Nachrichten an eine Börse mit einem Routing-Schlüssel-Suffix, das sich entsprechend dem Lastausgleichsfaktor dreht (zB key.0, key.1, key.0 .... für zwei Warteschlangen). Auf der Serverseite binden Sie diese beiden Warteschlangen an diesen Austausch mit den Binding-Schlüsseln 'key.0' und' key.1'. Diese Warteschlangen werden von zwei dedizierten Knoten verwaltet. Verbraucher konsumieren aus diesen 2 Warteschlangen .... –

Also, obwohl der Knoten, der eine Anfrage bearbeitet, gespiegelt wird und ein Slave ist, wird die Anfrage an eine Master-Warteschlange gerichtet, richtig? – choiapril

Antwort auf die Frage im Titel Is RabbitMQ Clustering including scalability too? - ja es tut, wird dies durch einfaches Hinzufügen weiterer Knoten/Entfernen einiger Knoten zu/aus dem Cluster erreicht. Natürlich müssen Siehohe Verfügbarkeit prüfen - das ist Warteschlange und Austausch usw.
Spiegelung und nur etwas klar in Bezug auf machen:

jedoch sein Clustering nicht Skalierbarkeit zu unterstützen scheint. Das ist , denn nur über die Master-Warteschlange können wir veröffentlichen/konsumieren, obwohl die Master-Warteschlange von jedem Knoten eines Clusters aus erreichbar ist.

Publishing erfolgt zum Austausch, Warteschlangen haben nichts mit Publishing. Ein Veröffentlichungsclient veröffentlicht nur einen Exchange- und einen Routingschlüssel. Es benötigt kein Wissen über die Warteschlange.

Quelle

2016-04-21 11:10:34 cantSleepNow

Ist RabbitMQ Clustering auch Skalierbarkeit?

Antwort

Verwandte Themen