rabbitmq中的连接池或通道之间是否存在性能差异？
如果这是明显的，我是一个Rabbitmq（和编程）的新手，所以提前抱歉。 我正在创build一个池，以便在队列上工作的线程之间共享，但我不确定是否应该在池中使用连接或通道。
我知道我需要通道去做实际的工作，但是每个连接有一个通道（从队列中获得更多的吞吐量）有什么性能好处？ 还是我最好只使用一个连接，每个应用程序和池许多渠道？
注意：因为我正在汇集资源，所以初始成本并不是一个因素，因为我知道连接比渠道更昂贵。 我对吞吐量更感兴趣。
我已经在rabbitmq网站上find了这个，所以我已经引用了下面的相关部分。
tl; dr版本是每个应用程序有1个连接，每个线程有1个通道。 希望有所帮助。
连接
AMQP连接通常是长期的。 AMQP是一个使用TCP进行可靠传输的应用程序级协议。 AMQP连接使用身份validation，并且可以使用TLS（SSL）进行保护。 当应用程序不再需要连接到AMQP代理程序时，它应该正常closuresAMQP连接，而不是突然closures底层的TCP连接。
通道
某些应用程序需要多个连接到AMQP代理。 但是，同时打开许多TCP连接是不可取的，因为这样做会占用系统资源，使得configuration防火墙变得更加困难。 AMQP 0-9-1连接与可被认为是“共享单个TCP连接的轻量级连接”的通道复用。
对于使用多个线程/进程进行处理的应用程序来说，每个线程/进程打开一个新通道并且不共享它们之间的通道是非常常见的。
特定信道上的通信与另一个信道上的通信完全分离，因此每个AMQP方法还携带一个客户端用来确定该方法用于哪个信道的通道号（例如，需要调用哪个事件处理程序） 。
build议每个线程有1个通道，即使它们是线程安全的，也可以有多个线程通过一个通道发送。 就你的应用而言，我build议你坚持每个线程1个通道。
另外build议每个频道只有1个消费者。
这些只是指导，所以你将不得不做一些testing，看看什么最适合你。
这个线程在这里和这里有一些见解。
尽pipe所有这些指导方针， 这个post表明，它将最有可能不会影响性能通过多个连接。 虽然它是不是具体是在谈论客户端还是服务器（rabbitmq）端。 有一点，它当然会使用更多的系统资源和更多的连接。 如果这不是问题，你希望有更多的吞吐量，那么可能会有更好的多连接，因为这篇文章build议多连接将允许你更多的吞吐量。 原因似乎是，即使有多个频道，一次只能有一条消息通过连接。 因此，一条较大的消息会阻塞整个连接，或者一条信道上的许多不重要的消息可能会阻塞同一连接上的重要消息，而是阻塞一条不同的信道。 资源再次是一个问题。 如果使用一个连接使用所有带宽，则添加一个额外的连接将不会增加一个连接上的两个通道的性能。 同时每个连接将使用更多的内存，CPU和文件句柄，但这可能不是一个问题，虽然可能是一个问题时，缩放。
除了接受的答案：
如果你有一个RabbitMQ节点的集群，前面有一个负载平衡器，或者是一个短暂的DNS（使得每次连接到一个不同的兔子节点成为可能），那么一个长寿命的连接就意味着一个应用程序节点只与一个RabbitMQ节点一起工作。 这可能导致一个RabbitMQ节点比其他节点使用更多。
上面提到的另一个问题是发布和消费是阻塞操作，这导致排队消息。 有更多的连接将确保1.每个消息的处理时间不会阻止其他消息2.大消息不会阻止其他消息。
这就是为什么值得考虑有一个小的连接池（考虑到上面提出的资源问题）
“每个线程一个通道” 可能是一个安全的假设（我可能说，因为我没有自己做任何研究，我没有理由怀疑文档:)），但要注意有一个情况下，这个断裂：
如果您使用RPC与RabbitMQ Direct直接回复，则不能重复使用同一个通道来消耗另一个 RPC请求。 我在google用户组中询问了有关这方面的细节，我从Michael Klishin（似乎积极参与RabbitMQ开发）得到的答案是
直接回复并不意味着与渠道共享使用任何方式。
我已经通过电子邮件发送Pivotal更新他们的文档，以解释如何 amq.rabbitmq.reply-to正在引擎盖下，我还在等待答案（或更新）。
所以，如果你想坚持“每个线程一个频道”，因为直接回复将无法正常工作。
