Потребители сообщений RabbitMQ перестают потреблять сообщения - PullRequest
5 голосов
/ 20 июля 2010

Наша команда находится в спринтовом спринте, чтобы выбрать между ActiveMQ или RabbitMQ.Мы сделали два небольших всплеска производителя / потребителя, отправив сообщение объекта с массивом из 16 строк, отметкой времени и двумя целыми числами.Шипы в порядке на наших машинах разработчиков (сообщения хорошо потребляются).

Затем появились стенды.Мы впервые заметили, что иногда на наших машинах, когда мы отправляли много сообщений, потребитель иногда зависал.Это было там, но сообщения накапливались в очереди.

Когда мы пошли на стендовую форму:

  • кластер из 2 компьютеров rabbitmq 4 ядра / 3,2 ГГц, 4 ГБ ОЗУ,нагрузка уравновешивается VIP
  • одним-шестью потребителями, работающими на машинах rabbitmq, сохраняя сообщения в базе данных mysql (машина того же типа для БД)
  • 12 производителей, работающих на 12 машинах AS(tomcat), атакованный с помощью jmeter, работающего на другой машине.Загрузка составляет от 600 до 700 запросов http в секунду для сервлетов, которые производят такую ​​же загрузку сообщений RabbitMQ.

Мы заметили, что иногда ,потребители зависают (ну, они не заблокированы, но они больше не потребляют сообщения).Мы видим, что, поскольку каждый потребитель экономит около 100 мс / сек в базе данных, поэтому, когда один из них прекращает потребление, общее количество сообщений, сохраняемых за секунду в БД, падает с одинаковым отношением (если, скажем, 3 потребителя останавливаются, мы падаем около 600 мсг)./ сек до 300 мсг / сек).

В течение этого времени с производителями все в порядке, и они все еще производят со скоростью jmeter (около 600 мсг / сек).Сообщения находятся в очередях и принимаются потребителями до сих пор «живыми».

Сначала мы загружаем все сервлеты с производителями, затем запускаем всех потребителей по одному, проверяем, в порядке ли соединения, затем запускаем jmeter.

Мы отправляем сообщения на один прямой обмен,Все потребители слушают одну постоянную очередь, ограниченную биржей.

Этот момент важен для нашего выбора.Вы видели это с rabbitmq, у вас есть представление о том, что происходит?

Спасибо за ваши ответы.

Ответы [ 4 ]

4 голосов
/ 28 июля 2010

Всегда стоит устанавливать счетчик предварительной выборки при использовании basic.consume:

channel.basicQos(100);

перед строкой channel.basicConsume, чтобы в вашем QueueingConsumer никогда не было более 100 сообщений в очереди.

2 голосов
/ 05 ноября 2010

Для объяснения QoS, смотри эту хорошую запись в блоге:

https://github.com/0x6e6562/hopper/blob/master/Work%20Distribution%20in%20RabbitMQ.markdown

1 голос
/ 26 июля 2010

Я видел такое поведение при использовании плагина RabbitMQ STOMP.Я еще не нашел решение.

Вы используете плагин STOMP?

0 голосов
/ 18 ноября 2010

Канал в RabbitMQ не является потокобезопасным. так проверьте в потребительском канале любые потоки запросов.

...