在我们的项目中，我们希望在"任务队列"模式中使用RabbitMQ来传递数据。
在生产者端，我们构建了一些TCP服务器（在node.js中）来recv高并发数据，并将其发送到MQ，而无需执行任何操作。
在消费者端，我们使用JAVA客户端从MQ，处理它，然后确认。
所以问题是：为了获得最大的消息传递吞吐量/性能（例如，400000消息/秒），多少个队列是最好的？更多的队列是否意味着更好的吞吐量/性能？还有什么需要我注意的吗？在这种情况下使用RabbitMQ有任何已知的最佳实践指南吗？
非常感谢任何评论！！
为了在RabbitMQ中获得最佳性能，请遵循其创建者的建议。来自RabbitMQ博客：
RabbitMQ的队列为空时速度最快。当队列空，并且它让消费者准备好接收消息，然后尽快队列收到一条消息，它会直接发送到消费者在持久队列中的持久消息的情况下，它也将进入磁盘，但这是以异步方式完成的，并且缓冲很重。重点是很少记账需要完成，修改的数据结构很少几乎不需要分配额外的内存。
如果您真的想深入研究RabbitMQ队列的性能，那么他们的另一个博客条目将深入研究数据。
根据我曾经从rabbitmqdiscuss邮件组得到的回复，你可以尝试增加吞吐量和减少延迟：
使用较大的预取计数。价值太小会影响绩效。
主题交换比直接交换或扇出交换慢。
确保排队的队伍保持较短。更长的队列会带来更多的处理开销
如果您关心延迟和消息速率，请使用较小的消息。使用高效的格式（例如，避免使用XML）或压缩有效载荷。
尝试使用有助于提高性能的HiPE。
避免事务和持久性。同时避免立即发布或强制模式。避免HA。集群也会影响性能。
如果您拥有多个队列和消费者。
至少使用v2.8.1版本，该版本引入了流量控制。确保内存和磁盘空间警报永远不会触发。
虚拟化可能会带来较小的性能损失。
调整您的操作系统和网络堆栈。确保您提供的内容足够多内存提供快速内核和RAM。
您将通过更大的预取计数来提高吞吐量，同时确认来自消费者的多条消息（而不是为每条消息发送ACK）。
但是，当然，启用了多个标志的ACK(http://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.ack)在使用者应用程序上需要额外的逻辑(http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2013-August/029600.html)。您必须保留从代理传递的消息的传递标签列表、它们的状态（无论您的应用程序是否处理过它们），以及在处理完传递标签小于或等于NDTAG的所有消息时，确认第N个传递标签（NDTAG）。