3

据我了解，RabbitMQ 集群是为了可扩展性而不是可用性，但使用镜像队列也可以实现可用性，因为如果该主服务器出现故障，则可以将最新的从服务器提升为主服务器。

从文档中：

发布到队列的消息被复制到所有从站。无论消费者连接到哪个节点，消费者都连接到主节点，从节点丢弃已在主节点确认的消息。因此，队列镜像增强了可用性，但不会在节点之间分配负载（所有参与的节点各自完成所有工作）。

因此，给定队列的节点之间的负载平衡没有意义，因为这总是会增加从联系的节点到队列的主节点的额外行程（除非我误解了某些东西）。因此，我们希望始终能够知道哪个节点是给定队列的主节点。

我并没有真正使用过 RabbitMQ，所以也许我只是在文档中遗漏了它，但似乎没有办法确定镜像队列的 master 的 ip，如果存在 master 故障并且 slave 被提升为掌握。我看到的每个来源都只是评论一个人设置初始主节点的能力，这对我来说不是很有帮助。对于任何时间 t，我如何找到给定队列的主节点 ip？

PS：将节点简单地放在负载均衡器后面似乎也很糟糕，因为如果有一些网络分区（即使在同一个 LAN 中的节点也可能发生），那么我们可能会遇到无法与队列的主人或更糟糕的是，如果您愿意，我们可能会进化出大脑分裂。

4

2 回答 2

1

您可以创建一个维护队列镜像拓扑的智能客户端。可以使用管理插件及其REST API。

例如。对于队列，curl -i -u guest:guest http://[HOST]:[PORT]/api/queues/[VHOST]/[QUEUE]将返回以下有效负载：

{
  "messages": 0,
  "slave_nodes": [
    "rabbit@node1",
    "rabbit@node0"
  ],
  "synchronised_slave_nodes": [
    "rabbit@node0",
    "rabbit@node1"
  ],
  "recoverable_slaves": [
    "rabbit@node0"
  ],
  "state": "running",
  "name": "myQueue",
=>"node": "rabbit@node2"
}

对于 myQueue，您的客户端将倾向于连接到node2（myQueue 主节点）以最小化 HOP。

我不确定这是否值得。它将增加连接的数量和客户端的复杂性。如果您实施 somethink，我会很高兴收到反馈。

于 2016-05-10T16:29:34.183 回答
1

您不需要主节点的 IP，您只需要镜像队列，这样队列中的所有消息都在所有节点上。在上面的段落中，您引用的是这句话

每个镜像队列由一个主服务器和一个或多个从服务器组成，如果旧主服务器因任何原因消失，最旧的从服务器将被提升为新主服务器。

所以master和slave这两个词与队列有关，而不是rabbitmq节点，我猜这是混乱。一旦我阅读了问题，然后又阅读了文档，这让我思考了一段时间，但我们不能说镜像队列由 rabbitmq 节点的主节点和从节点组成；）


至于（？）集群的负载平衡，您可以这样做，以便客户端始终连接到通过使用实际负载平衡器或通过使客户端“更智能” - 即他们应该重新连接到活动的 rabbitmq 节点如果（原始）主节点出现故障，则连接到另一个节点的 IP。推荐第一种方法，只需在此处查找Connecting to Clusters from Clients 即可 。

于 2016-05-10T05:08:22.310 回答