8 跨越集群的界限

概述

RabbitMQ 可以通过 3 种方式实现分布式部署：集群、Federation 和 Shovel。这 3 种方式不是互斥的，可以根据需要选择其中的一种或者以几种方式的组合来达到分布式部署的目的。 Federation 和 Shovel 可以为 RabbitMQ 的分布式部署提供更高的灵活性，但同时也提高了部署的复杂性。

Federation

 Federation （联邦）插件的设计目标是使 RabbitMQ 在不同的 Broker 节点之间进行消息传递而无须建立集群，该功能在很多场景下都非常有用：

• Federation 插件能够在不同管理域（可能设置了不同的用户和 vhost，也可能运行在不同版本的 RabbitMQ 和 Erlang 上）中的 Broker 或者集群之间传递消息。
• Fedaration 插件基于 AMQP 0-9-1 协议在不同的 Broker 之间进行通信，并设计成能够容忍不稳定的网络连接情况，
• 一个 Broker 节点中可以同时存在联邦交换器（或队列）或者本地交换器（或队列），只需要对特定的交换器（或队列）创建 Federation 连接（Federation link）。
• Fedaration 不需要在 N 个 Broker 节点之间创建 O(N^2)个连接（尽管这是最简单的使用方式），这也就意味着 Federation 在使用时更容易扩展。

  Federation 插件可以让多个交换器或者多个队列进行联邦。一个联邦交换器（federated exchange）或者一个联邦队列（federated queue）接收上有（upstream）的消息，这里的上游是指位于其他 Broker 上的交换器或者队列。联邦交换器能够将原本发送给上有交换器（upstream exchange）的消息路由到本地的某个队列中；联邦队列则允许一个本地消费者接收到来自上游队列（upstream queue）的消息。

联邦交换器

• [RabbitMQ分布式] (https://blog.csdn.net/wind_cp/article/details/106267468)

 可参考如上文献。
 一些杂七杂八记录的笔记要点如下：

• 应用场景  解决网络异地访问的延迟高问题、网络异地容灾。
• 建立 Federation link 的结构，具体可见文献的图，注意下：这些操作是内部的，对外部客户端来说是无感知的。
• 异地均摊消费。
• 默认的交换器和内部减缓其不能使用 Federation 的功能。
• 更复杂的拓扑逻辑部署方式。
• 转发一次限制。

联邦队列

• [RabbitMQ分布式] (https://blog.csdn.net/wind_cp/article/details/106267468)

 可参考如上文献。
 一些杂七杂八记录的笔记要点如下：

• 联邦队列的定义和作用。
• upstream（上游队列） 和 downstream（本地队列） 。
• 分担消费，也达到了负载均衡的效果。
• 多余的消费能力，一条消息可以在联邦队列间转发无限次。
• 对于dederated queue 只能使用 Basic.Consume 进行消费，不能使用异步的 Basic.Get消费。
• federated queue 并不具备传递性。

Federation 的使用

• [RabbitMQ分布式] (https://blog.csdn.net/wind_cp/article/details/106267468)

 可参考如上文献。
 具体略，这一块都是配置插件和相关的参数，不需要写代码实现逻辑。

Shovel

 与 Federation 具备的数据转发功能类似,Shovel 能够可靠、持续地从一个 Broker 中的队列（作为源端，即 source）拉取数据并转发至另一个 Broker 中的交换器（作为目的地，即 destination）。作为源端的队列和作为目的地的交换器可以同时位于同一个 Broker 上，也可以位于不同的 Broker 上。Shovel 可以翻译为“铲子”，是一种比较形象的比喻，这个“铲子”可以将消息从一方“挖到”另一方。Shovel的行为就像优秀的客户端应用程序能够负责连接源和目的端、负责消息的读写及负责连接失败问题的处理。
 Shovel 的主要优势在于：

• 松耦合。Shovel 可以移动位于不同管理域中的 Broker（或者集群）上的消息，这些 Broker（或者集群）可以包含不同的用户和 vhost，也可以使用不同的 RabbitMQ 和 Erlang 版本。
• 支持广域网。Shovel 插件同样基于 AMQP 协议在 Broker 之间进行通信，被设计成可以容忍时断时续的连通情形，并且能够保证消息的可靠性。
• 高度定制。当 Shovel 成功连接后，可以对其进行配置以执行相关的 AMQP 命令。

Shovel 的原理

• [RabbitMQ分布式] (https://blog.csdn.net/wind_cp/article/details/106267468)

 可参考如上文献。
 一些杂七杂八记录的笔记要点如下：

• Shovel 的结构。
• 通常情况下，使用 Shovel 时配置队列作为源端，交换器作为目的端，同样可以将交换器配置为源端，队列配置为目的端。
• Shovel 源端和目的端不一定需要在 Shovel link 建立之前创建。

Shovel 的使用

• [RabbitMQ分布式] (https://blog.csdn.net/wind_cp/article/details/106267468)

 可参考如上文献。  具体略，这一块都是配置插件和相关的参数，不需要写代码实现逻辑。  一些杂七杂八记录的笔记要点如下：

• 消息堆积可能会引起内存或者磁盘告警而造成所有 Connection 阻塞。
• 消息堆积严重时的处理办法。  可以选择清空队列，或者采用空消费程序丢弃掉部分消息。这种方案不适用重要的数据。
   另一种方案是增加下游消费者的消费能力。
   使用 Shovel。可以通过 Shovel 将队列中的消息移交给另一个集群。

案例：消息堆积的治理

• [RabbitMQ分布式] (https://blog.csdn.net/wind_cp/article/details/106267468)

 可参考如上文献。

参考文献

• [RabbitMQ分布式] (https://blog.csdn.net/wind_cp/article/details/106267468)
• [RabbitMQ实战指南]