Instrucciones de configuración relacionadas con la optimización del rendimiento del consumidor de RabbitMQ

RabbitMQ es un middleware de mensajes distribuidos escrito en lenguaje Erlang. Generalmente se utiliza como cola de mensajes en sitios web grandes. Su objetivo principal es desacoplar el procesamiento asincrónico entre varios subsistemas. El patrón básico del middleware de mensajes es el patrón típico productor-consumidor, es decir, el productor envía mensajes a la cola de mensajes y el consumidor escucha la cola de mensajes y consume los mensajes después de recibirlos.

Al utilizar RabbitMQ para la distribución de mensajes, debe prestar atención a tres conceptos principales: Exchange, RoutingKey y Queue.

Exchange puede entenderse como un intercambiador, RoutingKey puede entenderse como enrutamiento y Queue puede entenderse como una cola que realmente almacena mensajes. Una determinada cola sirve como una cola que realmente almacena mensajes y está vinculada a ellos. Exchange. ¿Cómo enrutar a las partes interesadas? La cola está determinada por los tres modos de Exchange:

(1) Exchange es un fan-out. Los mensajes enviados por el productor a Exchange se enviarán a cada uno. cola vinculada a él En este momento, RoutingKey No tiene ningún efecto;

(2) Exchange es un tema y el productor puede especificar una RoutingKey que admita comodines (por ejemplo: "RoutingKey"). g.,demo.*) se envía al Exchange, y todas las colas del Exchange cuya RoutingKey coincida con el comodín recibirán el mensaje;

(3) El tipo directo de Exchange es el más directo y simple y el productor Especifique Exchange y RoutingKey, y luego envíele el mensaje. El mensaje solo se puede vincular a la cola que se ajusta a la RoutingKey para recibir el mensaje. (Por lo general, si no especifica un nombre específico para RoutingKey, el nombre predeterminado es en realidad el nombre de la cola).

Configuración yml del lado del consumidor:

En el lado del consumidor , configure prefectch y el parámetro de concurrencia para habilitar el procesamiento de mensajes simultáneos en el lado del consumidor de mq, entonces, ¿qué significan estos dos parámetros? ¿Qué significan estos dos parámetros?

La captación previa es la cantidad de mensajes consumidos del corredor cada vez.

Cada cliente precarga una cierta cantidad de mensajes en el LinkedBlockingQueue en memoria de MQ. Cuanto mayor sea el valor, más rápido se entregarán los mensajes, pero mayor será el riesgo de que se interrumpa el orden en el que se procesan los mensajes. Si el modo de reconocimiento es Ninguno, se ignora.

El valor predeterminado para la captación previa solía ser 1, lo que podría provocar una infrautilización por parte de usuarios eficientes. A partir de la versión 2.0 de spring-amqp, el valor de captación previa predeterminado es 250, lo que mantendrá ocupados a los consumidores en los escenarios más comunes, mejorando así el rendimiento.

Sin embargo, en algunos escenarios de aplicaciones, especialmente mensajes grandes que se procesan lentamente, los mensajes pueden acumularse en la memoria y consumir mucha memoria, así como algunos mensajes que requieren una clasificación estricta, los valores de captación previa deben establecerse en 1.

Para escenarios de mensajería de bajo volumen y de múltiples consumidores (así como contenedores de un solo escucha con configuraciones simultáneas), si desea distribuir los mensajes de manera más uniforme entre varios usuarios, se recomienda obtener y establezca la Toma preestablecida =1.

Si desea asegurarse de que los mensajes no se pierdan, cuando la captación previa es mayor que 1, es posible que se pierdan datos debido al tiempo de inactividad del servicio, por lo que se recomienda configurar la captación previa = 1.

La simultaneidad establece el número de consumidores simultáneos establecidos para cada oyente durante la inicialización. En la configuración de yml anterior, concurrencia = 1, es decir, se abre un hilo para cada contenedor de escucha para procesar mensajes. En las versiones 2.0 y posteriores, este parámetro se puede configurar en las anotaciones:

Después de iniciar el servicio, puede observar que se generan dos subprocesos en el contenedor del oyente para consumir la cola.

Si el parámetro exclusivo está configurado en el oyente, se determina si un único cliente en el contenedor tiene acceso exclusivo a la cola. Si es verdadero, el recuento de simultaneidad del contenedor debe ser 1.

Si el consumidor está configurado con prefetch=10 y concurrency=2, entonces habrá dos consumidores (o subprocesos) escuchando la cola al mismo tiempo, pero cabe señalar que una vez que se envía el mensaje consumido por un consumidor, será rechazado automáticamente, por lo que otro consumidor no volverá a recibir el mensaje.

El oyente correspondiente a cada consumidor tiene un parámetro exclusivo, cuyo valor predeterminado es falso. Si se establece en verdadero, la concurrencia debe establecerse en 1, lo que significa que solo un consumidor puede consumir mensajes de la cola. Esto es adecuado para mensajes que deben ejecutar estrictamente el orden de consumo de la cola (primero en entrar, primero en salir).

Como dije antes, al configurar la concurrencia, debemos considerar escenarios comerciales específicos. Para aquellos escenarios que requieren un alto orden de mensajes, no es adecuado para el consumo concurrente, y para otros escenarios, como cuando. Al enviar mensajes recordatorios a los usuarios después del registro, no nos importa demasiado qué mensaje se consume primero y qué mensaje se consume más tarde, porque cada mensaje es relativamente independiente. Los usuarios que se registran después de recibir el mensaje primero no serían demasiado grandes. un impacto. No tendrá mucho impacto si los usuarios que se registran más tarde reciben primero el mensaje de texto.

Además de aumentar la velocidad de consumo, configurar el consumo simultáneo tiene otro beneficio: cuando un consumidor está bloqueado durante mucho tiempo, los mensajes en el BlockingQueue interno del consumidor actual también se bloquearán, pero se pueden enviar nuevos mensajes. aún se puede entregar a otros consumidores para su consumo, lo que puede causar problemas con la cantidad de mensajes consumidos en la captación previa. Esta situación, como máximo, causará problemas con la cantidad de mensajes consumidos en la captación previa, pero no provocará que toda la cola RabbitMQ se bloquee debido a problemas con los mensajes en un escenario de un solo consumidor. Todo lo que necesita hacer es establecer la simultaneidad adecuada y los valores de captación previa para el escenario empresarial adecuado.