Optimización de la cantidad de captación previa del consumo de RabbitMQ
El mecanismo de distribución de mensajes por sondeo y el mecanismo de envío de mensajes lo más rápido posible plantean dificultades para el uso real. De hecho, la capacidad de cada consumidor para procesar mensajes y el tiempo necesario para procesar cada mensaje pueden ser diferentes. Si los mensajes solo se distribuyen mecánicamente en orden, un consumidor puede tener una acumulación de mensajes debido a negocios complejos y bajas capacidades de procesamiento, mientras que otro consumidor completará todos los mensajes por adelantado y quedará inactivo, lo que resultará en un desperdicio de capacidades de procesamiento del sistema. Y no se pueden agregar nuevos consumidores para aumentar la potencia de procesamiento del sistema.
El efecto ideal es que cada consumidor asigne razonablemente las tareas de procesamiento de mensajes de acuerdo con sus propias capacidades de procesamiento, y los nuevos consumidores también pueden compartir tareas de procesamiento de mensajes, lo que permite que las capacidades de procesamiento del sistema se expandan en paralelo.
El cliente RabbitMQ puede establecer el recuento de captación previa del consumidor a través de basicQos(int prefetchCount) de la clase Channel, que es el número máximo de mensajes no confirmados por el consumidor.
Supongamos que prefetchCount = 10, hay dos consumidores. Los dos consumidores obtienen secuencialmente 10 mensajes de la cola y los almacenan en caché localmente. Si llega un nuevo mensaje a la cola en este momento, primero determine si hay más o igual a 20 mensajes sin confirmar en el canal. De ser así, no se entregarán mensajes al canal. Cuando la cantidad de mensajes no confirmados en el canal es inferior a 20, los consumidores en el canal tienen menos de 65,430 mensajes no confirmados.
Si el número de captaciones previas establecido en channel.basicQos() es apropiado es una cuestión muy especial. Queremos aprovechar al máximo la potencia de procesamiento del consumidor, por lo que no debe establecerse demasiado pequeña. De lo contrario, una vez que el consumidor haya procesado el mensaje, RabbitMQ no entregará nuevos mensajes hasta que reciba un mensaje de confirmación, lo que provocará que el consumidor esté inactivo. durante este período y desperdiciando el consumo de potencia de procesamiento del usuario; sin embargo, si la configuración es demasiado grande, los mensajes pueden acumularse en la memoria caché del usuario; Esperamos que los mensajes que no se puedan procesar en el futuro permanezcan en la cola y permitan que nuevos consumidores o consumidores inactivos compartan la tarea de procesar mensajes.
? Un artículo en el sitio web oficial de RabbitMQ analiza en detalle la configuración de la cantidad de captación previa:
? /blog/2012/05/11/alguna-teoría de colas-rendimiento-latencia-bandwidth/
Supongamos que se necesitan 50 milisegundos para obtener un mensaje de la cola del servidor RabbitMQ y transmitirlo al consumidor, y el El consumidor consume el mensaje. El consumidor tarda 4 milisegundos y 50 milisegundos en transmitir el mensaje de confirmación al servidor. Si las condiciones de la red y la velocidad de procesamiento del consumidor son estables, el número óptimo de captaciones previas es: (50 4 50)/4=26.
Inicialmente, el servidor enviará 26 mensajes al cliente y los almacenará en caché localmente. Cuando el consumidor procesa el primer mensaje, envía un mensaje de confirmación al servidor y obtiene el segundo mensaje almacenado en caché local. Se necesitan 50 milisegundos para que el mensaje de confirmación se envíe del cliente al servidor. Después de que el servidor reciba la confirmación, enviará un nuevo mensaje al cliente después de 50 ms. Los 25 mensajes restantes tardarán 25 × 4 = 100 ms en consumirse. Entonces, cuando llega un mensaje nuevo, y así sucesivamente, cada vez que se procesa un mensaje antiguo, llega un mensaje nuevo. No habrá retrasos en las noticias y los consumidores no estarán inactivos.
? Pero la situación real es que el estado de transmisión de la red y la velocidad a la que los consumidores procesan los mensajes no serán constantes y pueden ser más rápidos o más lentos, lo que resultará en una acumulación de mensajes o consumidores inactivos. Esto requiere una cantidad de captación previa para cambiar. con los cambios de la red y del consumidor en tiempo real.
Para decirlo sin rodeos, la captación previa de datos sirve para controlar la conexión entre la adquisición/envío de datos por parte de los consumidores y la lógica empresarial, y para evitar un retraso o una inactividad excesiva de un determinado mensaje.