1. Algunos conocimientos de RabbitMQ
1. Atributos del mensaje
RabbitMQ es un middleware de mensajes basado en el protocolo de transmisión de mensajes AMQP; similar a HTTP, hay dos partes de datos, encabezado y cuerpo, y Mensaje es el concepto de cuerpo de mensaje en RabbitMQ.
El mensaje se compone de Propiedades y Cuerpo. El primero es cierta metainformación, como la prioridad del mensaje, la persistencia, el formato de transmisión (como JSON), la demora y otras funciones avanzadas, y el Cuerpo es la entidad de datos del mensaje que se transmite.
2. Entrega de mensajes
Los tres conceptos de Exchange, Queue y Routing Key son la clave para comprender la entrega de mensajes de RabbitMQ. Un principio fundamental en RabbitMQ es que los mensajes no se pueden entregar directamente a Queue.
El productor solo puede entregar su propio mensaje a Exchange, y Exchange lo entrega a la cola correspondiente de acuerdo con la clave de enrutamiento.
3. Confiabilidad del mensaje
A diferencia del acceso síncrono HTTP, en RabbitMQ, el Productor no sabe si el mensaje se entregó de manera confiable al Consumidor para su procesamiento. Entonces, ¿cómo garantiza RabbitMQ la entrega confiable de mensajes?
Hay dos puntos principales: primero, el mecanismo de confirmación del mensaje. Después de que el Consumidor termine de procesar el mensaje, debe enviar un mensaje de confirmación al Broker Server. Hay tres formas de elegir "confirmar recepción", "descartar" y "reenviar". Si el consumidor cuelga antes de que el servidor del intermediario reciba el mensaje de confirmación, el servidor del intermediario volverá a enviar el mensaje.
En segundo lugar, puede elegir la persistencia de datos para que, incluso si RabbitMQ se reinicia, los mensajes no se pierdan.
2. Escenarios de uso de RabbitMQ
1. Acceso a datos
Supongamos que existe un sistema de recopilación de comportamiento de usuario responsable de recopilar datos de comportamiento de clic de usuario desde el lado de la aplicación. Por lo general, los informes de datos y el procesamiento de datos están separados, es decir, el lado de la aplicación informa los datos a través de la API REST, y el backend recibe los datos, los pone en la cola y los devuelve de inmediato, mientras que el procesamiento de datos usa Worker para obtener datos de la cola, de la siguiente manera Como se muestra en la figura.
Los beneficios de hacer esto son:
Primero, la separación de funciones, la interfaz API informada no se preocupa por la función de procesamiento de datos y solo es responsable de acceder a los datos;
En segundo lugar, el almacenamiento en búfer de datos, la tasa de informes de datos es incontrolable, dependiendo de la frecuencia de uso del usuario, el uso de este modo puede almacenar datos hasta cierto punto;
En tercer lugar, es fácil de expandir. Cuando la cantidad de datos es grande, se puede expandir agregando Trabajadores de procesamiento de datos para aumentar la tasa de procesamiento. Este es un modelo típico de productor-consumidor, donde los datos se informan como productor y los datos se procesan como consumidor.
2. Distribución de eventos
Supongamos que hay un sistema de comercio electrónico, la "cobro", "pedido", "pago" y otros comportamientos del usuario son eventos muy importantes. Por lo general, el servicio de back-end necesita hacer mucho en estos puntos de eventos además de completar el procesamiento funcional correspondiente Otras acciones de procesamiento, como enviar notificaciones por SMS, registrar puntos de usuario, etc.
Si ponemos estas acciones en cada módulo, no es propicio para el desacoplamiento funcional y el mantenimiento del código.En este momento, necesitamos un sistema de distribución de eventos para publicar los eventos correspondientes en cada módulo funcional y los procesadores que estén interesados en procesarlos.
Hay dos roles involucrados aquí: A está interesado en B, A es el controlador, B es el evento, el controlador de eventos completa el enlace de los dos y se suscribe al evento en el centro de mensajes. El módulo de servicio es el servicio de lógica empresarial back-end, que publica eventos en diferentes puntos de eventos y los eventos se distribuyen a los controladores correspondientes a los controladores de eventos a través del centro de mensajes.
Todo el proceso se muestra en la figura a continuación, y aquí hay un modo típico de publicación por suscripción.
3. Seis modos de trabajo de RabbitMQ
1. Modo simple: solo una cola y un consumidor
default AMQP交换机En modo simple, no necesitamos especificar un interruptor . RabbitMQ entregará nuestros mensajes a la cola especificada de manera predeterminada. Es un interruptor de tipo directo. La clave de enlace cuando la cola está vinculada a él es en realidad el nombre de la cola. .
2. WorkQueues: modo de cola de trabajo, solo una cola, múltiples consumidores
El modo de cola de trabajo también usa el conmutador AMQP predeterminado, y los mensajes en la cola se distribuirán uniformemente a varios consumidores para su procesamiento. Hay dos formas de distribución de mensajes:
Distribución por turnos : un consumidor consume un artículo y se distribuye por igual . En el modo woek, el método de distribución por turnos se adopta de forma predeterminada. La distribución de sondeo no escribe demostración de código, es relativamente simple, por ejemplo, si un productor envía 6 mensajes a la cola, si hay 3 consumidores escuchando esta cola al mismo tiempo, entonces cada uno de estos 3 consumidores compartirá Got 2 mensajes Lo siguiente introduce principalmente una distribución justa.
Distribución justa : La distribución justa se realiza de acuerdo a la capacidad de consumo de los consumidores, los que se procesan rápido obtienen más, los que se procesan lentamente obtienen menos, y los que pueden hacer más trabajo .
3. Publicar/Suscribir: modo de suscripción de publicación, hay N colas, N consumidores, debe declarar el interruptor de enlace
Hay tres tipos de interruptores en RabbitMQ: abanico, directo, tema
(1) fanout: modo fan-out, el mensaje se transmite a todas las colas vinculadas al conmutador
(2) directo: modo de enrutamiento, el editor del mensaje especifica una clave y el mensaje se enruta a todas las colas que coinciden con la clave
(3) tema: el modo de tema, similar al modo de enrutamiento, puede tener coincidencias aproximadas con comodines
4. Modo RPC: admite la situación en la que el productor y el consumidor no están en el mismo sistema, es decir, se permiten llamadas remotas
- En el modo RPC, el consumidor generalmente se ubica en un sistema remoto como servidor y proporciona una interfaz; el productor llama a la interfaz y envía un mensaje.
- El modo RPC es un modo de llamada remota, ya que requiere solicitudes http, por lo que la velocidad es más lenta que la llamada interna del sistema. Además, en el modo rpc, normalmente no es fácil distinguir cuáles son solicitudes externas y cuáles internas, lo que resulta en una velocidad general más lenta. Por lo tanto, no se puede abusar del modo rpc.
- Hay dos propiedades en MessageProperties:
answer_to: se utiliza para definir el nombre de la cola de devolución de llamada
correlación_id: se utiliza para correlacionar el envío de solicitudes de mensajes rpc y la recepción de respuestas de mensajes.
- Para implementar el modo RPC, el productor debe enviar una cola de devolución de llamada, el flujo de trabajo:
1. Después de que el productor (Cliente) comienza a producir mensajes, crea una cola de devolución de llamada anónima y exclusiva.
2. Cuando el productor (Cliente) envía una solicitud, contiene dos atributos: answer_to, que es la cola de devolución de llamada, correlación_id, que es la ID de esta solicitud
3. La solicitud (solicitud) se envía a la cola rpc_queue.
4. El consumidor (el trabajador RPC) espera la solicitud en rpc_queue, cuando la recibe, procesa el mensaje y envía el resultado al cliente utilizando la cola en el campo de respuesta.
5. El productor espera el mensaje en la cola de devolución de llamada. Cuando aparezca el mensaje, verifique la correlación_id y devuelva los datos de respuesta al programa si coinciden con el valor en la solicitud.