我是一个Rabbitmq的新手(也是程序开发方面的),如果我的提问很显而易见,那么请提前原谅。我正在创建一个在队列中工作的线程之间共享的池,但我不确定在池中应该使用连接还是通道。
我知道需要使用通道来执行实际的工作,但是每个连接是否有一个通道会带来性能上的优势(对于从队列中获取更多吞吐量)?或者我最好只在应用程序中使用一个单独的连接并池化许多通道?
注:因为我正在池化资源,所以初始成本不是问题,因为我知道连接比通道更昂贵。 我更加关心的是吞吐量。
我是一个Rabbitmq的新手(也是程序开发方面的),如果我的提问很显而易见,那么请提前原谅。我正在创建一个在队列中工作的线程之间共享的池,但我不确定在池中应该使用连接还是通道。
我知道需要使用通道来执行实际的工作,但是每个连接是否有一个通道会带来性能上的优势(对于从队列中获取更多吞吐量)?或者我最好只在应用程序中使用一个单独的连接并池化许多通道?
注:因为我正在池化资源,所以初始成本不是问题,因为我知道连接比通道更昂贵。 我更加关心的是吞吐量。
尽管所有的指导原则这篇文章都建议,使用多个连接很可能不会影响性能。但并没有具体说明是讨论客户端还是服务器(rabbitmq)端。一个要点是,使用更多的连接当然会消耗更多的系统资源,如果这不成问题,并且希望拥有更高的吞吐量,则使用多个连接可能会更好,如这篇文章所示,多个连接将允许您获得更高的吞吐量。原因似乎是即使存在多个通道,在同一时间只有一个消息通过连接。因此,大型消息将阻塞整个连接,或者许多不重要的消息在同一连接但不同通道上阻塞重要消息。再次强调资源是一个问题。如果您正在使用单个连接使用所有带宽,则添加额外的连接不会比在单个连接上具有两个通道的性能提高。此外,每个连接都将使用更多内存、CPU和文件句柄,但这可能不是一个问题,尽管在扩展时可能会成为一个问题。
除了被接受的答案之外:
如果您拥有一组RabbitMQ节点,其中有一个负载均衡器或短暂的DNS(使得每次连接到不同的rabbit节点成为可能),那么单个长时间连接意味着一个应用程序节点专门与一个RabbitMQ节点配合工作。这可能导致一个RabbitMQ节点比其他节点更加繁忙。
上面提到的另一个问题是发布和消费是阻塞操作,这会导致消息排队。使用更多的连接将确保1.每条消息的处理时间不会阻塞其他消息2.大型消息不会阻塞其他消息。
这就是为什么值得考虑使用小的连接池(请记住上面提出的资源问题)
我已经通过电子邮件向 Pivotal 发送了更新其文档以解释 amq.rabbitmq.reply-to 如何在后台工作的请求,但我仍在等待回复(或更新)。无论如何,直接回复都不应该与通道共享一起使用。