Quand utiliser RabbitMQ pelles et quand Fédération plugin?
Pour l'entreprise pour laquelle je travaille, Nous aimerions utiliser RabbitMQ comme bus de message principal. L'idée que nous avons est que chaque application utilise son propre vhost pour la communication interne et que via le plugin pelle ou fédération nous permettrait de partager certains types d'événements sur plusieurs vhosts (peut-être même plusieurs machines (non-clustered)). Nous avons choisi pour l'application par vhost pour séparer la communication interne des événements publics et pour garder la sécurité réglable par application.
Sur la base des informations publiées sur le site web RabbitMQ Je ne comprends pas quand je dois choisir pour les pelles ou quand je dois choisir pour le plugin Fédération.
RabbitMQ a l'explication suivante Quand utiliser quoi:
Généralement, vous utilisez la pelle pour relier les courtiers à travers internet lorsque vous avez besoin de plus de contrôle que la Fédération fournit.
Quel est le contrôle du grain fin dans les pelles qui me manque quand je choisis pour la Fédération?
En ce moment, je pense que je préférerais le plugin federation car je pourrais automatiser la communication inter-vhost via L'API REST fournie par le plugin federation. En cas de pelles, je devrais changer la configuration de la pelle et redémarrer 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 le dans un proche avenir, les clients Java/Perl/PHP se joindront.
Pour résumer mes questions:
- Quel est le contrôle du grain fin dans les pelles que je manque quand je
choisissez pour la fédération? - est-il correct que la seule façon de changer le la communication inter-vhost lorsque j'utilise des pelles est en changeant le fichier de configuration et en redémarrant l'instance?
- Est-ce que la configuration (vhost par application) a du sens ou est-ce que je manque complètement le point?
2 réponses
Les pelles et la file d'attente fournissent des moyens différents pour 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). En outre, un échange sur le noeud aval(destination) recevra une copie des messages qui sont publiés au noeud amont.
Les échanges fédérés sont similaires aux liaisons exchange-to-exchange, en ce sens qu'ils peuvent (éventuellement) abonnez-vous à un ensemble limité de messages d'un échange en amont.
File D'Attente Fédérée (NOTE: 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 amont(source) et aval(destination).
Essentiellement, la file d'attente en aval est un consommateur sur la file d'attente en amont, avec l'espoir qu'il y aura d'autres consommateurs en aval qui traitent les messages de la même manière qu'un consommateur attaché à la file d'attente en amont.
Les messages consommés par la file d'attente aval (fédérée) ne seront pas disponibles pour les consommateurs de la file d'attente amont.
Cas D'Utilisation:
Si les consommateurs sont migrés d'un nœud à un autre, une file d'attente fédérée permettra que cela se produise sans que les 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 " distribuée 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
Pelles d'autre part, attacher une file d'attente "en amont" à un échange "en aval". (Je place les Termes entre guillemets car la documentation de pelle ne décrit pas les nœuds avec la même sémantique que la documentation de Fédération.)
La pelle consomme le messages de la file d'attente et les envoie à l'échange sur le nœud de destination. (NOTE: Bien que ce ne soit pas normalement discuté 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 du grain fin dans les pelles qui me manque quand je choisissez pour la fédération?
Une pelle n'a pas pour 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 correct que la seule façon de changer le inter-vhost-communication quand j'utilise des pelles est en changeant theconfig fichier et redémarrage de l'instance?
Cela a généralement été le accepté inconvénient 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).'
.
Est-ce que la configuration (vhost par application) a du sens ou est-ce que je manque le point complètement?
Cette décision va dépendre de votre cas d'utilisation. vhosts fournissent principalement logique (et l'accès) séparation entre les files d'attente / échanges et les utilisateurs autorisés.
Pelle agit comme un consommateur intégré bien conçu. Il peut consommer des messages d'un courtier source et d'une file d'attente, et les publier dans un courtier de destination et exchange. Vous pouvez écrire une application pour le faire, mais pelle a déjà eu raison-si tout ce dont vous avez besoin est de déplacer des messages d'une file d'attente à un échange dans le même courtier ou un autre, pelle 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 configurez-le sur la source ou sur le courtier de destination, ou même utilisez un troisième courtier. C'est essentiellement un client AMQP.
Federation , 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, 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 besoin de lier des files d'attente supplémentaires à un échange de sujet ou à l'aide d'un échange de fanout, et pelleter les messages de chaque file d'attente vers un courtier en aval.
Pour résumer, federation fonctionne à un niveau supérieur, tandis que shovel est surtout "juste" un client bien écrit.
Pour reconfigurer pelle, vous devez redémarrer le courtier, malheureusement.
Je ne pense pas que vous ayez vraiment besoin d'un serveur virtuel par application. Vous pouvez ajouter un utilisateur par application au courtier sans vhosts séparés. Je ne sais pas ce que vous voulez dire sur "partager un événement entre vhosts", cependant.