问题描述
我正在试用兔子 mq 并发现它非常好.查看 HA 页面，我发现交换/队列复制运行良好.
I am piloting rabbit mq and find it quite good. Looking at the HA page I find that the exchange/queue replication works well.
我必须使用 TCP Loadbalancer 来平衡节点之间的负载这一事实让我感到困扰.这是正确的吗?
I am troubled by the fact that I must use a TCP Loadbalancer to balance the load between nodes. Is this correct?
我想在一个集群中有 2 个节点，并采用全部复制"策略.
I would like to have 2 nodes in a cluster with a "replicate-all" policy.
我希望发布者或消费者能够以类似循环的行为连接到所有节点.不幸的是，客户端 API 只允许为每个连接设置一台主机.
I would like and publisher or consumer to be able to connect to all nodes in a round-robin like behavior. Unfortunately the client API only allows setting one host per connection.
是否有任何(可能是第 3 方?)连接池之类的解决方案，以便发布者从所有节点发布信息，消费者从所有节点消费?
Is there any (3rd party maybe?) connection-pool like solution so a publisher publishes and a consumers consumes from all nodes?
推荐答案
我还没有看到任何客户端为 AMQP/RabbitMQ 做连接池.AMQP 在具有通道的单个进程中处理多个发布者/消费者，并且一些客户端使其易于使用，但似乎没有使用连接池处理节点的自动故障转移.
I haven't seen any clients that do connection pooling for AMQP/RabbitMQ. AMQP handles multiple publishers/consumers in a single process with channels and some clients make that easy to use but don't seem to handle automated failover of nodes using a connection pool.
在集群中不需要连接到集群中的所有节点，消费和发布操作将在集群内正确路由.对于尝试管理具有多个订阅的单个或多个进程(每个连接至少一个消耗)的消耗对我来说从来都不是最高优先级.由于多个进程消耗，每个进程随机连接到 RabbitMQ，如果其中一个 RabbitMQ 节点出现故障，您将能够保持可用性.
In a cluster there is no need to connect to all nodes in the cluster, consume and publish operations will be correctly routed within the cluster. For consuming trying to manage either single or multiple processes with multiple subscriptions (at least one consume for each connection) has never been the highest priority for me. With multiple processes consuming, each randomly connecting to RabbitMQ, you will be able to maintain availability should one of the RabbitMQ nodes fail.
如果检测到故障导致不到一秒的中断，长期连接中的发布者很容易重新连接，在我所做的任何事情中都足够小，不会出现问题.
Publishers in long-lived connections are easily able to reconnect if a failure is detected causing less than a second of disruption, small enough in anything I've worked on to not be a problem.
从几年的使用来看，我会说在故障转移期间重新连接到新主机是更简单的问题，困难的问题是管理应用程序中与现有 AMQP 连接相关的状态.实际上，我只是保留了一个可用主机列表，并为每个新连接选择下一个.任何时候连接关闭只需选择一个新主机并重试.这确实意味着在短时间内无法发布，如果您必须不断地在 PHP 中建立新连接，则可能会更加困难.
From a few years of usage I would say that reconnecting to a new host is the simpler problem during a failover with the difficult problem being managing the state within your application in regards to existing AMQP connections. In practice I've just kept a list of the hosts available and pick the next one for each new connection. Any time the connection closes just pick a new host and try again. It does mean a short time where you cannot publish and may be more difficult if you have to constantly make new connections in PHP.
由于 流量控制，TCP 负载平衡器可能会比它们的价值更麻烦.TCP 背压可能无法通过 LB，导致发布者的发布速度超过 RabbitMQ 的处理速度.在不科学的测试中，当 RabbitMQ 在负载均衡器后面时，当客户端直接连接时，我遇到了更多的稳定性问题.
Due to flow control TCP load balancers may be more trouble then they are worth. The TCP back pressure may not make it through the LB causing publishers to publish faster than RabbitMQ can handle. In unscientific tests I've had more issues with RabbitMQ stability when it was behind a load balancer then when clients connected directly.
这篇关于RabbitMQ 客户端负载均衡的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！