跳到主要内容

Federation 插件预览版发布

·4 分钟阅读
Simon MacMullen

注意：这篇博文讨论了为 RabbitMQ 2.5.0 发布的 federation 插件预览版。如果您使用的是 2.6.0 或更高版本，则 federation 是主要版本的一部分；您可以像获取任何其他插件一样获取它。

又一天，又一个新的插件发布😃今天的主题是 federation。如果您想跳过这篇文章并直接下载插件，请访问此处。详细说明请参见此处。

federation 的高层次目标是在 WAN 和管理域中扩展发布/订阅消息传递。

为此，我们引入了 federation 交换机 的概念。federation 交换机的行为类似于给定类型的普通交换机（它可以模拟任何已安装交换机类型的路由逻辑），但它也知道如何连接到 上游 交换机（这些交换机本身也可能是 federation 交换机）。

绑定到 federation 交换机的队列会接收发布到上游交换机（或上游的上游）的消息，以及本地发布的消息。如果网络中断，消息将在上游排队。

那么这与集群有何不同呢？

Federation集群
Broker 在逻辑上是独立的，可能具有不同的所有者。集群构成单个逻辑 Broker。
Broker 可以运行不同版本的 RabbitMQ 和 Erlang。节点必须运行相同版本的 RabbitMQ，并且通常是 Erlang。
Broker 可以通过不可靠的 WAN 链路连接。通信通过 AMQP（可选地通过 SSL 保护）。Broker 必须通过可靠的 LAN 链路连接。通信通过 Erlang 节点间消息传递。
Broker 可以以您安排的任何拓扑结构连接。链路可以是单向或双向的。所有节点都以双向方式连接到所有其他节点。
从 CAP 定理 中选择可用性和分区容错性。从 CAP 定理中选择一致性和可用性。
Broker 中的某些交换机可能是联合的，而另一些可能是本地的。集群是全有或全无的。
连接到任何 Broker 的客户端只能看到该 Broker 中的队列。连接到任何节点的客户端都可以看到所有节点上的队列。

README 包含使事情正常工作的 详细 说明，但让我们看一个简单的示例。

假设我们有三个 Broker，london、paris 和 newyork。我们想要一个名为 stocks 的联合 topic 交换机（抱歉使用了可预测的示例...）。我们将了解如何配置 london Broker 以与 paris 和 newyork 联合。

这是 london 的简单 rabbitmq.config 文件的外观

[
  {rabbitmq_federation,
   [{exchanges, [[{exchange,     "stocks"},
                  {virtual_host, "/"},
                  {type,         "topic"},
                  {durable,      true},
                  {auto_delete,  false},
                  {internal,     false},
                  {upstream_set, "common-upstreams"}]]},
    {upstream_sets, [{"common-upstreams", [[{connection, "newyork"}],
                                           [{connection, "paris"}]]}
                    ]},
    {connections, [{"newyork", [{host, "newyork.mycompany.com"}]},
                   {"paris",   [{host, "paris.mycompany.com"}, {protocol, "amqps"},
                                {username, "my-user"}, {password, "secret"}]}
                  ]},
    {local_username, "my-user"}
   ]}
].

rabbitmq_federation 应用程序配置了多个选项。

首先，我们配置要声明的交换机。（您可以通过 AMQP 声明 federation 交换机 - 请参阅 README - 但由于它们可能需要一些协调才能设置，因此在配置文件中声明它们通常更方便）。

每个联合交换机都需要一个“上游集”的名称才能工作 - 一组要连接的上游机器 - 因此我们设置其中一个。

然后我们列出如何建立每个连接。这里有很多选项；请参阅 README。

最后，我们指定应被视为从上游 Broker 注入消息的本地用户的名称。

当我们启动 london Broker 时，我们应该在日志中看到类似这样的消息

=INFO REPORT==== 22-Jun-2011::12:16:42 ===
Federation exchange 'stocks' in vhost '/' connected to newyork.mycompany.com:5672:/:stocks

=INFO REPORT==== 22-Jun-2011::12:16:43 ===
Federation exchange 'stocks' in vhost '/' connected to paris.mycompany.com:5671:/:stocks

并且交换机现在将接收远程发布的消息。

在这种情况下，我们可能还会配置其他 Broker 以与 london 联合，但这并不是您可以执行此操作的唯一方法 - 例如，您可以将 Broker 连接到单向环中，或者在树结构中使用 Broker 进行大规模扇出。

当然，由于这是预览版，因此存在限制。最糟糕的是 federation 与集群不兼容。您不应在集群中使用 federation 插件。这是我们要修复的第一件事。

还有其他限制：您无法联合 headers 交换机。除非您重新启动 Broker，否则无法更改要联合的计算机。没有状态报告（除了写入日志的消息）。这些都将得到修复。

那么 - 这对您有用吗？您怎么看？（提示：在此处下载 此处）。请在此处的评论中或在 rabbitmq-discuss 邮件列表中告知我们。

© . All rights reserved.