【问题标题】:RabbitMQ client load balancingRabbitMQ 客户端负载均衡
【发布时间】:2013-05-30 08:01:50
【问题描述】:

我正在试用rabbit mq,发现它非常好。查看 HA 页面,我发现交换/队列复制运行良好。

我很困扰我必须使用 TCP 负载均衡器来平衡节点之间的负载。这是正确的吗?

我希望集群中有 2 个节点采用“全部复制”策略。

我希望发布者或消费者能够以类似循环的行为连接到所有节点。不幸的是,客户端 API 只允许为每个连接设置一个主机。

是否有任何(可能是第 3 方?)类似连接池的解决方案,以便发布者发布,消费者从所有节点消费?

【问题讨论】:

标签: rabbitmq


【解决方案1】:

我还没有看到任何为 AMQP/RabbitMQ 进行连接池的客户端。 AMQP 通过通道在单个进程中处理多个发布者/消费者,一些客户端使其易于使用,但似乎无法使用连接池处理节点的自动故障转移。

在集群中不需要连接到集群中的所有节点,消费和发布操作将在集群内正确路由。对于消耗尝试管理具有多个订阅的单个或多个进程(每个连接至少消耗一个)对我来说从来不是最高优先级。使用多个进程,每个进程随机连接到 RabbitMQ,如果其中一个 RabbitMQ 节点发生故障,您将能够保持可用性。

如果检测到故障导致的中断不到一秒,长期连接中的发布者可以轻松地重新连接,在我所做的任何工作中都足够小,不会成为问题。

从几年的使用情况来看,我会说重新连接到新主机是故障转移期间更简单的问题,而困难的问题是管理应用程序中与现有 AMQP 连接有关的状态。实际上,我只是保留了一个可用主机列表,并为每个新连接选择下一个。每当连接关闭时,只需选择一个新主机并重试。这确实意味着您无法发布的时间很短,如果您必须不断地在 PHP 中建立新的连接,可能会更加困难。

由于flow control TCP 负载平衡器可能比它们的价值更麻烦。 TCP 背压可能无法通过 LB,导致发布者发布的速度超过了 RabbitMQ 的处理速度。在不科学的测试中,当 RabbitMQ 位于负载均衡器后面时,当客户端直接连接时,我遇到了更多的稳定性问题。

【讨论】:

    【解决方案2】:

    您没有提到您使用的是哪种客户端,但是对于 Python,有出色的 Kombu 库。 Kombu 支持connection and producer pools

    您还可以使用循环、随机或自定义故障转移策略when settting up a connection 指定多个 AMQP 服务器。

    【讨论】:

      【解决方案3】:

      对于python nameko 建议的实现High Availability-Failover(Rabbitmq) 的方法是here。 Nameko设法实现这一目标作为后盾 库(kombu)支持round-robin failover

      AMQP_URI: pyamqp://guest:guest@rabbitmq1:5672/;pyamqp://guest:guest@rabbitmq2:5672/
      

      【讨论】:

        猜你喜欢
        • 2022-01-17
        • 2011-12-30
        • 1970-01-01
        • 2020-11-15
        • 2021-10-22
        • 2020-01-03
        • 1970-01-01
        相关资源
        最近更新 更多