如果有人能够指出我对rabbitmq（在“平均”硬件，fwiw）的合理比例/限制的方向，或者将您的经验发布在其performance上，我将不胜感激。 我试图了解一下队列数量，队列用户数量，成千上万的监听者对扇出队列的性能影响，任何人都可能在高容量环境下运行兔子的硬数。
首先，您需要了解列表中的哪些项目具有可能会触及的缩放限制，哪些不可以。 其中一些是依赖于实现的，所以有助于阅读内部信息，例如RabbitMQ in Action一书。
队列数量受RAM限制。 另一方面，正在播放的消息数量不受RAM的限制，因为RabbitMQ会自动将其发送到磁盘。 有一次，当我不注意的时候，无意中在开发服务器上获得了近800万条消息。
消息大小也是没有限制的，但是如果单个消息的大小超过512K，你应该三思而行。 我结束了使用内存caching在应用程序之间传递大对象，只发送包含一个memcache键的较小的控制消息。 但如果你真的想要发送巨大的JPEG和二进制对象，如JAR文件作为消息。
用户数量是操作系统的限制，因为用户至less需要打开一个TCP套接字。 当然这在大多数操作系统中都是可调的，所以你的里程会有所不同，这就是为什么你必须testing你的模型。 我一直使用JMETER加载testing我们的Web应用程序，我刚刚发现这个AMQP插件https://github.com/jlavallee/JMeter-Rabbit-AMQP，但还没有使用它。 无论如何，这是一种能够快速告诉你硬件（或虚拟机configuration）能够合理处理的testingtypes。
你唯一困难的事情是testing大量的消费者到扇出队列。 您可能还想使用主题交换进行比较，而消费者使用通配符（*）绑定键订阅，从而达到相同的最终结果。 尝试使用尽可能多的不同机器来运行此testing，以确保您不会以某种方式陷入运行使用者进程的单个服务器所导致的瓶颈。 PS的Jmeter插件看起来像它也可能是有用的模拟消费者。
这不是一个真正可以回答的问题 – 有太多因素（“平均”硬件的移动定义，队列中消息的大小，消费者数量以及他们多久进行一次轮询/他们在消息中完成工作的速度等等） ）。 你真的需要基准你的环境。
也就是说，查看RabbitMQ性能的一些讨论（包括一些关于如何对安装进行基准testing的想法，以了解您对Rabbit的期望）：