benchmarking - RabbitMQ 消息消费者停止消费消息

Question

我们的团队在 ActiveMQ 或 RabbitMQ 之间进行选择。我们制作了 2 个小的生产者/消费者尖峰，发送带有 16 个字符串、一个时间戳和 2 个整数的数组的对象消息。我们的开发机器上的尖峰是正常的(消息被很好地消耗)。

然后是长凳。我们首先注意到，有时在我们的机器上，当我们发送大量消息时，消费者有时会挂起。它在那里，但消息在队列中累积。

当我们上台时:

2 个 rabbitmq 机器的集群 4 核/3.2Ghz，4Gb RAM，由 VIP

负载平衡

1 到 6 个消费者在 rabbitmq 机器上运行，将消息保存在 mysql 数据库中(数据库的机器类型相同)

12 个生产者在 12 台 AS 机器(tomcat)上运行，被另一台机器上运行的 jmeter 攻击。在产生相同负载的 RabbitMQ 消息的 servlet 上，负载约为每秒 600 到 700 个 http 请求。

我们注意到，有时消费者会挂起(好吧，他们没有被阻止，但他们不再消费消息)。我们可以看到，因为每个消费者在数据库中保存了大约 100 msg/sec，所以当一个消费者停止消费时，DB 中每秒保存的整体消息以相同的比例下降(如果假设 3 个消费者停止，我们下降大约 600 msg/sec 到 300 msg/sec)。

在那段时间里，生产者没问题，仍然以 jmeter 速率(大约 600 msg/秒)生产。消息在队列中并由仍然“活着”的消费者获取。

我们先用生产者加载所有的servlet，然后一个一个地启动所有的消费者，检查连接是否正常，然后运行jmeter。

我们正在向一个直接交易所发送消息。所有消费者都在收听一个绑定(bind)到交换的持久队列。

这一点对我们的选择很重要。你用 rabbitmq 看到过这个，你知道发生了什么吗？

谢谢您的回答。

Answer 1

它总是值得的
使用 basic.consume 时设置预取计数:

channel.basicQos(100);

在 channel.basicConsume 行之前，以确保您永远不会有
超过 100 条消息在您的 QueueingConsumer 中排队。