1 JMS
Java Message Service, Java Message Service es una API de middleware orientado a mensajes (MOM) en la plataforma Java, que se utiliza para enviar mensajes entre dos aplicaciones o sistemas distribuidos para la comunicación asíncrona.
Escenarios de aplicación de 2 mq
1) El
sistema de desacoplamiento A está seriamente acoplado con otros sistemas desordenados. El sistema A produce una pieza clave de datos, y muchos sistemas requieren que el sistema A envíe estos datos. ¿Un sistema siempre debe considerar los cuatro sistemas BCDE si fallan? ¿Quieres reenviar o guardar el mensaje? ¡Mi cabello es gris!
Si se utiliza MQ, el sistema A genera un dato y lo envía a MQ, sistema que necesita los datos para consumirlos en MQ. Si el nuevo sistema necesita datos, consúmalos directamente desde MQ; si un sistema no necesita estos datos, simplemente cancele el consumo de mensajes MQ. De esta manera, el sistema A no necesita considerar a quién enviar datos, no necesita mantener este código y no necesita considerar si la llamada es exitosa, tiempo de espera de falla, etc.
2)
Veamos otro escenario de forma asincrónica . Cuando el sistema A recibe una solicitud, necesita escribir la biblioteca localmente y también necesita escribir la biblioteca en los tres sistemas BCD. Se necesitan 3ms para escribir la biblioteca localmente, y 300ms, 450ms, 200ms. El retraso total de la solicitud final es 3 + 300 + 450 + 200 = 953ms, que es cercano a 1. El usuario siente que algo es demasiado lento. El usuario inicia una solicitud a través del navegador y espera 1 segundo, lo cual es casi inaceptable.
Generalmente, las empresas basadas en Internet generalmente requieren que cada solicitud se complete dentro de los 200 ms para las operaciones directas del usuario, que casi desconocen los usuarios.
Si usa MQ, el sistema A envía 3 mensajes a la cola de MQ de forma continua. Si tarda 5 ms, el tiempo total desde que recibe una solicitud hasta devolver una respuesta al usuario es 3 + 5 = 8 ms. Para el usuario, en realidad se siente Simplemente haga clic en un botón y volverá directamente después de 8 ms, ¡genial! ¡El sitio web está tan bien hecho, tan rápido!
3) Reducción de picos
Todos los días de 0:00 a 12:00, el sistema A está en calma y el número de solicitudes simultáneas por segundo es 50. Como resultado, cada vez de 12:00 a 13:00, el número de solicitudes simultáneas por segundo aumenta repentinamente a 5000 +. Pero el sistema se basa directamente en MySQL, una gran cantidad de solicitudes inundan MySQL y se ejecutan alrededor de 5000 SQL en MySQL cada segundo.
En general, MySQL es casi suficiente para transportar 2k solicitudes por segundo. Si las solicitudes por segundo alcanzan los 5k, MySQL puede ser eliminado directamente, causando que el sistema se bloquee y los usuarios ya no puedan usarlo.
Pero una vez que termina el período pico, por la tarde, se convierte en un período pico bajo. Puede ser que 1w usuarios estén operando en el sitio web al mismo tiempo. El número de solicitudes por segundo puede ser de solo 50 solicitudes, lo que es casi nada para todo el sistema. presión.
Si utiliza MQ, se escriben en MQ 5000 solicitudes por segundo y el sistema A puede procesar hasta 2000 solicitudes por segundo porque MySQL procesa hasta 2000 solicitudes por segundo. El sistema A extrae lentamente las solicitudes de MQ, extrayendo 2000 solicitudes por segundo. No exceda el número máximo de solicitudes que puede manejar por segundo. Está bien. De esta manera, incluso durante los períodos pico, el sistema A nunca Colgará. Si bien las solicitudes de MQ 5k llegan cada segundo, solo salen 2.000 solicitudes. Como resultado, durante el período pico del mediodía (1 hora), cientos de miles o incluso millones de solicitudes pueden quedar atrasadas en MQ. Este corto período de acumulación de solicitudes está bien, porque después del período pico, 50 solicitudes ingresan al MQ cada segundo, pero el sistema A seguirá procesando 2000 solicitudes por segundo. Por lo tanto, mientras termine el período pico, el sistema A resolverá rápidamente la acumulación de mensajes.
3 Problemas causados por MQ
1) Mayor complejidad del sistema
2) Requisitos de consistencia reducidos
4 Middleware para mensajes de uso común
1 ActiveMQ
ActiveMQ es un potente bus de mensajes de código abierto producido por Apache. Es un middleware de mensajes
que es totalmente compatible con la especificación JMS. Proporciona API enriquecidas y una variedad de modos de construcción de clústeres para convertirlo en un veterano en la industria.
El middleware de mensajes se usa ampliamente en pequeñas y medianas empresas para
medir MQ. : Rendimiento del servicio, almacenamiento de datos, arquitectura de clúster
Ventajas: API enriquecida
Desventajas: su rendimiento no puede mantenerse al día con escenarios de aplicaciones como alta concurrencia y big data. ActiveMQ parece impotente.
2 Kafka
Kafka es el sistema de mensajería de publicación-suscripción distribuida de código abierto de LinkedIn, que actualmente pertenece al principal proyecto de Apache. Se caracteriza por procesar el consumo de mensajes basado en el modo Pull, persiguiendo un alto rendimiento, y su propósito de diseño es la recolección y transmisión de registros. La versión 0.8 comienza a admitir la replicación, pero no admite transacciones. No existen requisitos estrictos para la duplicación, pérdida, error, etc. de mensajes, lo cual es adecuado para negocios de recopilación de datos de servicios de Internet que producen grandes cantidades de datos.
Ventajas: alto rendimiento (millones por segundo)
Desventajas: no admite transacciones, la confiabilidad de los datos no es muy alta
3 RocketMQ
RocketMQ es el middleware de mensajería de código abierto de Ali, que ha sido incubado como un proyecto Apache de alto nivel, está desarrollado en Java puro y tiene las características de alto rendimiento, alta disponibilidad y adecuado para aplicaciones de sistemas distribuidos a gran escala. La idea de RocketMQ se origina en Kafka, que optimiza la transmisión confiable y las propiedades transaccionales de los mensajes. En la actualidad, se usa ampliamente en escenarios como transacciones, recarga, computación de transmisión, envío de mensajes, transmisión de registros, distribución de binglog, etc.
Ventajas: alto rendimiento, transacciones de soporte, soporte para big data distribuido
Desventajas: el mantenimiento requiere profesionales, la versión comercial cobra
4 RabbitMQ
RabbitMQ es un sistema de cola de mensajes de código abierto desarrollado con lenguaje Erlang e implementado en base al protocolo AMQP. Las principales características de AMQP son la orientación a mensajes, la cola, el enrutamiento (incluido el punto a punto y la publicación / suscripción), la confiabilidad y la seguridad. El protocolo AMQP se usa más en sistemas empresariales, donde la consistencia, estabilidad y confiabilidad de los datos son muy altas, y los requisitos de rendimiento y rendimiento siguen siendo secundarios.
Ventajas: rendimiento moderado, alta estabilidad y fiabilidad.