RabbitMQ消息消费者停止消费消息
我们的团队正急于在 ActiveMQ 或 RabbitMQ 之间进行选择。我们制作了 2 个小生产者/消费者峰值，发送一条包含 16 个字符串数组、一个时间戳和 2 个整数的对象消息。在我们的开发机器上，峰值正常（消息被很好地消耗）。
然后是长凳。我们首先注意到，有时在我们的机器上，当我们发送大量消息时，消费者有时会挂起。它在那里，但消息在队列中堆积。
当我们进入实验平台时：
- 2台rabbitmq机器的集群，4核/3.2Ghz，4Gb RAM，由
- 运行在rabbitmq机器上的VIP 1到6个消费者进行负载平衡，将消息保存在mysql数据库中（相同类型的机器） DB）
- 在12台AS机器（tomcat）上运行的12个生产者，受到在另一台机器上运行的jmeter的攻击。在生成相同 RabbitMQ 消息负载的 servlet 上，负载约为每秒 600 到 700 个 http 请求。
我们注意到有时消费者会挂起（好吧，他们没有被阻止，但他们不再消费消息）。我们可以看到，因为每个消费者每秒在数据库中保存大约 100 条消息，所以当一个消费者停止消费时，数据库中每秒保存的总体消息以相同的比率下降（如果假设 3 个消费者停止，我们会下降大约 600 条消息） /秒到 300 条消息/秒）。
在那段时间里，生产者一切正常，仍然以 jmeter 速率（大约 600 条消息/秒）生产。消息位于队列中，并由仍然“活着”的消费者获取。
我们首先用生产者加载所有servlet，然后一一启动所有消费者，检查连接是否正常，然后运行jmeter。
我们正在向一个直接交换发送消息。所有消费者都在监听与交换器绑定的一个持久队列。
这一点对我们的选择很重要。你用rabbitmq见过这个吗，你知道发生了什么吗？
谢谢您的回答。
Our team is in a spike sprint to choose between ActiveMQ or RabbitMQ. We made 2 little producer/consumer spikes sending an object message with an array of 16 strings, a timestamp, and 2 integers. The spikes are ok on our devs machines (messages are well consumed).
Then came the benchs. We first noticed that somtimes, on our machines, when we were sending a lot of messages the consumer was sometimes hanging. It was there, but the messsages were accumulating in the queue.
When we went on the bench plateform :
- cluster of 2 rabbitmq machines 4 cores/3.2Ghz, 4Gb RAM, load balanced by a VIP
- one to 6 consumers running on the rabbitmq machines, saving the messages in a mysql DB (same type of machine for the DB)
- 12 producers running on 12 AS machines (tomcat), attacked with jmeter running on another machine. The load is about 600 to 700 http request per second, on the servlets that produces the same load of RabbitMQ messages.
We noticed that sometimes, consumers hang (well, they are not blocked, but they dont consume messages anymore). We can see that because each consumer save around 100 msg/sec in database, so when one is stopping consumming, the overall messages saved per seconds in DB fall down with the same ratio (if let say 3 consumers stop, we fall around 600 msg/sec to 300 msg/sec).
During that time, the producers are ok, and still produce at the jmeter rate (around 600 msg/sec). The messages are in the queues and taken by the consumers still "alive".
We load all the servlets with the producers first, then launch all the consumers one by one, checking if the connexions are ok, then run jmeter.
We are sending messages to one direct exchange. All consumers are listening to one persistent queue bounded to the exchange.
That point is major for our choice. Have you seen this with rabbitmq, do you have an idea of what is going on ?
Thank you for your answers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
总是值得的
在使用 basic.consume 时设置预取计数：
在channel.basicConsume行之前，以确保您永远不会
超过 100 条消息在您的 QueueingConsumer 中排队。
It's always worth
setting the prefetch count when using basic.consume :
before the channel.basicConsume line in order to ensure you never have
more than 100 messages queued up in your QueueingConsumer.
我在使用 RabbitMQ STOMP 插件时看到过这种行为。我还没有找到解决办法。
您使用 STOMP 插件吗？
I have seen this behavior when using the RabbitMQ STOMP plugin. I haven't found a solution yet.
Are you using the STOMP plugin?
RabbitMQ 中的通道不是线程安全的。
因此，请检查消费者通道中是否有任何线程请求。
The channel in a RabbitMQ is not thread safe.
so check in consumer channel for any thread requests.