3.2.0 版本中的联合队列

因此，我们在 RabbitMQ 3.2.0 中添加了对联合队列的支持。这篇博文解释了它们的作用以及如何使用它们。

（顺便说一句，如果这看起来像一堵文字墙，请见谅，我的绘画技巧不是很好。RabbitMQ 团队中更有艺术天赋的成员正在制作一些精美的图表...）

它们是用来做什么的？

队列联合背后的想法是处理跨不同 Broker 的队列的消息负载均衡。如果您有一组相互联合的队列，那么生产者可以向它们发布消息，而消费者可以从它们那里消费消息，而无需（太多）考虑位置。

因此，尽管联合交换机真正的动机是发布-订阅场景（任何地方的消费者都能够看到任何地方发布的消息），但联合队列对于工作队列场景非常有用（某个地方的消费者将能够看到任何地方发布的消息）。发布者可以在任何地方发布消息，联合机制会自动将消息移动到可以被消费的地方，但是一条消息在任何给定时间应该只在一个地方。

顺便说一句，这是一种与人们通常谈论的负载均衡不同的方法。通常，我们认为负载均衡是“在事实发生之前”——想象一下，发布者随机选择多个队列中的一个进行发布，每个队列都有一些本地消费者。这种方法的麻烦在于，如果一个队列的消费者落后或完全停止工作，那么就没有任何东西可以缓解这种情况。队列联合“在事实发生之后”进行负载均衡，将消息移动到可以处理它们的地方。

自 3.1.x 以来，联合链接的性能得到了提高（在 no-ack 模式下速度大约快两倍，在 on-confirm 模式下速度快 50%）。但是，如果可以避免移动消息，我们仍然希望避免移动消息，因此，只有当队列 B 有消费者但没有消息，并且队列 A 的消息多于其消费者可以（立即）处理的消息时，队列联合才会将消息从队列 A 移动到队列 B。队列联合的理想用户将在每个单独的队列中平衡发布和消费，从而使联合机制无事可做😃至少在某些消费者落后之前是这样...

它们不适用于什么？

既然交换机和队列都可以联合，人们很容易认为“好吧，我可以联合所有东西，然后我就拥有一个大型虚拟 Broker，就像一个集群但具有分区容错性”。当然，正如我们的老朋友 CAP 定理所暗示的那样，事情并没有那么简单；如果您获得了 (P) 分区容错性，您就必须失去其他东西，而在联合的情况下，那就是 (C) 一致性。联合队列将永远只在一个位置包含给定的消息；没有镜像。将其视为 RAID-0 而不是 HA 的 RAID-1。

当然，如果您想要 RAID-10，您可以使用联合将集群连接在一起...

那么如何联合队列呢？

这很简单！定义一个或多个上游，就像您联合交换机一样，然后定义一个与您的队列匹配的策略，并定义一个 federation-upstream-set 或 federation-upstream，同样就像您为交换机所做的那样。有关更多详细信息，请参阅文档，但实际上它的工作方式与联合交换机完全相同。