Comparación de middleware de mensajes comunes

1. Comparación de Kafka, RabbitMQ y el middleware de mensajes Redis

En los sistemas distribuidos, el middleware de mensajes a menudo se usa para el intercambio de datos entre sistemas.
De acuerdo con los escenarios reales de demanda comercial y los costos de operación y mantenimiento, puede elegir el producto que más le convenga.

2. Introducción de conceptos relacionados.

• Kafka
  1. Basado en el modo Pull para procesar el consumo de mensajes
  2. Perseguir un alto rendimiento
  3. El propósito inicial es registrar la recopilación y transmisión La
  versión 4.0.8 comenzó a admitir la replicación, no admite transacciones, la duplicación de mensajes, la pérdida, los errores no son estrictos Negocio de recopilación de datos que requiere y es adecuado para servicios de Internet que generan grandes cantidades de datos.

• RabbitMQ
  RabbitMQ es un sistema de colas de mensajes de código abierto desarrollado utilizando el lenguaje Erlang e implementado basado en el protocolo AMQP.
  Las principales características de AMQP
  1. Orientado a mensajes, colas, enrutamiento (incluyendo punto a punto y publicación / suscripción), confiabilidad y seguridad
  2. El protocolo AMQP se usa más en sistemas empresariales, y los escenarios que requieren una alta consistencia, estabilidad y confiabilidad de los datos, y los requisitos de rendimiento y rendimiento son los segundos.
  Se utiliza principalmente en: dubbo framework (zookeeper se utiliza para el centro de registro), spring cloud, etc.

• Redis
  Redis es una base de datos NoSQL basada en pares clave-valor, y es muy activa en el desarrollo y mantenimiento,
  aunque es un sistema de almacenamiento de base de datos clave-valor, en sí mismo soporta funciones MQ, por lo que puede usarse como un servicio de cola ligero.

3. Comparación de características

1. En términos de escenarios de aplicación,
RabbitMQ cumple con el protocolo AMQP y está desarrollado por el lenguaje erlang con alta concurrencia interna. Se utiliza para mensajes en tiempo real con requisitos de alta confiabilidad.

Kafka es el sistema de suscripción de mensajes de código abierto de Linkedin en diciembre de 2010. Se utiliza principalmente para procesar datos de transmisión en vivo y grandes cantidades de datos.

2. En el modelo arquitectónico,
RabbitMQ sigue el protocolo AMQP. El intermediario de RabbitMQ consiste en Exchange, Binding y queue, donde el intercambio y el enlace forman la clave de enrutamiento del mensaje, el productor del cliente se comunica conectando el canal y el servidor, y el consumidor obtiene el mensaje de la cola Consumo (conexión larga, el mensaje de cola se enviará al lado del consumidor, el consumidor lee los datos de la secuencia de entrada en un bucle). rabbitMQ se centra en el intermediario; hay un mecanismo de confirmación de mensaje.

Kafka cumple con la estructura general de MQ, productor, corredor, consumidor, consumidor como centro, la información del consumidor del mensaje se guarda la información del consumidor, el consumidor extrae los datos masivos del corredor de acuerdo con el punto de consumo; sin mecanismo de confirmación del mensaje.

3. En términos
de rendimiento, Kafka tiene un alto rendimiento, el procesamiento por lotes interno de mensajes, el mecanismo de copia cero, el almacenamiento y la recuperación de datos son operaciones de lotes secuenciales de disco local, con complejidad O (1), eficiencia del procesamiento de mensajes Muy alto
RabbitMQ es ligeramente inferior al 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; en función de la confiabilidad de los requisitos de almacenamiento, el almacenamiento puede usar memoria o disco duro.

4. En términos de disponibilidad,
RabbitMQ admite la cola del espejo, la cola principal no es válida y la cola del espejo se hace cargo
del agente de kafka para admitir el modo activo y en espera

5. En términos de equilibrio de carga del clúster,
kafka utiliza zookeeper para gestionar los corredores y consumidores en el clúster, y puede registrar temas para zookeeper, a través del mecanismo de coordinación de zookeeper, el productor guarda la información del agente del tema correspondiente, que puede ser aleatoriamente o sondeada y enviada al corredor ; Y el productor puede especificar fragmentos basados ​​en la semántica, y el mensaje se envía a un fragmento en el intermediario.
El equilibrio de carga de RabbitMQ requiere un equilibrador de carga separado para admitirlo.

Cuatro, escenarios de aplicación

Rabbitmq es más confiable que kafka.
Kafka es más adecuado para el procesamiento de alto rendimiento de E / S. Por ejemplo, la recopilación de registros ELK Kafka y RabbitMq son intermediarios de mensajes de propósito general. Todos son para despliegue distribuido. Pero sus suposiciones sobre la definición del modelo semántico del mensaje son muy diferentes.

• En los siguientes escenarios, es más adecuado usar Kafka. Tiene una gran cantidad de eventos (más de 100,000 por segundo), necesita particionar, secuencialmente, al menos una entrega exitosa a los consumidores que combinan el consumo en línea y empaquetado, desea poder releer el mensaje, puede aceptar el límite actual El nivel de nodo está altamente disponible o no le importa obtener soporte del software que todavía está en los niños pequeños a través de herramientas de foro / IRC.

• En los siguientes escenarios, es más adecuado usar RabbitMQ. Tiene menos eventos (más de 20,000 / seg) y necesita encontrar consumidores a través de una lógica de enrutamiento compleja, desea que la entrega de mensajes sea confiable, no le importa el orden de entrega de mensajes, necesita admitir nodos de clúster ahora Alto nivel de disponibilidad o necesita 7 * 24 horas de soporte pagado (por supuesto, también puede usar la herramienta de foro / IRC)

• La inserción de mensajes de Redis (basada en publicación / sub distribuida) se utiliza principalmente para la inserción de mensajes en tiempo real y no garantiza la fiabilidad

La inserción de mensajes de Redis (basada en publicación / sub distribuida) se utiliza principalmente para la inserción de mensajes en tiempo real, y no garantiza la fiabilidad. Se garantiza que otros mq y kafka son confiables pero tienen algún retraso (los sistemas que no son en tiempo real no garantizan el retraso). Redis-pub / sub se vaciará cuando se apague la alimentación, y el uso de redis-list como envío de mensajes tiene persistencia, pero no es completamente confiable y no se perderá.

• Redis es una base de datos en memoria! El padre de Redis hizo un disque, ¿quieres probarlo? mq generalmente usa un modelo de publicación de suscripción. Si considera el rendimiento, el enfoque principal es si el modelo de consumo es pull o push. Lo más influyente debería ser la estructura de almacenamiento. El rendimiento de Kafka solo puede ser efectivo cuando el número de temas es inferior a 64. determinado por partición. Pérdida de mensajes en casos extremos, por ejemplo: después de que el maestro escribe el mensaje, la máquina host se cae y el disco duro está dañado