Rabbitmq-多线程应用程序应该使用单通道还是多通道
我的应用程序有多个线程将消息发布到单个RabbitMQ集群。
阅读rabbit文档：我阅读了以下内容：
对于使用多个线程/进程进行处理的应用程序，每一个线程/进程打开一个新通道，并且不在它们之间共享通道是非常常见的。
而且我明白，与其开通多个连接（昂贵）
不如开通多个通道。
但是为什么不对所有线程使用单个通道呢？
在单个通道上使用多个通道有什么好处？
共有1个答案
AMQP具有通道的概念，以便在可靠的TCP连接上提供更多的灵活性。每条消息打开一个TCP连接会非常昂贵，因此他们想到了在连接中使用逻辑channelS的想法。
对所有线程都使用通道不是一个好主意，因为如果特定线程中的任何东西发生故障，并且通道死亡，其余线程将抛出异常AlReadyClosedException。一个通道可能会因为多种原因而死亡：例如，试图声明一些已经用其他参数声明的东西，或者试图取消一个不存在的使用者，发布到一个不存在的交换，等等。
我最好的建议是有一个对象，它在局部变量中保存channel并实现ShutdownListener接口，这样每次通道发生故障时，它都能够从连接中恢复并创建一个新的通道。所以我想说，主要的好处是故障容忍度和可伸缩性，因为如果通道死了，它不会影响其余的。
-
我刚刚阅读了RabbitMQ的Java API文档，发现它非常丰富而且简单。关于如何为发布/消费设置一个简单的的示例非常容易遵循和理解。但这是一个非常简单/基本的示例，它给我留下了一个重要的问题：如何设置1+来向多个队列发布/消费？ 假设我有一个RabbitMQ服务器，上面有3个队列:、和。因此，我们需要一个来发布/使用所有3个队列，或者更有可能有3个单独的，每个通道专用于一个队列。 在此基础上，
-
我在我产品环境中发现了一个问题。 我们在一个mq集群中有6个队列，我们有200个线程的线程池（实际上会更多，因为它会在一个独立的线程池中安排一些特殊任务）来处理来自上游的请求，当处理请求时，我会发布一个消息给rabbitmq Broker。 所以我有200个线程将消息发布到这6个队列。 对于每个队列，我将创建一个AMQP连接，对于每个线程，我有一个Channel的threadlocal，这样每个线
-
问题内容： Scrapy中很少有并发设置，例如CONCURRENT_REQUESTS。这意味着Scrapy搜寻器是多线程的吗？因此，如果我运行它，将在字面上并行触发多个同时请求？我问是因为，我读过Scrapy是单线程的。 问题答案： Scrapy是单线程的，除了交互式外壳程序和一些测试之外，请参见source。 它建立在Twisted的基础上，Twisted也是单线程的，并且利用了它自己的异步并发
-
问题内容： 我正在编写一个GUI应用程序，该应用程序通过Web连接定期检索数据。由于此检索需要一段时间，因此这会导致UI在检索过程中无响应（无法拆分成较小的部分）。这就是为什么我想将Web连接外包给一个单独的工作线程。 [是的，我知道，现在我有两个问题。] 无论如何，该应用程序使用PyQt4，所以我想知道更好的选择是：使用Qt的线程还是使用Python threading模块？各自的优点/缺点是什
-
问题内容： 为了在Linux上开发高度网络密集型服务器应用程序，首选哪种架构？这个想法是，该应用通常可以在具有多个内核（虚拟或物理）的机器上运行。考虑到性能是关键标准，选择多线程应用程序还是采用多进程设计更好？我确实知道资源共享和从多个进程访问此类资源的同步是很多编程开销，但是如前所述，整体性能是关键要求，因此我们可以忽略这些事情。编程语言为C / C ++。 我听说，即使是多线程应用程序（单个进
-
我正在使用多个线程在不同的表中插入插入记录。此外，我正在使用批处理的记录插入，以提高效率。 注意：要插入的记录数以百万为单位。 我的问题是，在这种多线程环境中，我应该使用连接池吗？ 我关心的问题： 每个线程将运行相当长的时间来执行数据库操作。所以，如果我的连接池的大小是2，线程的数量是4，那么在给定的时刻只有2个线程将运行。因此，其他两个线程将会在很长一段时间内保持理想状态以获得连接，因为针对百万