Lors de l'utilisation de RabbitMQ pelles et quand Fédération plugin?

De pelles et de file d'attente fournir différents moyens à transférer des messages de l'un RabbitMQ nœud à un autre.

Fédérés De Change

Avec un fédéré de change, les files d'attente peuvent être connectés à la file d'attente sur l'amont(source) nœud. En outre, un échange sur l'aval(destination) nœud de recevoir une copie des messages qui sont publiés à l'amont du nœud.

Fédéré les échanges sont un analogue de l'échange-à-échange des liaisons, en cela, il peut (éventuellement) s'abonner à un ensemble limité de messages à partir d'un en amont de l'échange.

Fédéré File D'Attente
(NOTE: ce sont de nouveaux en RabbitMQ 3.2.x)

Avec un fédéré de la file d'attente, les consommateurs peuvent être connectés à la file d'attente sur l'amont(source) et en aval(destination) nœuds.

Dans l'essence de l'aval de la file d'attente est un consommateur sur l'amont de la file d'attente, avec l'espoir qu'il y aura être d'autres les consommateurs en aval de ce processus que les messages de la même manière en tant que consommateur attaché à l'amont de la file d'attente.

Tous les messages consommée par l'aval (fédérés) de la file d'attente ne sera pas disponible pour les consommateurs en amont de la file d'attente.

Cas D'Utilisation:

Si les consommateurs sont en cours de migration à partir d'un nœud à un autre, un fédéré file d'attente va permettre que cela arrive sans messages manqués, ou traité deux fois.

Cas D'Utilisation: à partir de la RabbitMQ docs

L'utilisation typique serait d'avoir la même "logique" de la file d'attente distribués
sur de nombreux courtiers. Chaque courtier doit déclarer un fédéré file d'attente avec
tous les autres fédéré les files d'attente en amont. (Les liens forment un
complet bi-directionnelle, graphique n files d'attente.)

Pelle

Pelles d'autre part, fixer un "en amont" de la file d'attente pour un "en aval" de l'échange. (Je place les termes entre guillemets parce que la pelle de la documentation ne permet pas de décrire les nœuds avec la même sémantique que la fédération de la documentation.)

La pelle consomme les messages de la file d'attente et les envoie à l'échange sur le nœud de destination. (NOTE: bien que pas normalement examinées dans le cadre de ce le patron, il n'en est rien, l'arrêt d'une consommation à partir de la connexion à la file d'attente sur le nœud origine.)

Les réponses aux questions:

Ce qui est de la fine grain de contrôle dans les pelles qui me manque quand je
choisissez pour la fédération?

Une pelle n'a pas ont à résider sur une "en amont" ou "en aval" nœud. Il peut être configuré et fonctionnent à partir d'un noeud indépendant.

Une pelle pouvez créer tous les éléments de la liaison par lui-même: la source de la file d'attente, les liaisons de la file d'attente, et la destination de l'échange. Ainsi, il est non-invasive à la source ou la destination du nœud.

Est-il exact que la seule façon de changer la
inter-vhost-communication lorsque j'utilise des pelles est de changer theconfig
fichier et le redémarrage de l'instance?

Cela a généralement été accepté à la baisse de la pelle.

Avec la commande suivante (attention: uniquement testé sur RabbitMQ 3.1.x, et avec une très spécifiques rabbitmq.config fichier qui contiennent uniquement ) vous pouvez recharger une pelle de configuration à partir du fichier spécifié. (dans ce cas /etc/rabbitmq/rabbitmq.config)

rabbitmqctl eval 'application:stop(rabbitmq_shovel), {ok, [[{rabbit, _}|[{rabbitmq_shovel, [{shovels, Shovels}] }]]]} = file:consult("/etc/rabbitmq/rabbitmq.config"), application:set_env(rabbitmq_shovel, shovels, Shovels), application:start(rabbitmq_shovel).'

.

Le programme d'installation (vhost par application), un sens ou j'ai loupé l'
point complètement?

Cette décision va dépendre de votre cas d'utilisation. vhosts principalement à fournir de logique (et de l'accès) la séparation entre les files d'attente/les échanges et les utilisateurs autorisés.