Quand utiliser les pelles RabbitMQ et quand le plugin Federation?
Pour l'entreprise pour laquelle je travaille, nous aimerions utiliser RabbitMQ comme bus de messages principal. L'idée que nous avons est que chaque application utilise son propre vhost pour la communication interne et que via la pelle ou le plugin de fédération, nous pourrions partager certains types d'événements sur plusieurs vhosts (peut-être même plusieurs machines (non clusterisées)) . Nous avons choisi l'application par vhost pour séparer la communication interne des événements publics et pour maintenir la sécurité réglable par application.
Sur la base des informations publiées sur le site Web RabbitMQ , je ne l'obtiens pas lorsque je dois choisir des pelles ou lorsque je dois choisir le plugin de fédération.
RabbitMQ a ce qui suit explication quand utiliser quoi:
En règle générale, vous utiliseriez la pelle pour relier des courtiers sur Internet lorsque vous avez besoin de plus de contrôle que ne le prévoit la fédération.
Quel est le contrôle des grains fins dans les pelles qui me manque lorsque je choisis la fédération?
En ce moment, je pense que je préférerais le plugin de fédération car je pourrais automatiser la communication inter-vhost via l'API REST fournie par le plugin de fédération. Dans le cas de pelles, je devrais changer le pelle la configuration et redémarrez l'instance RabbitMQ chaque fois que nous aimerions partager un événement entre vhosts. Mes pensées sont-elles correctes à ce sujet?
Nous exécutons actuellement RMQ sur Windows avec des clients se connectant à partir de .NET. Dans un futur proche, les clients Java/Perl/PHP se joindront.
Pour résumer mes questions:
- Quel est le contrôle du grain fin dans les pelles qui me manque quand je
choisissez la fédération? - Est-il exact que la seule façon de changer la communication inter-hôte lorsque j'utilise des pelles est de changer le fichier de configuration et de redémarrer l'instance?
- La configuration (vhost par application) a-t-elle un sens ou suis-je complètement absent?
Les pelles et la file d'attente offrent différents moyens de transférer des messages d'un nœud RabbitMQ à un autre.
Échange fédéré
Avec un échange fédéré, les files d'attente peuvent être connectées à la file d'attente sur le nœud amont (source). De plus, un échange sur le nœud en aval (destination) recevra une copie des messages qui sont publiés sur le nœud en amont.
Les échanges fédérés sont similaires aux liaisons d'échange à échange, en ce sens qu'ils peuvent (facultativement) s'abonner à un ensemble limité de messages à partir d'un échange en amont.
File d'attente fédérée (REMARQUE: ce sont des nouveautés dans RabbitMQ 3.2.x)
Avec une file d'attente fédérée, les consommateurs peuvent être connectés à la file d'attente sur les nœuds en amont (source) et en aval (destination).
En substance, la file d'attente en aval est un consommateur dans la file d'attente en amont, avec l'espoir qu'il y aura des consommateurs en aval supplémentaires qui traiteront les messages de la même manière qu'un consommateur attaché à la file d'attente en amont.
Tous les messages consommés par la file d'attente en aval (fédérée) ne seront pas disponibles pour les consommateurs de la file d'attente en amont.
Cas d'utilisation:
Si les consommateurs migrent d'un nœud à un autre, une file d'attente fédérée permettra que cela se produise sans que des messages soient manqués ou traités deux fois.
Cas d'utilisation: à partir des documents RabbitMQ
L'utilisation typique serait d'avoir la même file d'attente "logique" répartie sur de nombreux courtiers. Chaque courtier déclarerait une file d'attente fédérée avec toutes les autres files d'attente fédérées en amont. (Les liens formeraient un graphique bidirectionnel complet sur n files d'attente.)
Pelle
Les pelles, d'autre part, attachent une file d'attente "en amont" à un échange "en aval". (Je place les termes entre guillemets car la documentation de la pelle ne décrit pas les nœuds avec la même sémantique que la documentation de la fédération.)
La pelle consomme les messages de la file d'attente et les envoie à l'échange sur le nœud de destination. (REMARQUE: bien que cela ne soit pas normalement abordé dans le cadre de ce modèle, rien n'empêche un consommateur de se connecter à la file d'attente sur le nœud d'origine.)
Pour répondre aux questions spécifiques:
Quel est le contrôle des grains fins dans les pelles qui me manque lorsque je choisis la fédération?
Une pelle ne doit pas avoir résider sur un nœud "amont" ou "aval". Il peut être configuré et fonctionner à partir d'un nœud indépendant.
Une pelle peut créer tous les éléments de la liaison par elle-même: la file d'attente source, les liaisons de la file d'attente et l'échange de destination. Ainsi, il est non invasif pour le nœud source ou de destination.
Est-il exact que la seule façon de changer la communication inter-hôte lorsque j'utilise des pelles est de changer le fichier de configuration et de redémarrer l'instance?
Cela a généralement été l'inconvénient accepté de la pelle.
Avec la commande suivante (mise en garde: testé uniquement sur RabbitMQ 3.1.x, et avec un fichier rabbitmq.config Très spécifique qui ne contient que), vous pouvez recharger une configuration de pelle à 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).'
.
La configuration (vhost par application) a-t-elle un sens ou suis-je complètement absent?
Cette décision dépendra de votre cas d'utilisation. Les vhosts fournissent principalement une séparation logique (et d'accès) entre les files d'attente/échanges et les utilisateurs autorisés.
Pelle agit comme un consommateur intégré bien conçu. Il peut consommer les messages d'un courtier source et d'une file d'attente, et les publier dans un courtier de destination et les échanger. Vous pouvez écrire une application pour ce faire, mais la pelle a déjà fait les choses - si tout ce dont vous avez besoin est de déplacer des messages d'une file d'attente vers un échange dans le même courtier ou un autre, shovel peut le faire pour vous. Tout comme une application qui se comporte bien, elle peut déclarer des échanges/files d'attente/liaisons, se reconnecter, changer la clé de routage, etc. Vous pouvez la configurer sur la source ou sur le courtier de destination, ou même utiliser un troisième courtier. Il s'agit essentiellement d'un client AMQP.
Fédération, d'autre part est utilisé pour connecter votre courtier à un ou plusieurs courtiers en amont, ou vous pouvez même créer des chaînes de courtiers, en pliant la topologie comme vous le souhaitez. Vous pouvez fédérer des échanges ou des files d'attente, et par exemple distribuer des messages à plusieurs courtiers sans avoir à lier des files d'attente supplémentaires à un échange de rubriques ou à l'aide d'un échange en éventail, et pelleter les messages de chaque file d'attente vers un courtier en aval.
Pour récapituler, la fédération opère à un niveau supérieur, tandis que la pelle est pour la plupart "juste" un client bien écrit.
Pour reconfigurer la pelle, vous devez malheureusement redémarrer le courtier.
Je ne pense pas que vous ayez vraiment besoin d'un vhost par application. Vous pouvez ajouter un utilisateur par application au courtier sans vhosts séparés. Je ne sais pas trop ce que vous voulez dire par "partager un événement entre vhosts".