RabbitMQ 客户端负载均衡

Question

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

我对必须使用 TCP 负载均衡器来平衡节点之间的负载这一事实感到困扰。这是正确的吗？

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

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

是否有任何(可能是第三方？)类似连接池的解决方案，以便发布者从所有节点发布内容，而消费者从所有节点消费？

Answer 1

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

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

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

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

由于flow control TCP 负载均衡器可能会带来更多麻烦，而不是其值(value)。 TCP 背压可能无法通过 LB，导致发布者的发布速度超过 RabbitMQ 的处理速度。在不科学的测试中，当 RabbitMQ 位于负载均衡器后面时，我遇到了更多与客户端直接连接时相比的稳定性问题。