Shovel 和队列提供了将消息从一个 RabbitMQ 节点转发到另一个节点的不同方法。
联合交易所
通过联合交换，队列可以连接到上游（源）节点上的队列。此外，下游（目标）节点上的交换将接收发布到上游节点的消息的副本。
联合交换类似于交换到交换的绑定，因为它们可以（可选）从上游交换订阅一组有限的消息。
联合队列（注意：这些是 RabbitMQ 3.2.x 中的新增功能）
通过联合队列，消费者可以连接到上游（源）和下游（目标）节点上的队列。
本质上，下游队列是上游队列上的消费者，期望会有额外的下游消费者以与附加到上游队列的消费者相同的方式处理消息。
下游（联合）队列消耗的任何消息将不可用于上游队列上的消费者。
使用案例：
如果消费者从一个节点迁移到另一个节点，联合队列将允许这种情况发生，而不会丢失消息或处理两次。
使用案例：来自 RabbitMQ 文档 http://www.rabbitmq.com/federated-queues.html
典型的用途是分布相同的“逻辑”队列
超过许多经纪人。每个代理将声明一个联合队列
上游的所有其他联合队列。 （这些链接将形成一个
n 个队列上的完整双向图。）
Shovel
另一方面，铲子将“上游”队列附加到“下游”交换。 （我将这些术语放在引号中，因为 shovel 文档没有描述与联合文档具有相同语义的节点。）
铲子消耗队列中的消息并将它们发送到目标节点上的交换器。 （注意：虽然通常不作为该模式的一部分进行讨论，但没有什么可以阻止消费者连接到源节点上的队列。）
回答具体问题：
当我使用铲子时，我所缺少的细粒度控制是什么？
选择联邦？
铲子不会have驻留在“上游”或“下游”节点上。它可以从独立节点进行配置和操作。
shovel 可以自行创建链接的所有元素：源队列、队列的绑定和目标交换。因此，它对于源节点或目标节点都是非侵入性的。
当我使用 shovels 时更改虚拟主机间通信的唯一方法是更改配置文件并重新启动实例，这是否正确？
这通常是铲子公认的缺点。
使用以下命令（警告：仅在 RabbitMQ 3.1.x 上测试，并且具有非常具体的rabbitmq.config仅包含 ) 的文件，您可以从指定文件重新加载铲子配置。 （在这种情况下/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).'
.
设置（每个应用程序的虚拟主机）是否有意义或者我错过了
点完全？
这个决定将取决于您的用例。虚拟主机主要提供队列/交换器和授权用户之间的逻辑（和访问）分离。
