我是Rabbitmq（和编程）的新手，所以如果这是显而易见的，我提前表示歉意。我正在创建一个池来在队列上工作的线程之间共享，但我不确定是否应该使用池中的连接或通道。我知道我需要通道来完成实际工作，但每个连接一个通道是否会带来性能优势（就队列的吞吐量而言）？或者我最好只使用每个应用程序一个连接并池化许多通道？注意：因为我是在共享资源，所以初始成本不是一个因素，因为我知道连接比通道更昂贵。2我对吞吐量更感兴趣。
cuxqih211#
我在rabbitmq website上发现了这一点，它靠近底部，所以我在下面引用了相关部分。dr版本是每个应用程序应该有1个连接，每个线程应该有1个通道。连接AMQP连接通常是长期的。AMQP是一种应用程序级别协议，使用TCP进行可靠的传送。AMQP连接使用验证，并且可以使用TLS（SSL）进行保护。当应用程序不再需要连接到AMQP代理时，它应该正常关闭AMQP连接，而不是突然关闭基础TCP连接。渠道一些应用程序需要多个连接到AMQP代理。但是，不希望同时保持多个TCP连接打开，因为这样做会消耗系统资源，并使配置防火墙变得更加困难。AMQP 0-9-1连接与可被视为“共享单个TCP连接的轻量级连接”的通道复用。对于使用多个线程/进程进行处理的应用程序，每个线程/进程打开一个新通道，并且不在它们之间共享通道是非常常见的。特定通道上的通信与另一个通道上的通信完全分离，因此每个AMQP方法还携带一个通道号，客户端使用该通道号来确定该方法用于哪个通道（例如，需要调用哪个事件处理程序）。建议每个线程有一个通道，即使它们是线程安全的，所以你可以有多个线程通过一个通道发送。就你的应用程序而言，我建议你坚持每个线程有一个通道。此外，建议每个通道只有1个消费者。这些只是指导方针，所以你将不得不做一些测试，看看什么对你最有效。这个线程有一些见解here和here。尽管有这些指导方针，this post建议多个连接最有可能不会影响性能，尽管它没有具体说明是客户端还是服务器端（rabbitmq）方面。有一点，它当然会使用更多的系统资源与更多的连接。如果这不是一个问题，并且您希望有更大的吞吐量，那么拥有多个连接可能确实更好，因为this post建议多个连接将允许您有更大的吞吐量。原因似乎是，即使有多个通道，一次也只有一条消息通过连接。因此，一条大消息将阻塞整个连接，或者一个通道上的许多不重要的消息可能阻塞同一连接但不同通道上的重要消息。资源再次成为一个问题。如果你用一个连接耗尽了所有的带宽，那么添加一个额外的连接并不会比在一个连接上有两个通道更能提高性能。而且每个连接都会使用更多的内存，cpu和文件句柄。但这可能不是问题，尽管在缩放时可能是问题。
wb1gzix02#
除了已接受的答案外：如果您有一个RabbitMQ节点集群，前面有一个负载均衡器，或者有一个短期DNS（允许每次连接到不同的RabbitMQ节点），那么一个长期连接意味着一个应用程序节点只与一个RabbitMQ节点一起工作，这可能导致一个RabbitMQ节点比其他节点的使用率更高。上面提到的另一个问题是发布和使用会阻塞操作，这会导致消息排队。拥有更多的连接将确保1.每个消息的处理时间不会阻塞其他消息2.大消息不会阻塞其他消息。这就是为什么值得考虑使用一个小型连接池的原因（记住上面提到的资源问题）
4sup72z83#
“每个线程一个通道”* 可能 * 是一个安全的假设（我说可能是因为我自己没有做任何研究，我没有理由怀疑文档：）），但要注意，有一种情况下，这打破了：如果你在RabbitMQ Direct reply-to中使用RPC，那么你就不能重用 * 同一个 * 通道来消费 * 另一个 * RPC请求。我在谷歌用户组中询问了关于这个问题的细节，我从Michael Klishin（他似乎积极参与了RabbitMQ的开发）那里得到的回答是直接回复并不意味着与通道共享一起使用。我已经给Pivotal发了电子邮件，要求更新他们的文档，以解释 * amq.rabbitmq.reply-to是如何在引擎盖下工作的，我仍在等待答复（或更新）。因此，如果你想坚持“每个线程一个通道”小心，因为这将不会工作良好的直接回复。
amq.rabbitmq.reply-to
3条答案
按热度按时间cuxqih211#
我在rabbitmq website上发现了这一点，它靠近底部，所以我在下面引用了相关部分。
dr版本是每个应用程序应该有1个连接，每个线程应该有1个通道。
连接
AMQP连接通常是长期的。AMQP是一种应用程序级别协议，使用TCP进行可靠的传送。AMQP连接使用验证，并且可以使用TLS（SSL）进行保护。当应用程序不再需要连接到AMQP代理时，它应该正常关闭AMQP连接，而不是突然关闭基础TCP连接。
渠道
一些应用程序需要多个连接到AMQP代理。但是，不希望同时保持多个TCP连接打开，因为这样做会消耗系统资源，并使配置防火墙变得更加困难。AMQP 0-9-1连接与可被视为“共享单个TCP连接的轻量级连接”的通道复用。
对于使用多个线程/进程进行处理的应用程序，每个线程/进程打开一个新通道，并且不在它们之间共享通道是非常常见的。
特定通道上的通信与另一个通道上的通信完全分离，因此每个AMQP方法还携带一个通道号，客户端使用该通道号来确定该方法用于哪个通道（例如，需要调用哪个事件处理程序）。
建议每个线程有一个通道，即使它们是线程安全的，所以你可以有多个线程通过一个通道发送。就你的应用程序而言，我建议你坚持每个线程有一个通道。
此外，建议每个通道只有1个消费者。
这些只是指导方针，所以你将不得不做一些测试，看看什么对你最有效。
这个线程有一些见解here和here。
尽管有这些指导方针，this post建议多个连接最有可能不会影响性能，尽管它没有具体说明是客户端还是服务器端（rabbitmq）方面。有一点，它当然会使用更多的系统资源与更多的连接。如果这不是一个问题，并且您希望有更大的吞吐量，那么拥有多个连接可能确实更好，因为this post建议多个连接将允许您有更大的吞吐量。原因似乎是，即使有多个通道，一次也只有一条消息通过连接。因此，一条大消息将阻塞整个连接，或者一个通道上的许多不重要的消息可能阻塞同一连接但不同通道上的重要消息。资源再次成为一个问题。如果你用一个连接耗尽了所有的带宽，那么添加一个额外的连接并不会比在一个连接上有两个通道更能提高性能。而且每个连接都会使用更多的内存，cpu和文件句柄。但这可能不是问题，尽管在缩放时可能是问题。
wb1gzix02#
除了已接受的答案外：
如果您有一个RabbitMQ节点集群，前面有一个负载均衡器，或者有一个短期DNS（允许每次连接到不同的RabbitMQ节点），那么一个长期连接意味着一个应用程序节点只与一个RabbitMQ节点一起工作，这可能导致一个RabbitMQ节点比其他节点的使用率更高。
上面提到的另一个问题是发布和使用会阻塞操作，这会导致消息排队。拥有更多的连接将确保1.每个消息的处理时间不会阻塞其他消息2.大消息不会阻塞其他消息。
这就是为什么值得考虑使用一个小型连接池的原因（记住上面提到的资源问题）
4sup72z83#
“每个线程一个通道”* 可能 * 是一个安全的假设（我说可能是因为我自己没有做任何研究，我没有理由怀疑文档：）），但要注意，有一种情况下，这打破了：
如果你在RabbitMQ Direct reply-to中使用RPC，那么你就不能重用 * 同一个 * 通道来消费 * 另一个 * RPC请求。我在谷歌用户组中询问了关于这个问题的细节，我从Michael Klishin（他似乎积极参与了RabbitMQ的开发）那里得到的回答是
直接回复并不意味着与通道共享一起使用。
我已经给Pivotal发了电子邮件，要求更新他们的文档，以解释 *
amq.rabbitmq.reply-to是如何在引擎盖下工作的，我仍在等待答复（或更新）。因此，如果你想坚持“每个线程一个通道”小心，因为这将不会工作良好的直接回复。