Middleware de mensajes (1) Explicación detallada de MQ y comparación de los cuatro MQ principales
1. Conocimiento relacionado con el middleware de mensajes
1. Descripción general
La cola de mensajes se ha convertido gradualmente en el medio principal de comunicación interna en los sistemas de TI empresariales. Tiene una serie de funciones como bajo acoplamiento, entrega confiable, transmisión, control de flujo y eventual consistencia, y se ha convertido en uno de los principales medios de RPC asíncrono. Actualmente, existen muchos middleware de mensajes convencionales en el mercado, como el antiguo ActiveMQ, RabbitMQ, el popular Kafka, RocketMQ desarrollado independientemente por Alibaba, etc.
2. Composición del middleware de mensajes
2.1 Broker
El servidor de mensajes, como servidor, proporciona servicios centrales de mensajes
2.2 Productor
p>El productor de mensajes, el iniciador del negocio, es responsable de producir mensajes y transmitirlos al corredor.
2.3 Consumidor
Consumidor de mensajes, el procesador. del negocio, es responsable de obtener los mensajes del broker Message y realizar el procesamiento de la lógica de negocios
2.4 Tema
2.5 Cola
2.6 Mensaje
Cuerpo del mensaje, arreglado según diferentes protocolos de comunicación Paquetes de datos codificados en el formato para encapsular datos comerciales y realizar la transmisión de mensajes
3 Clasificación de los modos de middleware de mensajes
3.1 Punto- a punto
PTP punto a punto: utilizar cola como portador de comunicación
Descripción:
El productor del mensaje produce el mensaje y lo envía al cola, y luego el consumidor del mensaje lo saca de la cola y consume el mensaje.
Una vez consumido el mensaje, ya no se almacena en la cola, por lo que es imposible que el consumidor del mensaje consuma el mensaje que se ha consumido. La cola admite la existencia de múltiples consumidores, pero para un mensaje, solo un consumidor puede consumirlo.
Descripción:
La cola implementa el equilibrio de carga y envía mensajes producidos por el productor a la cola de mensajes para que los consuman varios consumidores. Pero un mensaje solo puede ser aceptado por un consumidor. Cuando no hay ningún consumidor disponible, el mensaje se guardará hasta que haya un consumidor disponible.
4 Ventajas del middleware de mensajes
4.1 Desacoplamiento del sistema
No existe una relación de llamada directa entre sistemas interactivos, solo transmisión de mensajes, por lo que el sistema es intrusivo No fuerte , bajo acoplamiento.
4.2 Mejorar el tiempo de respuesta del sistema
Por ejemplo, en el conjunto de lógica original, completar el pago puede implicar modificar el estado del pedido, calcular los puntos de miembro y notificar la distribución logística antes de que pueda ser completado a través de MQ A través del diseño arquitectónico, los negocios urgentes e importantes (que requieren respuesta inmediata) se pueden colocar en el método de llamada, y las colas de mensajes con bajos requisitos de respuesta se pueden colocar en la cola MQ para que los procesen los consumidores.
4.3 Proporcionar servicios para la arquitectura de procesamiento de big data
A través de mensajes como integración, en el contexto de big data, las colas de mensajes también se integran con la arquitectura de procesamiento en tiempo real para proporcionar soporte de rendimiento para proceso de datos.
4.4 Java Message Service - JMS
La interfaz del programa de aplicación Java Message Service (JMS) es una API para el middleware de mensajes (MOM) en la plataforma Java que se utiliza para enviar mensajes entre dos. aplicaciones o en un sistema distribuido para comunicación asíncrona.
5 escenarios de aplicación de middleware de mensajes
5.1 Comunicación asincrónica
Algunas empresas no quieren o no necesitan procesar mensajes de inmediato. La cola de mensajes proporciona un mecanismo de procesamiento asincrónico que permite a los usuarios colocar un mensaje en la cola pero no procesarlo inmediatamente. Coloque tantos mensajes como desee en la cola y procéselos cuando sea necesario.
5.2 Desacoplamiento
Reducir la fuerte dependencia entre proyectos y adaptarse a sistemas heterogéneos. Es extremadamente difícil predecir qué necesidades encontrará el proyecto en el futuro al comienzo del proyecto. Se inserta una capa de interfaz implícita basada en datos en el medio del proceso de procesamiento a través del sistema de mensajería. Los procesos de procesamiento en ambos lados deben implementar esta interfaz. Cuando la aplicación cambia, los procesos de procesamiento en ambos lados se pueden expandir o modificar de forma independiente. , siempre que se garanticen los procesos de procesamiento en ambos lados. Obedecen las mismas restricciones de interfaz.
5.3 Redundancia
En algunos casos, el proceso de procesamiento de datos fallará. A menos que los datos persistan, se perderán. Message Queue Server evita el riesgo de pérdida de datos al conservarlos hasta que se hayan procesado por completo. En el paradigma "insertar-obtener-eliminar" utilizado por muchas colas de mensajes, antes de eliminar un mensaje de la cola, su sistema de procesamiento debe indicar claramente que el mensaje ha sido procesado, garantizando así que sus datos se guarden de forma segura hasta que termine. usándolo.
5.4 Escalabilidad
Debido a que la cola de mensajes desacopla su procesamiento, es fácil aumentar la frecuencia de la puesta en cola y el procesamiento de mensajes, simplemente agregue procesamiento adicional. No es necesario cambiar el código ni ajustar los parámetros. Facilita la expansión distribuida.
5.5 Protección contra sobrecargas
En caso de un fuerte aumento de visitas, la aplicación aún necesita seguir funcionando, pero ese tráfico en ráfaga no se puede predecir si se cree que puede soportarlo; Este tipo de Inversión de recursos para estar en espera en función del acceso máximo instantáneo es, sin duda, un gran desperdicio. El uso de colas de mensajes puede permitir que los componentes clave resistan una presión de acceso repentina sin colapsar por completo debido a solicitudes repentinas sobrecargadas.
5.6 Recuperabilidad
Cuando falla una parte de los componentes del sistema, no afectará a todo el sistema. La cola de mensajes reduce el acoplamiento entre procesos, por lo que incluso si un proceso que procesa mensajes cuelga, los mensajes agregados a la cola aún se pueden procesar después de que el sistema se recupere.
5.7 Garantía de pedido
En la mayoría de los escenarios de uso, el orden del procesamiento de datos es importante. La mayoría de las colas de mensajes están ordenadas de forma inherente y pueden garantizar que los datos se procesarán en un orden específico.
5.8 Buffering
En cualquier sistema importante, habrá elementos que requieran diferentes tiempos de procesamiento. Las colas de mensajes ayudan a que las tareas se ejecuten de manera más eficiente a través de una capa de almacenamiento en búfer que ayuda a controlar y optimizar la velocidad a la que los datos fluyen a través del sistema. para ajustar el tiempo de respuesta del sistema.
5.9 Procesamiento de flujos de datos
Los flujos de datos masivos generados por sistemas distribuidos, como registros comerciales, datos de monitoreo, comportamientos de los usuarios, etc., se recopilan y resumen en tiempo real o en lotes. Entonces, el análisis de big data es una tecnología necesaria para la Internet actual y completar dicha recopilación de datos a través de colas de mensajes es la mejor opción.
6 Protocolos comúnmente utilizados para middleware de mensajes
6.1 Protocolo AMQP
AMQP es el protocolo avanzado de cola de mensajes, un protocolo de cola de mensajes avanzado estándar de capa de aplicación que proporciona mensajería unificada Services, es un estándar abierto para protocolos de capa de aplicación diseñados para middleware orientado a mensajes. Los clientes y el middleware de mensajes basados en este protocolo pueden transmitir mensajes y no están restringidos por diferentes productos de cliente/middleware, diferentes lenguajes de desarrollo, etc.
Ventajas: fiable y versátil
Protocolo MQTT 6.2
MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería instantánea desarrollado por IBM que tiene el potencial de. convertirse en una parte importante del Internet de las cosas. El protocolo es compatible con todas las plataformas y puede conectar casi todos los elementos conectados a Internet con el mundo exterior. Se utiliza como protocolo de comunicación para sensores y actuadores (como conectar casas a Internet a través de Twitter).
Ventajas: formato simple, pequeña ocupación de ancho de banda, comunicación móvil, PUSH, sistema integrado
Protocolo STOMP 6.3
STOMP (Protocolo de mensajes orientados a transmisión de texto) Es un protocolo de transmisión de mensajes orientado a texto, un protocolo de texto simple diseñado para MOM (Message Oriented Middleware, middleware orientado a mensajes). STOMP proporciona un formato de conexión interoperable que permite a los clientes interactuar con cualquier intermediario de mensajes STOMP (Broker).
Ventajas: modo comando (no modo tema\cola)
Protocolo XMPP 6.4
XMPP (Protocolo de presencia y mensajería extensible) Es un protocolo basado en Extensible Lenguaje de marcado (XML) y se utiliza principalmente para mensajería instantánea (IM) y detección de campos en línea. Adecuado para operaciones casi en tiempo real entre servidores. Basado esencialmente en la transmisión XML, este protocolo puede eventualmente permitir a los usuarios de Internet enviar mensajes instantáneos a cualquier otra persona en Internet, incluso si sus sistemas operativos y navegadores son diferentes.
Ventajas: apertura universal, gran compatibilidad, escalabilidad y alta seguridad, pero el formato de codificación XML ocupa mucho ancho de banda
6.5 Otros protocolos personalizados basados en TCP/IP
p >
Algunos marcos especiales (como redis, kafka, zeroMq, etc.) no siguen estrictamente la especificación MQ de acuerdo con sus propias necesidades, sino que encapsulan un conjunto de protocolos basados en TCP \ IP y los transmiten. la interfaz del socket de red, realizando la función MQ.
7 Introducción al middleware de mensajes común MQ
7.1 RocketMQ
Un middleware de mensajes de modelo de cola y distribuido de código abierto bajo el sistema Alibaba, anteriormente conocido como The Metaq. El nombre de la versión 3.0 se cambió a RocketMQ, que es un conjunto de mq implementado por Alibaba usando Java basado en ideas de diseño de Kafka. Al mismo tiempo, integramos múltiples productos mq (Notify, metaq) dentro de Alibaba para mantener solo las funciones principales y eliminar todas las demás dependencias de tiempo de ejecución para garantizar que las funciones principales se minimicen. Sobre esta base, cooperamos con otros productos de código abierto de Alibaba. mencionado anteriormente para implementar diferentes escenarios, la arquitectura mq se utiliza actualmente principalmente en sistemas de comercio de órdenes.
Tiene las siguientes características:
El oficial proporciona algunas diferencias comparativas con kafka:
https://rocketmq.apache.org/docs/motivation/
7.2 RabbitMQ
Una cola de mensajes de código abierto escrita en Erlang, que admite muchos protocolos: AMQP, XMPP, SMTP, STOMP. Esto es lo que la hace muy pesada y más adecuada para empresas. desarrollo del nivel. Al mismo tiempo, se implementa la arquitectura del Broker. La idea central es que el productor no enviará mensajes directamente a la cola, y el mensaje se colocará primero en la cola central cuando se envíe al cliente.
Tiene buen soporte para enrutamiento, equilibrio de carga y persistencia de datos. Se utiliza principalmente para la integración de ESB a nivel empresarial.
7.3 ActiveMQ
Un subproyecto bajo Apache. Al utilizar Java para admitir completamente la implementación del proveedor JMS de las especificaciones JMS1.1 y J2EE 1.4, se pueden implementar escenarios de aplicaciones avanzadas de manera eficiente con una pequeña cantidad de código. Compatibilidad con protocolos de transporte conectables, como: transportes in-VM, TCP, SSL, NIO, UDP, multidifusión, JGroups y JXTA. RabbitMQ, ZeroMQ y ActiveMQ admiten clientes multilingües de uso común C, Java, .Net, Python, Php, Ruby, etc.
7.4 Redis
Una base de datos NoSQL de valores clave desarrollada en lenguaje C. El desarrollo y el mantenimiento son muy activos. Aunque es un sistema de almacenamiento de bases de datos de valores clave, en sí mismo es compatible con MQ. función, por lo que se puede utilizar como un servicio de cola ligero. Para las operaciones de puesta en cola y retirada de cola de RabbitMQ y Redis, cada una se ejecuta 1 millón de veces y el tiempo de ejecución se registra cada 100.000 veces. Los datos de prueba se dividen en cuatro tamaños diferentes: 128Bytes, 512Bytes, 1K y 10K. Los experimentos muestran que cuando los datos son relativamente pequeños, el rendimiento de Redis es mayor que el de RabbitMQ al ingresar a la cola, pero si el tamaño de los datos excede los 10K, Redis es insoportablemente lento al salir de la cola, y Redis muestra muy buen rendimiento independientemente de; el tamaño de los datos y el rendimiento de eliminación de cola de RabbitMQ es mucho menor que el de Redis.
7.5 Kafka
Un subproyecto bajo Apache, un sistema de cola de mensajes de publicación/suscripción distribuido de alto rendimiento implementado usando Scala, con las siguientes características:
7.6 ZeroMQ
Conocido como el sistema de cola de mensajes más rápido, está especialmente desarrollado para escenarios de alto rendimiento/baja latencia. A menudo se utiliza en aplicaciones de la industria financiera y se centra en escenarios de comunicación de datos en tiempo real. ZMQ puede implementar colas avanzadas/complejas en las que RabbitMQ no es bueno, pero los desarrolladores necesitan combinar varios marcos técnicos ellos mismos y el costo de desarrollo es alto. Por lo tanto, ZeroMQ tiene un modelo único sin middleware, que se parece más a una biblioteca de sockets. No necesita instalar ni ejecutar un servidor de mensajes o middleware, porque su aplicación utiliza la API ZeroMQ para completar la función de servicios lógicos. Sin embargo, ZeroMQ solo proporciona colas no persistentes. Si la máquina no funciona, se perderán datos. Por ejemplo: Storm de Twitter utiliza ZeroMQ como transmisión de flujo de datos.
El socket ZeroMQ es independiente de la capa de transporte: el socket ZeroMQ define una interfaz API unificada para todos los protocolos de la capa de transporte. De forma predeterminada, se admiten los protocolos intraproceso (inproc), entre procesos (IPC), multidifusión y TCP. Para cambiar entre diferentes protocolos, simplemente cambie el prefijo de la cadena de conexión. Puede pasar de la comunicación local entre procesos a la comunicación TCP distribuida en cualquier momento con un costo mínimo. ZeroMQ maneja la lógica de establecimiento, desconexión y reconexión de la conexión entre bastidores.
Características:
2. Comparación del middleware de mensajes principal