何时使用 RabbitMQ 铲子以及何时使用联邦插件? [英] When to use RabbitMQ shovels and when Federation plugin?
问题描述
对于我工作的公司，我们希望使用 RabbitMQ 作为我们的主要消息总线.我们的想法是每个应用程序都使用自己的虚拟主机进行内部通信，并且通过铲子或联合插件，我们可以在多个虚拟主机(甚至可能是多台机器(非集群))之间共享某些类型的事件.我们选择每个虚拟主机的应用程序，以将内部通信与公共事件分开，并保持每个应用程序的安全性可调.
For the company I work for we would like to use RabbitMQ as our main message bus. The idea we have is that every single application uses their own vhost for internal communication and that via the shovel or federation plugin we would make it possible to share certain type of the events across multiple vhosts (maybe even multiple machines (non-clustered)). We chose for application per vhost to separate internal communication from public events and to keep the security adjustable per application.
根据 RabbitMQ 网站上发布的信息，当我不得不选择铲子时，我不明白或者当我必须选择联邦插件时.
Based on the information published on the RabbitMQ website I don't get it when I have to choose for shovels or when I have to choose for the federation plugin.
RabbitMQ 有以下说明什么时候用什么:
RabbitMQ has the following explanation when to use what:
当您需要比联邦提供的更多控制权时，通常会使用铲子通过 Internet 链接代理.
Typically you would use the shovel to link brokers across the internet when you need more control than federation provides.
我选择联邦时缺少的铲子细粒控制是什么?
What is the fine grain control in shovels which I am missing when I choose for federation?
此时我想我更喜欢联邦插件，因为我可以通过联邦插件提供的 REST API 自动化虚拟主机间通信.在铲子的情况下，每次我们想在虚拟主机之间共享事件时，我都需要更改铲子配置并重新启动 RabbitMQ 实例.我的想法对吗?
At this moment I think I would prefer the federation plugin because I could automate the inter-vhost-communication via the REST API provided by the federation plugin. In case of shovels I would need to change the shovel configuration and reboot the RabbitMQ instance every time we would like to share an event between vhosts. Are my thoughts correct about this?
我们目前在 Windows 上运行 RMQ，客户端从 .NET 连接.在不久的将来，Java/Perl/PHP 客户端将加入.
We are currently running RMQ on Windows with clients connecting from .NET. In the near future Java/Perl/PHP clients will join.
总结一下我的问题:
- 我在使用时缺少的铲子中的细粒控制是什么
选择联邦? - 唯一的改变方法是正确的吗?我使用铲子时的虚拟主机间通信是通过更改配置文件并重新启动实例来实现的吗?
- 设置(每个应用程序的虚拟主机)是否有意义，还是我完全错过了重点?
推荐答案
铲子和队列提供了不同的方式将消息从一个 RabbitMQ 节点转发到另一个.
Shovels and queue provide different means to be forward messages from one RabbitMQ node to another.
联合交易所
使用联合交换，队列可以连接到上游(源)节点上的队列.此外，下游(目标)节点上的交换将收到发布到上游节点的消息副本.
With a federated exchange, queues can be connected to the queue on the upstream(source) node. In addition, an exchange on the downstream(destination) node will receive a copy of messages that are published to the upstream node.
联合交换类似于交换到交换的绑定，因为它们可以(可选地)订阅来自上游交换的一组有限的消息.
Federated exchanges are a similar to exchange-to-exchange bindings, in that, they can (optionally) subscribe to a limited set of messages from an upstream exchange.
联合队列(注意:这些是 RabbitMQ 3.2.x 中的新功能)
Federated Queue (NOTE: These are new in RabbitMQ 3.2.x)
使用联合队列，消费者可以连接到上游(源)和下游(目标)节点上的队列.
With a federated queue, consumers can be connected to the queue on both the upstream(source) and downstream(destination) nodes.
本质上，下游队列是上游队列的消费者，期望会有额外的下游消费者以与附加到上游队列的消费者相同的方式处理消息.
In essence the downstream queue is a consumer on the upstream queue, with the expectation that there will be additional downstream consumers that process the messages in the same manner as a consumer attached to the upstream queue.
下游(联合)队列使用的任何消息都将不可用于上游队列上的消费者.
Any messages consumed by the downstream (federated) queue will not be available for consumers on the upstream queue.
用例:
如果消费者从一个节点迁移到另一个节点，联合队列将允许这种情况发生，而不会丢失消息或处理两次.
If consumers are being migrated from one node to another, a federated queue will allow this to happen without messages being missed, or processed twice.
典型用途是分配相同的逻辑"队列超过许多经纪人.每个代理都会声明一个联合队列上游的所有其他联合队列.(链接将形成一个在 n 个队列上完成双向图.)
The typical use would be to have the same "logical" queue distributed over many brokers. Each broker would declare a federated queue with all the other federated queues upstream. (The links would form a complete bi-directional graph on n queues.)
铲子
另一方面，铲子将上游"队列附加到下游"交换.(我将这些术语放在引号中，因为 shovel 文档没有描述与联邦文档具有相同语义的节点.)
Shovels on the other hand, attach an "upstream" queue to a "downstream" exchange. (I place the terms in quotes because the shovel documentation does not describe the nodes with the same semantics as the federation documentation.)
铲子消耗队列中的消息并将它们发送到目标节点上的交换器.(注意:虽然通常不作为该模式的一部分进行讨论，但没有什么可以阻止消费者连接到源节点上的队列.)
The shovel consumes the messages from the queue and sends them to the exchange on the destination node. (NOTE: While not normally discussed as part of this the pattern, there is nothing stopping a consumer from connecting to the queue on the origin node.)
回答具体问题:
我在使用铲子时缺少的细粒控制是什么选择联邦?
What is the fine grain control in shovels which I am missing when I choose for federation?
铲子没有驻留在上游"或下游"节点上.它可以从一个独立的节点进行配置和操作.
A shovel does not have to reside on an "upstream" or "downstream" node. It can be configured and operate from an independent node.
铲子可以自己创建链接的所有元素:源队列、队列的绑定和目标交换.因此，它对源节点或目标节点都是非侵入性的.
A shovel can create all of the elements of the linkage by itself: the source queue, the bindings of the queue, and the destination exchange. Thus, it is non-invasive to either the source or destination node.
唯一的改变方法是正确的吗?我使用铲子时的虚拟主机间通信是通过更改配置文件并重启实例?
Is it correct that the only way to change the inter-vhost-communication when I use shovels is by changing theconfig file and rebooting the instance?
这通常是铲子的公认缺点.
This has generally been the accepted downside of the shovel.
使用以下命令(警告:仅在 RabbitMQ 3.1.x 上测试，并且使用仅包含的非常具体的 rabbitmq.config 文件)您可以从指定文件重新加载铲子配置.(在这种情况下 /etc/rabbitmq/rabbitmq.config)
With the following command (caveat: only tested on RabbitMQ 3.1.x, and with a very specific rabbitmq.config file that only contain ) you can reload a shovel configuration from the specified file. (in this case /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).'
.
设置(每个应用程序的虚拟主机)是否有意义或者我错过了完全指向?
Does the setup (vhost per application) make sense or am I missing the point completely?
此决定将取决于您的用例.虚拟主机主要提供队列/交换和授权用户之间的逻辑(和访问)分离.
This decision is going to depend on your use case. vhosts primarily provide logical (and access) separation between queues/exchanges and authorized users.
这篇关于何时使用 RabbitMQ 铲子以及何时使用联邦插件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
