¿Hay alguna razón para usar RabbitMQ sobre Kafka?

Me pidieron que evaluara RabbitMQ en lugar de Kafka, pero me resultó difícil encontrar una razón por la que está haciendo algo mejor que Kafka. ¿Alguien sabe si es realmente mejor en rendimiento, durabilidad, latencia o facilidad de uso?

RabbitMQ es un agente de mensajes sólido de uso general que admite varios protocolos, como AMQP, MQTT, STOMP, etc. Puede manejar un alto rendimiento. Un caso de uso común para RabbitMQ es manejar trabajos en segundo plano o tareas de larga duración, como escaneo de archivos , escalado de imágenes o conversión de PDF. RabbitMQ también se usa entre microservicios, donde sirve como un medio de comunicación entre aplicaciones, evitando cuellos de botella que pasan mensajes.

Kafka es un bus de mensajes optimizado para flujos de datos de alto ingreso y reproducción. Use Kafka cuando tenga la necesidad de mover una gran cantidad de datos, procesar datos en tiempo real o analizar datos durante un período de tiempo. En otras palabras, donde los datos deben ser recopilados, almacenados y manejados. Un ejemplo es cuando desea realizar un seguimiento de la actividad del usuario en una tienda web y generar artículos sugeridos para comprar. Otro ejemplo es el análisis de datos para seguimiento, ingestión, registro o seguridad.

Kafka puede verse como un agente de mensajes duradero donde las aplicaciones pueden procesar y reprocesar datos transmitidos en el disco. Kafka tiene un enfoque de enrutamiento muy simple. RabbitMQ tiene mejores opciones si necesita enrutar sus mensajes de manera compleja a sus consumidores. Use Kafka si necesita admitir consumidores por lotes que podrían estar fuera de línea o consumidores que desean mensajes con baja latencia. 

Para entender cómo leer los datos de Kafka, primero debemos entender a sus consumidores y grupos de consumidores. Las particiones le permiten paralelizar un tema dividiendo los datos en múltiples nodos. Cada registro en una partición se asigna e identifica por su desplazamiento único. Este desplazamiento apunta al registro en una partición. En la última versión de Kafka, Kafka mantiene un desplazamiento numérico para cada registro en una partición. Un consumidor en Kafka puede confirmar automáticamente las compensaciones periódicamente o puede elegir controlar esta posición confirmada manualmente. RabbitMQ mantendrá todos los estados sobre mensajes consumidos / reconocidos / no reconocidos. Me parece que Kafka es más complejo de entender que el caso de RabbitMQ, donde el mensaje simplemente se elimina de la cola una vez que se ataca.

Las colas de RabbitMQ son más rápidas cuando están vacías, mientras que Kafka retiene grandes cantidades de datos con muy poca sobrecarga: Kafka está diseñada para contener y distribuir grandes volúmenes de mensajes. (Si planea tener colas muy largas en RabbitMQ, podría echar un vistazo a las colas diferidas ).

Kafka está construido desde cero con una escala horizontal (escala agregando más máquinas) en mente, mientras que RabbitMQ está diseñado principalmente para escala vertical (escala agregando más potencia).

RabbitMQ tiene una interfaz integrada fácil de usar que le permite monitorear y manejar su servidor RabbitMQ desde un navegador web. Entre otras cosas, se pueden manejar colas, conexiones, canales, intercambios, usuarios y permisos de usuario: creados, eliminados y enumerados en el navegador, y puede monitorear las tasas de mensajes y enviar / recibir mensajes manualmente. Kafka tiene una serie de herramientas de código abierto, y también algunas comerciales , que ofrecen funcionalidades de administración y monitoreo. Diría que es más fácil / más rápido obtener una buena comprensión de RabbitMQ.

Puede encontrar más lecturas y algunos datos de comparación aquí: https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html

También se recomienda el documento de la industria: "Kafka versus RabbitMQ: un estudio comparativo de dos implementaciones de publicación / suscripción de referencia de la industria": http://dl.acm.org/citation.cfm?id=3093908

Trabajo en una empresa que ofrece tanto Apache Kafka como RabbitMQ como servicio.

Escucho esta pregunta todas las semanas ... Mientras que RabbitMQ (como IBM MQ o JMS u otras soluciones de mensajería en general) se usa para la mensajería tradicional, Apache Kafka se usa como plataforma de transmisión (mensajería + almacenamiento distribuido + procesamiento de datos). Ambos están diseñados para diferentes casos de uso.

Puede usar Kafka para "mensajes tradicionales", pero no usar MQ para escenarios específicos de Kafka.

El artículo " Apache Kafka vs. Enterprise Service Bus (ESB): ¿amigos, enemigos o frenemies? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/ ) "explica por qué Kafka no es competitivo sino complementario a las soluciones de integración y mensajería (incluido RabbitMQ) y cómo integrar ambos.

5 Grandes diferencias entre Kafka y RabbitMQ, cliente que las usa:

¿Qué sistema de mensajería elegir o debemos cambiar nuestro sistema de mensajería existente?

No hay una respuesta a la pregunta anterior. Un enfoque posible a la revisión cuando se tiene que decidir qué sistema de mensajería o en caso de que el cambio del sistema existente es “ Evaluar el alcance y el costo ”

Una diferencia crítica que ustedes olvidaron es que RabbitMQ es un sistema de mensajería basado en inserción, mientras que Kafka es un sistema de mensajería basado en extracción. Esto es importante en el escenario en el que el sistema de mensajería tiene que satisfacer a diferentes tipos de consumidores con diferentes capacidades de procesamiento. Con el sistema basado en Pull, el consumidor puede consumir en función de su capacidad, donde los sistemas push enviarán los mensajes independientemente del estado del consumidor, poniendo así al consumidor en alto riesgo.

RabbitMQ es un agente de mensajes de propósito general tradicional. Permite a los servidores web responder rápidamente a las solicitudes y enviar mensajes a múltiples servicios. Los editores pueden publicar mensajes y ponerlos a disposición de las colas, para que los consumidores puedan recuperarlos. La comunicación puede ser asíncrona o síncrona.

Por otro lado, Apache Kafka no es solo un agente de mensajes. Inicialmente fue diseñado e implementado por LinkedIn para servir como una cola de mensajes. Desde 2011, Kafka ha sido de código abierto y evolucionó rápidamente en una plataforma de transmisión distribuida, que se utiliza para la implementación de canalizaciones de datos en tiempo real y aplicaciones de transmisión.

Es horizontalmente escalable, tolerante a fallas, rápido rápido y funciona en producción en miles de empresas.

Las organizaciones modernas tienen varias canalizaciones de datos que facilitan la comunicación entre sistemas o servicios. Las cosas se vuelven un poco más complicadas cuando un número razonable de servicios necesita comunicarse entre sí en tiempo real.

La arquitectura se vuelve compleja ya que se requieren diversas integraciones para permitir la comunicación entre estos servicios. Más precisamente, para una arquitectura que abarca m servicios de origen yn destino, se deben escribir nxm integraciones distintas. Además, cada integración viene con una especificación diferente, lo que significa que uno puede requerir un protocolo diferente (HTTP, TCP, JDBC, etc.) o una representación de datos diferente (Binario, Apache Avro, JSON, etc.), lo que hace que las cosas sean aún más desafiantes . Además, los servicios de origen podrían abordar el aumento de la carga de las conexiones que podrían afectar la latencia.

Apache Kafka conduce a arquitecturas más simples y manejables, al desacoplar las canalizaciones de datos. Kafka actúa como un sistema distribuido de alto rendimiento donde los servicios de origen envían flujos de datos, haciéndolos disponibles para los servicios de destino para extraerlos en tiempo real.

Además, muchas interfaces de usuario de código abierto y de nivel empresarial para administrar Kafka Clusters están disponibles ahora. Para obtener más detalles, consulte mis artículos Descripción general de las herramientas de monitoreo de la interfaz de usuario para los clústeres de Apache Kafka y ¿Por qué Apache Kafka?

La decisión de elegir RabbitMQ o Kafka depende de los requisitos de su proyecto. En general, si desea un intermediario de mensajes pub / sub simple / tradicional, elija RabbitMQ. Si desea construir una arquitectura basada en eventos sobre la cual su organización actuará en eventos en tiempo real, entonces elija Apache Kafka ya que proporciona más funcionalidad para este tipo de arquitectura (por ejemplo, Kafka Streams o ksqlDB).

Sé que es un poco tarde y tal vez ya lo dijiste indirectamente, pero nuevamente, Kafka no es una cola, es un registro (como alguien dijo anteriormente, basado en encuestas).

Para simplificar, el caso de uso más obvio cuando debería preferir RabbitMQ (o cualquier techno de cola) sobre Kafka es el siguiente:

Tiene varios consumidores consumiendo de una cola y siempre que haya un nuevo mensaje en la cola y un consumidor disponible, desea que se procese este mensaje. Si observa de cerca cómo funciona Kafka, notará que no sabe cómo hacerlo, debido a la escala de la partición, tendrá un consumidor dedicado a una partición y tendrá un problema de inanición. Problema que se evita fácilmente mediante el uso de tecno de cola simple. Puede pensar en usar un hilo que despache los diferentes mensajes de la misma partición, pero nuevamente, Kafka no tiene ningún mecanismo de reconocimiento selectivo.

Lo máximo que puede hacer es hacerlo como esos tipos e intentar transformar Kafka como una cola: https://github.com/softwaremill/kmq

Yannick

Use RabbitMQ cuando:

• No tiene que lidiar con Bigdata y prefiere una interfaz de usuario integrada conveniente para el monitoreo
• No hay necesidad de colas replicables automáticamente
• No hay múltiples suscriptores para los mensajes: dado que, a diferencia de Kafka, que es un registro, RabbitMQ es una cola y los mensajes se eliminan una vez consumidos y llega el reconocimiento
• Si tiene los requisitos para usar comodines y expresiones regulares para mensajes
• Si es importante definir la prioridad del mensaje

En resumen: RabbitMQ es bueno para casos de uso simples, con poco tráfico de datos, con el beneficio de la cola prioritaria y las opciones de enrutamiento flexibles. Para datos masivos y alto rendimiento, use Kafka.

Proporcionaré una respuesta objetiva basada en mi experiencia con ambos, también omitiré la teoría detrás de ellos, asumiendo que ya lo sabes y / u otras respuestas ya han proporcionado suficiente.

RabbitMQ : elegiría este si mis requisitos son lo suficientemente simples como para manejar la comunicación del sistema a través de canales / colas, la retención y la transmisión no son un requisito. Por ejemplo, cuando el sistema de fabricación construyó el activo, sí notifica al sistema de acuerdo que configure los contratos, etc.

Kafka : Requisito de abastecimiento de eventos principalmente, cuando es posible que deba lidiar con transmisiones (a veces infinitas), una gran cantidad de datos a la vez correctamente equilibrados, compensaciones de reproducción para garantizar un estado determinado, etc. Tenga en cuenta que esta arquitectura también aporta más complejidad, ya que incluye conceptos como temas / particiones / intermediarios / mensajes de lápidas, etc. como una importancia de primera clase.

El único beneficio que se me ocurre es la función Transaccional, el resto se puede hacer usando Kafka

Escalar ambos es difícil de una manera tolerante a fallas distribuidas, pero diría que es mucho más difícil a gran escala con RabbitMQ. No es trivial comprender Shovel, Federation, Mirrored Msg Queues, ACK, problemas con Mem, tolerancia a fallas, etc. Sin decir que no tendrá problemas específicos con Zookeeper, etc. en Kafka, pero hay menos partes móviles que manejar. Dicho esto, obtienes un intercambio Polyglot con RMQ que no con Kafka. Si quieres transmitir, usa Kafka. Si desea IoT simple o entrega de paquetes de alto volumen similar, use Kafka. Se trata de consumidores inteligentes. Si desea flexibilidad de mensajes y mayor confiabilidad con mayores costos y posiblemente algo de complejidad, use RMQ.

Si tiene necesidades de enrutamiento complejas y desea una GUI integrada para monitorear al agente, entonces RabbitMQ podría ser el mejor para su aplicación. De lo contrario, si está buscando un agente de mensajes para manejar el alto rendimiento y proporcionar acceso al historial de transmisión, Kafka es probablemente la mejor opción.

Apache Kafka es una opción popular para alimentar tuberías de datos. Apache kafka agregó flujo de kafka para admitir casos de uso de etl populares. KSQL simplifica la transformación de datos dentro de la tubería, preparando mensajes para aterrizar limpiamente en otro sistema. KSQL es el motor de transmisión de SQL para Apache Kafka. Proporciona una interfaz SQL interactiva fácil de usar pero potente para el procesamiento de flujo en Kafka, sin la necesidad de escribir código en un lenguaje de programación como Java o Python. KSQL es escalable, elástico, tolerante a fallas y en tiempo real. Admite una amplia gama de operaciones de transmisión, que incluyen filtrado de datos, transformaciones, agregaciones, uniones, ventanas y sesionización.

https://docs.confluent.io/current/ksql/docs/index.html

Rabbitmq no es una opción popular para los sistemas etl, sino para aquellos sistemas donde requiere sistemas de mensajería simples con menos rendimiento.

Me doy cuenta de que esta es una vieja pregunta, pero un escenario en el que RabbitMQ podría ser una mejor opción es cuando se trata de la redacción de datos.

Con RabbitMQ, por defecto, una vez que el mensaje se ha consumido, se elimina. Con Kafka, por defecto, los mensajes se guardan durante una semana. Es común establecer esto en un tiempo mucho más largo, o incluso nunca eliminarlos.

Si bien ambos productos se pueden configurar para retener (o no retener) mensajes, si el cumplimiento de CCPA o GDPR es una preocupación, iría con RabbitMQ.

Kafka es mejor que RabbitMQ en términos de rendimiento, durabilidad y latencia. Si espera transacciones de menos de 10k / seg, puede optar por RabbitMQ, pero eso también depende de su implementación.

Implementé Kafka en nuestro producto donde manejábamos más de 70k / seg de transacciones y la latencia fue en promedio de 15 ms con pocos picos que alcanzaron hasta 40 ms. El tamaño del tema fue de 100 kb.

PFB más puntos de datos sobre KAFKA y RabbitMQ: Apache Kafka incluye el corredor en sí, que en realidad es la parte más conocida y más popular, y ha sido diseñado y comercializado de manera destacada para escenarios de procesamiento de flujo. Además de eso, Apache Kafka ha agregado recientemente Kafka Streams que se posiciona como una alternativa a las plataformas de transmisión como Apache Spark, Apache Flink, Apache Beam / Google Cloud Data Flow y Spring Cloud Data Flow. La documentación hace un buen trabajo al analizar casos de uso populares como seguimiento de actividad del sitio web, métricas, agregación de registros, procesamiento de flujo, aprovisionamiento de eventos y registros de compromiso. Uno de esos casos de uso que describe es la mensajería, que puede generar cierta confusión. Así que vamos a desempaquetarlo un poco y obtener algo de claridad sobre qué escenarios de mensajería son mejores para Kafka, por ejemplo:

Transmita de A a B sin enrutamiento complejo, con un rendimiento máximo (100k / seg +), entregado en orden particionado al menos una vez. Cuando su aplicación necesita acceso al historial de transmisión, entregado en orden particionado al menos una vez. Kafka es un almacén de mensajes duradero y los clientes pueden obtener una "repetición" del flujo de eventos a pedido, a diferencia de los corredores de mensajes más tradicionales, donde una vez que se ha entregado un mensaje, se elimina de la cola. Stream Processing Event Sourcing RabbitMQ es una solución de mensajería de uso general, a menudo utilizada para permitir que los servidores web respondan rápidamente a las solicitudes en lugar de verse obligados a realizar procedimientos con muchos recursos mientras el usuario espera el resultado. También es bueno para distribuir un mensaje a múltiples destinatarios para consumo o para equilibrar cargas entre trabajadores bajo carga alta (20k + / seg). Cuando sus requisitos se extienden más allá del rendimiento, RabbitMQ tiene mucho que ofrecer: características para entrega confiable, enrutamiento, federación, HA, seguridad, herramientas de administración y otras características. Examinemos algunos escenarios mejores para RabbitMQ, como:

Su aplicación debe funcionar con cualquier combinación de protocolos existentes como AMQP 0-9-1, STOMP, MQTT, AMQP 1.0. Necesita un control / garantías de consistencia más fino por mensaje (colas de mensajes no entregados, etc.) Sin embargo, Kafka ha agregado recientemente un mejor soporte para las transacciones. Su aplicación necesita variedad en mensajes punto a punto, solicitud / respuesta y publicación / suscripción. Enrutamiento complejo para los consumidores, integre múltiples servicios / aplicaciones con una lógica de enrutamiento no trivial. RabbitMQ también puede abordar de manera efectiva varios de los casos de usos más fuertes de Kafka mencionados anteriormente, pero con el ayuda de software adicional. RabbitMQ se usa a menudo con Apache Cassandra cuando la aplicación necesita acceso al historial de transmisión, o con el complemento LevelDB para aplicaciones que necesitan una cola "infinita", pero ninguna de las características se envía con RabbitMQ.

La respuesta corta es "acuses de recibo de mensajes". RabbitMQ se puede configurar para requerir acuses de recibo de mensajes. Si un receptor falla, el mensaje vuelve a la cola y otro receptor puede intentarlo de nuevo. Si bien puede lograr esto en Kafka con su propio código, funciona con RabbitMQ fuera de la caja.

En mi experiencia, si tiene una aplicación que tiene requisitos para consultar un flujo de información, Kafka y KSql son su mejor opción. Si desea un sistema de colas, está mejor con RabbitMQ.

La respuesta más votada cubre la mayor parte, pero me gustaría destacar el punto de vista del caso de uso. ¿Puede Kafka hacer lo que el conejo mq puede hacer? La respuesta es sí, pero ¿puede el conejo mq hacer todo lo que hace Kafka? La respuesta es no. Entonces, ¿qué es lo que el conejo mq no puede hacer? Con esto ahora lea de nuevo la respuesta más votada y tendrá más sentido. Para elaborar, tome un caso de uso en el que necesite crear un sistema de mensajería que tenga un rendimiento súper alto, por ejemplo, "me gusta" en Facebook y haya elegido el conejo mq para eso. Creó un intercambio y una cola y un consumidor donde todos los editores (en este caso, los usuarios de FB) pueden publicar mensajes de 'me gusta'. Como su rendimiento es alto, creará múltiples subprocesos en el consumidor para procesar mensajes en paralelo, pero aún estará limitado por la capacidad de hardware de la máquina donde se ejecuta el consumidor. Asumiendo que un consumidor no es suficiente para procesar todos los mensajes, ¿qué haría? ¿Puede agregar un consumidor más a la cola? No, no puede hacerlo. ¿Puede crear una nueva cola y vincular esa cola para intercambiar que publica mensajes de 'me gusta'? La respuesta no es porque tendrá mensajes procesados ​​dos veces. Ese es el problema central que resuelve kafka. Le permite crear particiones distribuidas (Queue in rabbit mq) y consumidores distribuidos que se comunican entre sí. Eso asegura que sus mensajes en un tema reciban procesos de los consumidores distribuidos en varios nodos (Máquinas). Los corredores de Kafka aseguran que los mensajes tengan una carga equilibrada en todas las particiones de ese tema. El grupo de consumidores se asegura de que todos los consumidores se comuniquen entre sí y que el mensaje no se procese dos veces. Pero en la vida real no enfrentará este problema a menos que su rendimiento sea muy alto porque el conejo mq también puede procesar datos muy rápido incluso con un solo consumidor.