1. Introducción
ActivoMQ :
ActiveMQ es un intermediario de mensajes de código abierto desarrollado por Apache Software Foundation basado en el lenguaje Java e implementa JMS.
ConejoMQ :
RabbitMQ es un software de intermediación de mensajes de código abierto (también conocido como middleware orientado a mensajes) que implementa el protocolo avanzado de cola de mensajes (AMQP). El servidor RabbitMQ está escrito en el lenguaje Erlang, mientras que la agrupación en clústeres y la conmutación por error se basan en el marco de la plataforma abierta de telecomunicaciones. Todos los lenguajes de programación principales tienen bibliotecas cliente que se comunican con interfaces proxy. RabbitMQ admite múltiples protocolos de mensajería, confirmaciones de entrega y otras funciones.
Kafka :
Apache Kafka es un proyecto de sistema de mensajería de código abierto desarrollado por Apache Software Foundation y escrito en Scala.
Kafka fue desarrollado originalmente por LinkedIn y de código abierto a principios de 2011. Graduado de Apache Incubator en octubre de 2012.
El objetivo de este proyecto es proporcionar una plataforma unificada, de alto rendimiento y baja latencia para procesar datos en tiempo real. Kafka es un servicio de envío de registros distribuido, particionado y de múltiples réplicas. Proporciona la funcionalidad de un sistema de mensajería a través de un diseño único.
RocketMQ :
Apache RocketMQ es una plataforma de transmisión y mensajería distribuida con baja latencia, gran consistencia, alto rendimiento y confiabilidad, capacidad a teraescala y escalabilidad flexible. Toma prestadas ideas de diseño de Kafka, pero no es una copia de Kafka. Implementado en base a JMS.
Púlsar :
Apache Pulsar es el proyecto principal de Apache Software Foundation. Es una plataforma de flujo de mensajes distribuidos nativa de la nube de próxima generación que integra mensajería, almacenamiento y computación funcional liviana. Está diseñada con una separación de arquitectura de computación y almacenamiento. Admite almacenamiento persistente, multiinquilino y replicación de datos entre regiones en salas de máquinas múltiples. Tiene características de almacenamiento de datos en streaming como consistencia fuerte, alto rendimiento, baja latencia y alta escalabilidad. Se considera como el mensaje en tiempo real. transmisión de streaming y almacenamiento en la era nativa de la nube y calcule la solución óptima.
Para una introducción más detallada, lea el documento: " Comparación de colas de mensajes RabbitMQ, RocketMQ, Kafka y Pulsar "
2. Comparación de funciones y rendimiento
- modelo push-pull de consumo
De la misma manera que los consumidores obtienen mensajes, Kafka y RocketMQ extraen mensajes a través de encuestas largas. Pull, RabbitMQ, Pulsar y NSQ usan Push.
La cola de mensajes de tipo pull es más adecuada para escenarios de alto rendimiento, ya que permite a los consumidores controlar su propio flujo y obtener mensajes en función de sus capacidades de consumo reales. La cola de mensajes de tipo push tiene un mejor rendimiento en tiempo real, pero necesita una buena estrategia de control de flujo (contrapresión). Cuando la capacidad de consumo del consumidor es insuficiente, la cantidad de consumo push se puede reducir para evitar abrumar al consumidor.
- cola de retraso
Entrega retrasada de mensajes: cuando un mensaje se genera y se entrega a la cola de mensajes, algunos escenarios comerciales no quieren que los consumidores reciban el mensaje inmediatamente, sino que esperen un período de tiempo específico antes de que el consumidor pueda recibir el mensaje para su consumo. Las colas de retraso generalmente se dividen en dos tipos: retraso basado en mensajes y retraso basado en cola. El retraso basado en mensajes se refiere a establecer un tiempo de retraso diferente para cada mensaje. Cuando nuevos mensajes ingresan a la cola, se ordenan según el tiempo de retraso. Por supuesto, esto tendrá un mayor impacto en el rendimiento. Otro tipo de retraso basado en colas se refiere a la configuración de colas con diferentes niveles de retraso. El tiempo de retraso de cada mensaje en la cola es el mismo, lo que evita la pérdida de rendimiento causada por la clasificación según el tiempo de retraso. A través de una determinada estrategia de escaneo, Se puede entregar el mensaje con tiempo de espera agotado.
Los escenarios de uso para mensajes retrasados incluyen reintentos de detección de anomalías, cancelación de tiempo de espera de pedido, etc., por ejemplo:
- Si la solicitud de servicio es anormal, la solicitud anormal debe colocarse en una cola separada y volver a intentarse después de 5 minutos;
- El usuario compra bienes pero aún no ha pagado. Se le debe recordar que pague periódicamente y el pedido se cerrará cuando expire el tiempo de espera;
- Para una cita de entrevista o reunión, envíe una notificación para recordarle nuevamente media hora antes de que comience la entrevista o reunión.
Kafka no admite mensajes retrasados. Pulsar admite mensajes retrasados de segundo nivel. Todos los mensajes de entrega retrasados serán registrados por el Rastreador de mensajes retrasados con el índice correspondiente. Cuando el consumidor consume, primero irá al Rastreador de mensajes retrasados para verificar si hay algún mensaje caducado que deba ser entregado. Si hay algún mensaje caducado, saque el índice correspondiente del Tracker, busque el mensaje correspondiente y consúmalo. Si no hay ningún mensaje caducado, consuma el mensaje normal directamente. Para los mensajes de retraso a largo plazo, se almacenarán en el disco y se cargarán en la memoria cuando se acerque el intervalo de retraso.
Los mensajes retrasados de la versión de código abierto de RocketMQ se almacenan temporalmente en un tema interno, no admiten precisión de tiempo arbitraria y admiten niveles específicos, como sincronización de 5 segundos, 10 segundos, 1 m, etc.
RabbitMQ necesita instalar un complemento Rabbitmq_delayed_message_exchange.
NSQ guarda los mensajes retrasados a través de una cola de prioridad en la memoria, lo que admite precisión de segundo nivel y hasta 2 horas de retraso.
- cola de mensajes fallidos
Debido a algunas razones, el mensaje no se puede entregar correctamente. Para garantizar que el mensaje no se descarte sin ningún motivo, generalmente se coloca en una cola con una función especial, que generalmente se denomina cola de mensajes no entregados. En correspondencia con esto, también existe el concepto de "cola de reversión". Imagine que si ocurre una excepción cuando el consumidor consume, entonces el consumo no se confirmará (Ack) y el mensaje nunca estará disponible después de la operación de reversión. El mensaje se colocará en la parte superior de la cola y luego se procesará y revertirá continuamente, lo que provocará que la cola caiga en un bucle infinito. Para resolver este problema, puede configurar una cola de reversión para cada cola, que tanto ella como la cola de mensajes no entregados proporcionan una garantía de mecanismo para el manejo de excepciones. En situaciones reales, la cola de mensajes no entregados y la cola de reintentos pueden desempeñar el papel de la cola de reversión.
Kafka no tiene una cola de mensajes fallidos y registra la compensación del consumo actual a través de Offset.
Pulsar tiene un mecanismo de reintento. Cuando los consumidores consumen algunos mensajes por primera vez y no reciben una respuesta normal, ingresarán al tema de reintento. Cuando los reintentos alcancen un cierto número de veces, dejarán de reintentar y entregarán al Tema de letra muerta medio.
RocketMQ usa DLQ para registrar todos los mensajes de falla de consumo.
RabbitMQ implementa una cola de mensajes fallidos de forma similar a una cola de retraso.
NSQ no tiene una cola de mensajes fallidos.
- cola de prioridad
La cola de prioridad es diferente de la cola de primero en entrar, primero en salir: los mensajes con alta prioridad tienen el privilegio de consumirse primero, lo que puede proporcionar garantías posteriores de diferentes niveles de mensajes. Sin embargo, esta prioridad también necesita una premisa: si la velocidad de consumo del consumidor es mayor que la velocidad del productor y no hay acumulación de mensajes en el servidor de middleware de mensajes (generalmente llamado simplemente Broker), entonces establezca la prioridad para los mensajes enviados. No hay significado sustancial, porque el consumidor consume un mensaje tan pronto como el productor lo envía, lo que significa que hay como máximo un mensaje en el Broker y la prioridad de un solo mensaje no tiene sentido.
Kafka, RocketMQ, Pulsar y NSQ no admiten colas de prioridad y la prioridad de los mensajes se puede lograr a través de diferentes colas.
RabbitMQ admite mensajes prioritarios.
- Rastreo de mensajes
Generalmente, los mensajes se procesan una vez que se completa el consumo y el mensaje ya no se puede consumir. El seguimiento de mensajes es todo lo contrario: significa que una vez consumido el mensaje, el mensaje consumido anteriormente aún se puede consumir. Para los mensajes, un problema común es la "pérdida de mensajes". Generalmente es difícil rastrear si realmente se perdió debido a defectos en el middleware de mensajes o debido a un mal uso por parte del usuario. Si el middleware de mensajes en sí tiene una función de rastreo de mensajes, usted puede reproducir los mensajes "perdidos" rastreando el consumo para descubrir el origen del problema. La función del seguimiento de mensajes va mucho más allá, como la recuperación de índices y la reconstrucción de caché local. Algunas soluciones de compensación empresarial también se pueden implementar mediante el seguimiento.
Kafka admite el seguimiento de mensajes y puede restablecer la compensación del consumidor según la marca de tiempo o la compensación especificada para que se pueda consumir repetidamente.
Pulsar admite el seguimiento de mensajes por tiempo.
RocketMQ admite el retroceso en el tiempo y el principio de implementación es coherente con Kafka.
RabbitMQ no admite el seguimiento, los mensajes se marcarán para su eliminación una vez marcados para su confirmación.
Los mensajes generales de NSQ no se pueden rastrear, pero puede usar la herramienta nsq_to_file para escribir mensajes en un archivo y luego reproducirlos desde el archivo.
- Persistencia de mensajes
La reducción de picos de tráfico es una función muy importante del middleware de mensajes y esta función en realidad se beneficia de su capacidad de acumulación de mensajes. En cierto sentido, si un middleware de mensajes no tiene la capacidad de acumular mensajes, entonces no puede considerarse como un middleware de mensajes calificado. La acumulación de mensajes se divide en acumulación de memoria y acumulación de disco. En términos generales, la capacidad del disco será mucho mayor que la capacidad de la memoria. Para el apilamiento de tipo disco, la capacidad de apilamiento es el tamaño de todo el disco. Desde otra perspectiva, la acumulación de mensajes también proporciona funciones de almacenamiento redundantes para el middleware de mensajes.
Kafka y RocketMQ descargan mensajes directamente en archivos de disco para lograr persistencia, y todos los mensajes se almacenan en el disco. Siempre que la capacidad del disco sea suficiente, se puede lograr una acumulación ilimitada de mensajes.
RabbitMQ es una pila en memoria típica, pero esto no es absoluto. Después de que se activen ciertas condiciones, habrá una acción de paginación para paginar los mensajes en la memoria al disco (la acción de paginación afectará el rendimiento), o usará directamente una Cola diferida para paginar los mensajes en la memoria al disco. Los mensajes se conservan directamente en el disco.
Los mensajes de Pulsar se almacenan en el clúster de almacenamiento de BookKeeper y también son archivos de disco.
NSQ escribe mensajes en archivos a través de la herramienta nsq_to_file.
- Mecanismo de confirmación de mensaje
La cola de mensajes necesita gestionar el progreso del consumo y confirmar si el consumidor procesa correctamente el mensaje. El componente de la cola de mensajes que utiliza el método push a menudo confirma un solo mensaje. Para los mensajes no confirmados, se realiza una reenvío retrasado o la entrada a la cola de mensajes no entregados. .
Kafka confirma el mensaje a través de Offset.
RocketMQ, al igual que Kafka, también envía Offset. La diferencia es que los consumidores pueden marcar los mensajes que no se consumen como errores de consumo de mensajes. El corredor volverá a intentar la entrega. Si se acumulan varios errores de consumo, se entregarán a la cola de mensajes no entregados.
RabbitMQ es similar a NSQ: el consumidor confirma un solo mensaje; de lo contrario, volverá a la cola para esperar la próxima entrega.
Pulsar utiliza una gestión de cursor especializada. La confirmación acumulativa tiene el mismo efecto que Kafka: se proporciona una confirmación única o selectiva.
- Mensaje TTL
El mensaje TTL indica el tiempo de supervivencia de un mensaje. Si ningún consumidor consume el mensaje dentro del tiempo TTL después de enviarlo, la cola de mensajes lo eliminará o lo colocará en la cola de mensajes no entregados.
Kafka elimina mensajes según el período de retención establecido. Es posible que el mensaje no se haya consumido y se haya eliminado después de su vencimiento. TTL no es compatible.
Pulsar admite TTL; si ningún consumidor consume el mensaje dentro del período TTL configurado, el mensaje se marcará automáticamente como reconocido. La diferencia entre el período de retención de mensajes y el TTL de mensajes es que el período de retención de mensajes se aplica a los mensajes marcados como reconocidos y configurados para eliminarse, mientras que el TTL se aplica a los mensajes que no se confirman. TTL en Pulsar se ilustra en la leyenda de arriba. Por ejemplo, si la suscripción B no tiene consumidores activos, el mensaje M10 se marcará automáticamente como reconocido después de que haya transcurrido el período TTL configurado, aunque ningún consumidor haya leído realmente el mensaje.
RocketMQ tiene relativamente poca información sobre mensajes TTL, pero la interfaz parece admitirlo.
RabbitMQ tiene dos métodos: uno es configurarlo en las propiedades de la cola al declarar la cola, y los mensajes en toda la cola tienen el mismo período de validez. También puede establecer atributos para el mensaje al enviarlo y establecer un TTL diferente para cada mensaje.
NSQ no parece ser compatible todavía y hay un problema de solicitud de función en el estado Abierto.
- Aislamiento multiinquilino
La tenencia múltiple se refiere a la capacidad de atender a múltiples inquilinos a través de una única instancia de software. Un inquilino es un grupo de usuarios que tienen la misma "vista" del sistema. En sistemas que no admiten múltiples inquilinos, a menudo es necesario crear múltiples instancias de colas de mensajes para diferentes usuarios o diferentes clústeres para lograr el aislamiento físico, lo que generará altos costos de operación y mantenimiento. Como sistema de mensajería de nivel empresarial, las capacidades multiinquilino de Pulsar están diseñadas para cumplir con los siguientes requisitos:
- Asegúrese de que los estrictos SLA se puedan cumplir sin problemas.
- Garantizar el aislamiento entre los diferentes inquilinos.
- Hacer cumplir cuotas sobre la utilización de recursos.
- Proporciona seguridad por inquilino y a nivel de sistema.
- Garantice una operación y mantenimiento de bajo coste y una gestión lo más sencilla posible.
Pulsar satisface las necesidades anteriores de las siguientes maneras:
- Obtenga la seguridad que necesita con autenticación, autorización y ACL (listas de control de acceso) para cada inquilino.
- Aplique cuotas de almacenamiento por inquilino.
Todos los mecanismos de aislamiento se definen en forma de políticas, que se pueden cambiar durante la operación, lo que reduce los costos de operación y mantenimiento y simplifica la administración.
- secuencia de mensajes
La secuencialidad de los mensajes se refiere a garantizar que los mensajes estén en orden. El orden de consumo de mensajes es coherente con el orden de producción.
Kafka garantiza que los mensajes dentro de la partición estén ordenados.
Pulsar admite dos modos de consumo: el modo de transmisión de suscripción exclusiva solo garantiza el orden de los mensajes y el modelo de cola de suscripción compartida no garantiza el orden.
RocketMQ necesita usar bloqueos para garantizar que una cola tenga solo un hilo de consumidor consumiendo al mismo tiempo para garantizar el orden de los mensajes.
RabbitMQ tiene condiciones secuenciales estrictas, que requieren envío y consumo de un solo subproceso, y no utiliza funciones avanzadas como colas de retraso y colas de prioridad.
NSQ utiliza el propio case/select de golang para implementar la distribución de mensajes, no proporciona garantías de pedido, no puede hacer coincidir mensajes característicos con los consumidores y no puede lograr el orden de mensajes.
- Consulta de mensaje
En el desarrollo real, a menudo es necesario verificar el contenido de los mensajes en MQ, como consultar mensajes específicos de MQ a través de una determinada clave de mensaje/ID. O puede rastrear el enlace del mensaje para saber de dónde viene el mensaje y dónde se envía, de modo que pueda solucionar y localizar el problema rápidamente.
La capa de almacenamiento de Kafka se implementa en forma de un registro de confirmación distribuido, y cada operación de escritura se agrega secuencialmente al final del registro. La lectura también es lectura secuencial. La función de búsqueda no es compatible.
Pulsar puede consultar el contenido del mensaje, los parámetros del mensaje y la trayectoria del mensaje de un mensaje específico a través del ID del mensaje.
RocketMQ admite la consulta de mensajes por clave de mensaje, clave única e ID de mensaje.
RabbitMQ utiliza un sistema de almacenamiento basado en índices. Estos guardan los datos en una estructura de árbol para proporcionar el acceso rápido necesario para confirmar mensajes individuales. Dado que los mensajes de RabbitMQ se eliminarán después de la confirmación, solo se pueden consultar los mensajes no confirmados.
NSQ en sí no admite la persistencia ni la recuperación de mensajes, pero puede usar herramientas como nsq_to_http para escribir mensajes en un almacenamiento que admita la indexación.
- patrón de consumo
Kafka tiene dos modos de consumo, que en última instancia garantizarán que solo un consumidor consuma una partición:
- Método de suscripción: cuando cambia el número de particiones de temas o el número de consumidores, se realizará el reequilibrio; al registrar un oyente de reequilibrio, puede administrar manualmente el desplazamiento sin registrar un oyente, y Kafka lo administrará automáticamente.
- Método de asignación: asigne manualmente al consumidor a la partición y Kafka no realizará rebanance.
Pulsar tiene los siguientes cuatro modos de consumo: el modo exclusivo y el modo de recuperación ante desastres son similares a Kafka, son modelos de flujo y cada partición tiene solo un consumo de consumidor, lo que puede garantizar el orden de los mensajes. El modo de compartir y el modo de compartir claves son modelos de cola: varios consumidores pueden aumentar la velocidad de consumo, pero no pueden garantizar el orden.
- Modo exclusivo exclusivo (modo predeterminado): una suscripción solo se puede asociar con un consumidor. Solo este consumidor puede recibir todos los mensajes del tema. Si el consumidor falla, el consumo se detendrá.
- Modo de recuperación ante desastres (conmutación por error): cuando hay varios consumidores, se ordenarán en el orden del diccionario y el primer consumidor se inicializará como el único consumidor que recibirá mensajes. Cuando el primer consumidor se desconecta, todos los mensajes (no reconocidos y posteriormente entrantes) se distribuirán al siguiente consumidor de la cola.
- Modo compartido (compartido): los mensajes se distribuyen a diferentes consumidores a través de un mecanismo de sondeo por turnos (que también se puede personalizar), y cada mensaje solo se distribuirá a un consumidor. Cuando un consumidor se desconecta, todos los mensajes no reconocidos que se le envíen serán reprogramados y distribuidos a otros consumidores supervivientes.
- Modo de compartir CLAVE (Key_Shared): cuando hay varios consumidores, los mensajes se distribuirán según la clave, los mensajes con la misma clave solo se distribuirán al mismo consumidor.
RocketMQ tiene dos modos de consumo, el modo de transmisión BROADCASTING y el modo de clúster CLUSTERING.
El consumo de transmisión se refiere a: un mensaje es consumido por múltiples consumidores. Incluso si estos consumidores pertenecen al mismo grupo de consumidores, el mensaje será consumido una vez por cada consumidor en el grupo de consumidores. El concepto de grupo de consumidores en el consumo de transmisión puede considerarse sin sentido en términos de división de mensajes.
Modo de consumo de clúster: las instancias de consumidores en un ConsumerGroup comparten uniformemente los mensajes consumidos. Por ejemplo, un tema tiene 9 mensajes y uno de ConsumerGroup tiene 3 instancias (tal vez 3 procesos o 3 máquinas), luego cada instancia solo consume parte de ellos y los mensajes consumidos no pueden ser consumidos por otras instancias.
El consumo de RabbitMQ y NSQ es similar, son similares al modo de compartir Pulsar. En forma de cola, aumentar el número de consumidores en un grupo de consumidores puede aumentar la velocidad de consumo.
- confiabilidad del mensaje
La pérdida de mensajes es un problema común al que se debe enfrentar cuando se utiliza el middleware de mensajes. Detrás de él, la confiabilidad del mensaje también es un factor clave para medir la calidad del middleware de mensajes. Especialmente en el ámbito de los pagos financieros, la fiabilidad de los mensajes es especialmente importante. Por ejemplo, cuando falla un servicio, ¿se perderán algunos mensajes que el productor haya producido exitosamente durante la conmutación de alta disponibilidad? El vaciado sincrónico es una forma efectiva de mejorar la confiabilidad de un componente, y el middleware de mensajes no es una excepción. Tanto Kafka como RabbitMQ pueden admitir el vaciado sincrónico, pero en la mayoría de los casos, la confiabilidad de un componente no debe determinarse mediante el vaciado sincrónico. utilizando operaciones que consumen mucho rendimiento para garantizarlo, se utiliza un mecanismo de copia múltiple para garantizarlo.
Kafka puede establecer el nivel de confiabilidad configurando el parámetro request.required.acks, que indica cuántas copias de un mensaje deben confirmar la recepción exitosa antes de que la tarea lo envíe correctamente.
- request.required.acks=-1 (Confirmación completamente sincrónica, sólida garantía de confiabilidad)
- request.required.acks=1 (el líder confirma el recibo, predeterminado)
- request.required.acks=0 (sin confirmación, pero alto rendimiento)
Pulsar tiene un concepto similar a Kafka, llamado Ack Quorum Size (Qa). Qa es el número de Bookies que deben ser confirmados mediante una respuesta después de enviar cada solicitud de escritura. Cuanto mayor sea el valor, más tiempo llevará confirmar que el la escritura es exitosa Su valor El límite superior es el número de copias Qw. Por coherencia, Qa debe ser (Qw+1)/2 o más, es decir, para garantizar la seguridad de los datos, el límite inferior de Qa es (Qw+1)/2.
RocketMQ es similar a Kafka.
RabbitMQ es una arquitectura maestro-esclavo que implementa copias múltiples y una semántica de coherencia sólida a través de colas de anillo reflejadas. Varias copias pueden garantizar que después de que el nodo maestro caiga de manera anormal, el esclavo pueda ser promovido como el nuevo maestro y continuar brindando servicios para garantizar la disponibilidad.
NSQ almacenará mensajes en archivos locales a través del componente go-diskqueue y controlará el tamaño de la cola en la memoria a través del parámetro mem-queue-size. Si mem-queue-size = 0, cada mensaje se almacenará en el disco y allí No hay necesidad de preocuparse por los reinicios de los nodos, lo que provocaría la pérdida de mensajes. Sin embargo, dado que se almacena en el disco local, si el nodo se desconecta, los mensajes acumulados en el disco del nodo se perderán.