Los componentes de MQ más utilizados son ActiveMQ, RabbitMQ, RocketMQ, ZeroMQ, MetaMQ, Kafka. Por supuesto, Kafka es más poderoso. Aunque diferentes MQ tienen sus propias características y ventajas, no importa qué tipo de MQ, hay algunas características de MQ en sí. A continuación, presentaré las características de MQ.
| característica | Activo | RabbitMQ | RocketMQ | Kafka |
| Lenguaje de desarrollo | Java | Erlang | Java | Scala |
| Haga clic en Rendimiento | Diez mil | Diez mil | Cien mil | Cien mil |
| Oportunidad | nivel ms | nivel de nosotros (microsegundos) | nivel ms | Dentro de ms |
| Disponibilidad | Alto (arquitectura maestro-esclavo) | Alto (arquitectura maestro-esclavo) | Muy alto (arquitectura distribuida) | Muy alto (arquitectura distribuida) |
| Caracteristicas | Los productos maduros, utilizados en muchas empresas, tienen muchos documentos maduros y admiten varios protocolos. | Simultaneidad sólida, rendimiento extremadamente bueno, latencia extremadamente baja y una interfaz de administración rica | La función MQ es relativamente completa, fuerte escalabilidad | Solo se admiten las funciones principales de MQ y no se proporcionan funciones como la consulta de algunos mensajes y el retroceso de mensajes. Después de todo, se proporciona para big data, que se utiliza ampliamente en el campo de big data. |
Selección de middleware
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 Apache. La característica principal de Kafka es procesar mensajes según el modo Pull . Los mensajes están en orden. Mediante el control, puede garantizar que todos los mensajes se consuman y solo una vez. Persigue un alto rendimiento . El propósito inicial es utilizarlos para la recopilación y transmisión de registros . Admite replicación y transacciones, y no tiene requisitos estrictos sobre duplicación, pérdida y error de mensajes . Es adecuado para servicios de recopilación de datos para servicios de Internet que generan grandes cantidades de datos. El sistema completamente distribuido, el agente, el productor, el consumidor, todos admiten de forma nativa y automática la distribución y realizan automáticamente el equilibrio de carga. Admite la carga paralela de datos de Hadoop. Esta es una solución factible para datos de registro y sistemas de análisis fuera de línea como Hadoop, pero requiere limitaciones de procesamiento en tiempo real. Kafka utiliza el mecanismo de carga paralela de Hadoop para unificar el procesamiento de mensajes en línea y fuera de línea, que también es valorado por el sistema estudiado en este tema. Comparado con ActiveMQ, Apache Kafka es un sistema de mensajería muy ligero, además de muy buen rendimiento, también es un sistema distribuido que funciona bien. Enlace de publicación de blog detallado
Kafka, conocido como el asesino de los macrodatos, no puede pasarse por alto cuando se trata de la transmisión de mensajes en el campo de los macrodatos. Este middleware de mensajes nació para los macrodatos, con su TPS de millones de niveles (una sola máquina escribe alrededor de un millón de TPS) / Seg ) es famoso y se ha convertido rápidamente en el favorito del campo de los macrodatos, desempeñando un papel fundamental en el proceso de recopilación, transmisión y almacenamiento de datos. La disponibilidad es muy alta. Kafka está distribuido, con múltiples copias de un solo dato, y un pequeño número de máquinas están inactivas. No se perderán datos o no estarán disponibles. Hay una excelente interfaz de administración Kafka Web de terceros, Kafka-Manager .
Desventajas: ① Si Kafka tiene más de 64 colas / particiones en una sola máquina, la carga aumentará significativamente, cuantas más colas, mayor será la carga y mayor será el tiempo de respuesta para enviar mensajes. ② Utilice el modo de sondeo corto y el rendimiento en tiempo real depende del intervalo de sondeo. ③Reintentar no es compatible para fallas de consumo. ④Se admite el orden de los mensajes, pero cuando un agente deja de funcionar, el orden de los mensajes estará desordenado . ⑤ La comunidad se actualiza lentamente.
RabbitMQ
RabbitMQ es un sistema de cola de mensajes de código abierto desarrollado con lenguaje Erlang, que admite muchos protocolos AMQP , XMPP, SMTP y STOMP. 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 para que se vuelva muy pesado, es más adecuado para el desarrollo de enrutamiento a nivel empresarial (enrutamiento), equilibrio de carga (equilibrio de carga), consistencia de datos , estabilidad y confiabilidad de escenarios de alta demanda , rendimiento y El requisito de rendimiento es el segundo. Robusto, estable, fácil de usar, multiplataforma, compatible con varios idiomas, documentación completa. La interfaz de administración proporcionada por el código abierto es excelente y fácil de usar. La comunidad es muy activa. Enlace de publicación de blog detallado
Desventajas: ① Desarrollo de Erlang, es difícil entender el código fuente Las funciones básicas dependen del rápido mantenimiento y corrección de errores de la comunidad de código abierto, que no favorece el desarrollo y mantenimiento secundario. ② RabbitMQ tiene un rendimiento más bajo debido al mecanismo de implementación más pesado. ③Es necesario aprender interfaces y protocolos más complicados, y el costo de aprendizaje y mantenimiento es alto.
RocketMQ
RocketMQ es el middleware de mensajes de código abierto de Alibaba, 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 originó en Kafka e hizo algunas mejoras propias. Optimiza la transmisión confiable y las propiedades transaccionales de los mensajes. Actualmente se usa ampliamente en Alibaba Group para transacciones, recarga, computación de transmisión, envío de mensajes y procesamiento de transmisión de registros. , Distribución de Binglog y otros escenarios. La confiabilidad del mensaje es muy alta . Después de la configuración de optimización de parámetros, el mensaje puede lograr cero pérdidas. La función MQ es relativamente completa, está distribuida y tiene una buena escalabilidad. Admite mil millones de niveles de acumulación de mensajes , no causará degradación del rendimiento debido a la acumulación. El código fuente es Java, podemos leer el código fuente nosotros mismos, personalizar el MQ de nuestra empresa y controlarlo.
Nacido en el campo de la Internet financiera, tiene altos requisitos de confiabilidad , especialmente en las deducciones de pedidos de comercio electrónico y recortes de picos comerciales. Cuando una gran cantidad de transacciones se inunda, es posible que el back-end no pueda manejar la situación a tiempo. RoketMQ puede ser más confiable en términos de estabilidad Estos escenarios comerciales se han probado muchas veces en Alibaba Double 11. Si su empresa tiene los escenarios de concurrencia anteriores, se recomienda elegir RocketMQ.
Desventajas: ① No hay muchos lenguajes de cliente compatibles, actualmente Java y C ++, de los cuales C ++ es inmaduro. ②La actividad comunitaria es media. ③No hay una interfaz como JMS implementada en el núcleo de MQ y algunos sistemas necesitan modificar una gran cantidad de código para migrar.
ZeroMQ
Conocido como el sistema de cola de mensajes más rápido, especialmente para escenarios de demanda de alto rendimiento. ZMQ puede implementar colas avanzadas / complejas en las que RabbitMQ no es bueno, pero los desarrolladores necesitan combinar múltiples marcos técnicos por sí mismos.La complejidad técnica es un desafío para la aplicación exitosa de MQ. ZeroMQ tiene un modelo único que no es middleware, no necesita instalar y ejecutar un servidor de mensajes o middleware, porque su aplicación desempeñará esta función de servicio. Solo necesita hacer referencia a la biblioteca ZeroMQ, que se puede instalar usando NuGet, y luego puede enviar mensajes entre aplicaciones. Pero ZeroMQ solo proporciona colas no persistentes, lo que significa que si la máquina no funciona, los datos se perderán. Entre ellos, Storm de Twitter utiliza ZeroMQ como transmisión de flujo de datos.
ActiveMQ
Apache ActiveMQ es rápido, admite muchos clientes y protocolos en varios idiomas, tiene un modo de integración empresarial fácil de usar y muchas funciones avanzadas, y es totalmente compatible con JMS 1.1 y J2EE 1.4. Apache ActiveMQ se publica bajo la licencia Apache 2.0. Existe una baja probabilidad de perder datos. Enlace de publicación de blog detallado
Desventajas: la comunidad oficial ahora mantiene cada vez menos ActiveMQ 5.xy se usa menos en escenarios de rendimiento a gran escala .
Redis
Es una base de datos NoSQL de Key-Value, su desarrollo y mantenimiento son muy activos, aunque es un sistema de almacenamiento de base de datos de Key-Value, soporta la función MQ, por lo que se puede utilizar como un servicio de cola ligero. Las operaciones de poner y quitar de cola de RabbitMQ y Redis se ejecutan 1 millón de veces cada una, y el tiempo de ejecución se registra cada 100.000 veces. Los datos de prueba se dividen en cuatro tamaños diferentes de 128Bytes, 512Bytes, 1K y 10K. Los experimentos muestran que al ingresar al equipo, el rendimiento de Redis es superior al de RabbitMQ cuando los datos son relativamente pequeños, y si el tamaño de los datos excede los 10K, Redis es insoportablemente lento; al dejar el equipo, independientemente del tamaño de los datos, Redis muestra muy buen desempeño Y el rendimiento de eliminación de cola de RabbitMQ es mucho menor que el de Redis.
test de presión
Compare el rendimiento de Kafka, RabbitMQ, RocketMQ enviando mensajes (124 bytes). Para las pruebas de estrés, solo nos centramos en los indicadores de rendimiento del servidor, por lo que el estándar para las pruebas de estrés es aumentar continuamente la presión en el extremo de envío hasta que el rendimiento del sistema ya no aumente y el tiempo de respuesta se alargue. En este momento, el servidor tiene un cuello de botella de rendimiento y se puede obtener el mejor rendimiento del sistema correspondiente. En el escenario de envío síncrono, el rendimiento del middleware de tres mensajes se distingue claramente:
Kafka
El rendimiento de Kafka es tan alto como 17,3 w / s, y es el líder de la industria en middleware de mensajería de alto rendimiento . Esto depende principalmente de su modo de cola para garantizar que el proceso de escritura en el disco sea E / S lineal . En este momento, la E / S del disco Broker ha alcanzado el cuello de botella.
RocketMQ
RocketMQ también tuvo un buen desempeño, con un rendimiento de 11.6w / sy una E / S de disco cercana al 100%. Después de que el mensaje de RocketMQ se escriba en la memoria, devolverá un ack y un hilo separado hará la operación de parpadeo Todos los mensajes se escriben en el archivo secuencialmente .
RabbitMQ
El rendimiento de RabbitMQ es de 5,95 w / s y el consumo de recursos de la CPU es alto. Es compatible con el protocolo AMQP y es muy pesado. Para garantizar la confiabilidad del mensaje, ha hecho concesiones en el rendimiento. También hicimos una prueba de rendimiento de RabbitMQ en un escenario de persistencia de mensajes, y el rendimiento fue de alrededor de 2.6w / s.
Conclusión de la prueba: el rendimiento del envío síncrono es Kafka> RocketMQ> RabbitMQ
En términos de modelo de arquitectura
RabbitMQ
RabbitMQ sigue el protocolo AMQP El Broker de RabbitMQ se compone de Exchange, Binding y Queue, entre los cuales Exchange y Binding forman la clave de enrutamiento del mensaje. El Productor cliente se comunica con el Servidor conectándose al Canal, y el Consumidor obtiene mensajes de la Cola para consumo (conexión larga, los mensajes en la Cola se enviarán al Consumidor y el Consumidor lee cíclicamente los datos del flujo de entrada). RabbitMQ toma a Broker como centro y tiene un mecanismo de confirmación de mensajes.
Kafka
Kafka cumple con la estructura general de MQ, Productor, Broker, Consumer, con Consumer como el centro, en el Consumer Consumer donde se almacena la información de consumo del mensaje, y el Consumer extrae datos en lotes del Broker según el punto de consumo, sin un mecanismo de confirmación de mensaje.
En rendimiento
Kafka
Kafka tiene un alto rendimiento, utiliza internamente el procesamiento por lotes de mensajes , el mecanismo de copia cero , el almacenamiento y la adquisición de datos son operaciones por lotes secuenciales del disco local , con complejidad O (1) y la eficiencia del procesamiento de mensajes es muy alta.
RabbitMQ
RabbitMQ es ligeramente inferior a Kafka en términos de rendimiento. Su punto de partida es diferente. RabbitMQ admite la entrega confiable de mensajes , admite transacciones y no admite operaciones por lotes . Según el requisito de almacenamiento confiable , el almacenamiento puede usar memoria o disco duro .
En términos de usabilidad
RabbitMQ
RabbitMQ admite la cola del espejo, la cola principal falla y la cola del espejo se hace cargo.
Kafka
Broker de Kafka admite el modo activo y en espera.
En términos de equilibrio de carga del clúster
Kafka
Kafka usa Zookeeper para administrar agentes y consumidores en el clúster, y los temas se pueden registrar en Zookeeper. Mediante el mecanismo de coordinación de Zookeeper, el Productor guarda la información del Broker correspondiente al tema, la cual puede ser enviada al Broker de forma aleatoria o por encuesta. Y el Productor puede especificar fragmentos basándose en la semántica, y el mensaje se envía a un determinado fragmento del Broker.
RabbitMQ
El equilibrio de carga de RabbitMQ requiere un equilibrador de carga independiente para admitirlo.
para resumir
Rabbitmq es más confiable que Kafka y Kafka es más adecuado para el procesamiento de E / S de alto rendimiento, como la recopilación de registros ELK
Tanto Kafka como RabbitMq están diseñados para una implementación distribuida. Pero sus supuestos sobre la definición del modelo semántico del mensaje son muy diferentes. Soy escéptico con el argumento de que "AMQP es más maduro". Hablemos con hechos y veamos qué soluciones se utilizan para resolver su problema.
[1] Kafka es más adecuado para los siguientes escenarios. Tiene una gran cantidad de eventos (más de 100,000 / seg), necesita entregarlo exitosamente al menos una vez en un orden secuencial dividido a los consumidores que están mezclados con el consumo en línea y empaquetado, desea poder volver a leer el mensaje y puede aceptar el límite actual El nivel de nodo tiene una alta disponibilidad o no le importa obtener el soporte del software en la etapa inicial a través del foro / herramienta IRC.
[2] Es más adecuado utilizar RabbitMQ en los siguientes escenarios. Tiene menos eventos (más de 20.000 / seg) y necesita encontrar consumidores a través de una lógica de enrutamiento compleja, desea una entrega de mensajes confiable, no le importa el orden de entrega de los mensajes y necesita admitir nodos de clúster ahora El nivel de alta disponibilidad significa que necesita 7 * 24 horas de soporte pago (por supuesto, también puede usar la herramienta de foro / IRC).