Los consumidores de mensajes de RabbitMQ dejan de consumir mensajes

Question

Nuestro equipo se encuentra en una carrera rápida para elegir entre ActiveMQ o RabbitMQ. Hicimos 2 pequeñas puntas de productor/consumidor enviando un mensaje de objeto con una matriz de 16 cadenas, una marca de tiempo y 2 enteros. Los picos están bien en nuestras máquinas de desarrollo (los mensajes se consumen bien).

Luego vinieron los bancos. Notamos por primera vez que a veces, en nuestras máquinas, cuando estábamos enviando muchos mensajes, el consumidor a veces estaba colgando. Estaba allí, pero los mensajes se acumulaban en la cola.

Cuando fuimos en el banco Plateform:

• racimo de 2 máquinas RabbitMQ 4 núcleos/3.2Ghz, 4 GB de RAM, carga equilibrada por un VIP
• uno a 6 consumidores que se ejecuta en las máquinas RabbitMQ, guardar los mensajes en una base de datos MySQL (mismo tipo de máquina para el DB)
• 12 productores que se ejecutan en máquinas AS 12 (Tomcat), atacaron con jmeter se ejecuta en otra máquina. La carga es de aproximadamente 600 a 700 pedidos por segundo por segundo, en los servlets que producen la misma carga de mensajes RabbitMQ.

notamos que veces, los consumidores cuelgan (bueno, no están bloqueadas, pero ellos no consumir mensajes más). Podemos ver eso porque cada consumidor ahorra alrededor de 100 msg/seg en la base de datos, por lo que cuando uno deja de consumir, los mensajes generales guardados por segundo en DB caen con la misma proporción (si dijimos que 3 consumidores se detienen, caemos alrededor de 600 msg)./seg a 300 msg/seg).

Durante ese tiempo, los productores están bien, y aún así producir a la tasa jmeter (alrededor de 600 msg/seg). Los mensajes están en las colas y son tomados por los consumidores aún "vivos".

cargamos todos los servlets con los productores en primer lugar, a continuación, poner en marcha todos los consumidores, uno por uno, comprobando si las conexiones están bien, a continuación, ejecute jmeter.

Estamos enviando mensajes a un intercambio directo. Todos los consumidores están escuchando una fila persistente limitada al intercambio.

Ese punto es importante para nuestra elección. ¿Has visto esto con rabbitmq, tienes una idea de lo que está pasando?

Gracias por su respuesta.

Answer 1

Siempre vale la pena establecer el recuento de captación previa cuando se utiliza basic.consume:

channel.basicQos(100); 

antes de la línea channel.basicConsume con el fin de garantizar que nunca tenga más de 100 mensajes en cola en su QueueingConsumer.

Answer 2

He visto este comportamiento cuando se utiliza el plugin RabbitMQ STOMP. No he encontrado una solución todavía.

¿Está utilizando el plugin STOMP?

Answer 3

Para la explicación QoS, CF esta buena entrada de blog:

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

Answer 4

El canal en un RabbitMQ no es hilo de seguridad. así que verifique en el canal del consumidor cualquier solicitud de subprocesos.