Existe alguma razão para usar o RabbitMQ sobre o Kafka?

Me pediram para avaliar o RabbitMQ em vez do Kafka, mas achei difícil encontrar uma razão para estar fazendo algo melhor que o Kafka. Alguém sabe se é realmente melhor em produtividade, durabilidade, latência ou facilidade de uso?

O RabbitMQ é um intermediário de mensagens de uso geral sólido que suporta vários protocolos, como AMQP, MQTT, STOMP, etc. Ele pode lidar com alto rendimento. Um caso de uso comum do RabbitMQ é manipular trabalhos em segundo plano ou tarefas de longa execução, como digitalização de arquivos , dimensionamento de imagens ou conversão de PDF. O RabbitMQ também é usado entre microsserviços, onde serve como um meio de comunicação entre aplicativos, evitando gargalos na transmissão de mensagens.

Kafka é um barramento de mensagens otimizado para fluxos de dados com alta entrada e reprodução. Use o Kafka quando precisar mover uma grande quantidade de dados, processar dados em tempo real ou analisar dados durante um período de tempo. Em outras palavras, onde os dados precisam ser coletados, armazenados e manipulados. Um exemplo é quando você deseja acompanhar a atividade do usuário em uma loja virtual e gerar itens sugeridos para compra. Outro exemplo é a análise de dados para rastreamento, ingestão, registro ou segurança.

O Kafka pode ser visto como um intermediário de mensagens durável, onde os aplicativos podem processar e reprocessar dados transmitidos em disco. Kafka tem uma abordagem de roteamento muito simples. O RabbitMQ tem melhores opções se você precisar rotear suas mensagens de maneiras complexas para seus consumidores. Use Kafka se precisar oferecer suporte a consumidores em lote que podem estar offline ou consumidores que desejam mensagens com baixa latência. 

Para entender como ler dados do Kafka, primeiro precisamos entender seus consumidores e grupos de consumidores. As partições permitem paralelizar um tópico dividindo os dados em vários nós. Cada registro em uma partição é atribuído e identificado por seu deslocamento exclusivo. Esse deslocamento aponta para o registro em uma partição. Na versão mais recente do Kafka, o Kafka mantém um deslocamento numérico para cada registro em uma partição. Um consumidor em Kafka pode cometer compensações automaticamente periodicamente ou pode optar por controlar essa posição confirmada manualmente. O RabbitMQ manterá todos os estados sobre mensagens consumidas / reconhecidas / não reconhecidas. Acho Kafka mais complexo de entender do que o caso do RabbitMQ, onde a mensagem é simplesmente removida da fila depois que é recebida.

As filas do RabbitMQ são mais rápidas quando estão vazias, enquanto o Kafka retém grandes quantidades de dados com muito pouca sobrecarga - o Kafka foi projetado para armazenar e distribuir grandes volumes de mensagens. (Se você planeja ter filas muito longas no RabbitMQ, pode dar uma olhada nas filas preguiçosas .)

O Kafka é construído desde o início com o dimensionamento horizontal (dimensionamento adicionando mais máquinas) em mente, enquanto o RabbitMQ é projetado principalmente para o dimensionamento vertical (dimensionamento adicionando mais energia).

O RabbitMQ possui uma interface amigável que permite monitorar e manipular o servidor RabbitMQ a partir de um navegador da web. Entre outras coisas, filas, conexões, canais, trocas, usuários e permissões de usuário podem ser manipuladas - criadas, excluídas e listadas no navegador e você pode monitorar as taxas de mensagens e enviar / receber mensagens manualmente. O Kafka possui várias ferramentas de código aberto e algumas comerciais , oferecendo as funcionalidades de administração e monitoramento. Eu diria que é mais fácil / mais rápido entender bem o RabbitMQ.

Mais leitura e alguns dados de comparação podem ser encontrados aqui: https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html

Também recomendando o documento da indústria: "Kafka versus RabbitMQ: um estudo comparativo de duas implementações de publicação / assinatura de referência da indústria": http://dl.acm.org/citation.cfm?id=3093908

Eu trabalho em uma empresa que fornece o Apache Kafka e o RabbitMQ como serviço.

Eu ouço essa pergunta toda semana ... Enquanto o RabbitMQ (como IBM MQ ou JMS ou outras soluções de mensagens em geral) é usado para mensagens tradicionais, o Apache Kafka é usado como plataforma de streaming (sistema de mensagens + armazenamento distribuído + processamento de dados). Ambos são criados para diferentes casos de uso.

Você pode usar o Kafka para "mensagens tradicionais", mas não usar cenários específicos do MQ para Kafka.

O artigo “ Apache Kafka vs. Enterprise Service Bus (ESB) - amigos, inimigos ou frenemies? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/ ) ”discute por que o Kafka não é competitivo, mas complementar as soluções de integração e mensagens (incluindo o RabbitMQ) e como integrar os dois.

5 Principais diferenças entre Kafka e RabbitMQ, cliente que os está usando:

Qual sistema de mensagens escolher ou devemos mudar nosso sistema de mensagens existente?

Não há uma resposta para a pergunta acima. Uma abordagem possível para revisão quando você tem que decidir qual sistema de mensagens ou você deve mudar o sistema existente é “ Avaliar escopo e custos ”

Uma diferença crítica que vocês esqueceram é o RabbitMQ: o sistema de mensagens push, enquanto o Kafka é o sistema de mensagens pull. Isso é importante no cenário em que o sistema de mensagens precisa satisfazer tipos diferentes de consumidores com diferentes recursos de processamento. Com o sistema Pull, o consumidor pode consumir com base em sua capacidade, onde os sistemas push enviarão as mensagens independentemente do estado do consumidor, colocando o consumidor em alto risco.

O RabbitMQ é um intermediário tradicional para mensagens de uso geral. Ele permite que os servidores da Web respondam às solicitações rapidamente e entreguem mensagens para vários serviços. Os editores podem publicar mensagens e disponibilizá-las nas filas, para que os consumidores possam recuperá-las. A comunicação pode ser assíncrona ou síncrona.

Por outro lado, o Apache Kafka não é apenas um intermediário de mensagens. Foi inicialmente projetado e implementado pelo LinkedIn para servir como uma fila de mensagens. Desde 2011, o Kafka tem código aberto e evoluiu rapidamente para uma plataforma de streaming distribuída, usada para a implementação de pipelines de dados em tempo real e aplicativos de streaming.

É escalável horizontalmente, tolerante a falhas, extremamente rápido e é executado em produção em milhares de empresas.

As organizações modernas possuem vários pipelines de dados que facilitam a comunicação entre sistemas ou serviços. As coisas ficam um pouco mais complicadas quando um número razoável de serviços precisa se comunicar em tempo real.

A arquitetura se torna complexa, pois são necessárias várias integrações para permitir a intercomunicação desses serviços. Mais precisamente, para uma arquitetura que engloba m serviços de origem e de destino, é necessário escrever integrações distintas do nxm. Além disso, toda integração vem com uma especificação diferente, o que significa que é possível exigir um protocolo diferente (HTTP, TCP, JDBC etc.) ou uma representação de dados diferente (binária, Apache Avro, JSON etc.), tornando as coisas ainda mais desafiadoras. . Além disso, os serviços de origem podem lidar com o aumento da carga de conexões que podem afetar potencialmente a latência.

O Apache Kafka leva a arquiteturas mais simples e gerenciáveis, dissociando os pipelines de dados. O Kafka atua como um sistema distribuído de alto rendimento, no qual os serviços de origem enviam fluxos de dados, disponibilizando-os para os serviços de destino, em tempo real.

Além disso, muitas interfaces de usuário de código aberto e de nível empresarial para gerenciar os Kafka Clusters estão disponíveis agora. Para obter mais detalhes, consulte meus artigos Visão geral das ferramentas de monitoramento da interface do usuário para clusters do Apache Kafka e Por que o Apache Kafka?

A decisão de optar por RabbitMQ ou Kafka depende dos requisitos do seu projeto. Em geral, se você deseja um broker de mensagens pub-sub simples / tradicional, vá para o RabbitMQ. Se você deseja criar uma arquitetura orientada a eventos sobre a qual sua organização atuará em eventos em tempo real, vá para o Apache Kafka, pois ele fornece mais funcionalidade para esse tipo de arquitetura (por exemplo, Kafka Streams ou ksqlDB).

Eu sei que é um pouco tarde e talvez você já tenha dito indiretamente, mas, novamente, Kafka não é uma fila, é um log (como alguém disse acima, com base em pesquisas).

Para simplificar, o caso de uso mais óbvio em que você deve preferir o RabbitMQ (ou qualquer outro techno de fila) ao Kafka é o seguinte:

Você tem vários consumidores consumindo em uma fila e sempre que houver uma nova mensagem na fila e um consumidor disponível, você deseja que essa mensagem seja processada. Se você observar atentamente como o Kafka funciona, notará que não sabe como fazer isso; por causa do dimensionamento da partição, você terá um consumidor dedicado a uma partição e entrará em um problema de fome. Problema que é facilmente evitado usando o techno de fila simples. Você pode pensar em usar um encadeamento que enviará as diferentes mensagens da mesma partição, mas, novamente, o Kafka não possui nenhum mecanismo de reconhecimento seletivo.

O máximo que você pode fazer é fazer como esses caras e tentar transformar Kafka como uma fila: https://github.com/softwaremill/kmq

Yannick

Use RabbitMQ quando:

• Você não precisa lidar com o Bigdata e prefere uma interface de usuário incorporada conveniente para monitorar
• Não há necessidade de filas replicáveis ​​automaticamente
• Sem assinantes múltiplos para as mensagens - Como, ao contrário do Kafka, que é um log, o RabbitMQ é uma fila e as mensagens são removidas quando consumidas e o reconhecimento é recebido
• Se você tiver os requisitos para usar caracteres curinga e regex para mensagens
• Se definir a prioridade da mensagem é importante

Em resumo: o RabbitMQ é bom para casos de uso simples, com baixo tráfego de dados, com o benefício de fila de prioridade e opções de roteamento flexíveis. Para dados massivos e alto rendimento, use o Kafka.

Fornecerei uma resposta objetiva com base na minha experiência com ambos, também ignorarei a teoria por trás deles, assumindo que você já o conheça e / ou outras respostas já tenham fornecido o suficiente.

RabbitMQ : Eu escolheria este caso meus requisitos fossem simples o suficiente para lidar com a comunicação do sistema através de canais / filas, retenção e streaming não é um requisito. Por exemplo, quando o sistema de fabricação constrói o ativo, ele notifica o sistema de contrato para configurar os contratos e assim por diante.

Kafka : Requisito de fornecimento de eventos principalmente, quando você pode precisar lidar com fluxos (às vezes infinitos), uma grande quantidade de dados ao mesmo tempo adequadamente equilibrados, reproduzir deslocamentos para garantir um determinado estado e assim por diante. Lembre-se de que essa arquitetura também traz mais complexidade, pois inclui conceitos como tópicos / partições / intermediários / mensagens de marca para exclusão, etc. como uma importância de primeira classe.

O único benefício que consigo pensar é no recurso Transacional, o resto pode ser feito usando o Kafka

O dimensionamento de ambos é difícil de maneira tolerante a falhas distribuída, mas eu argumentaria que é muito mais difícil em escala maciça com o RabbitMQ. Não é trivial entender Shovel, Federation, Filas de Mensagens Espelhadas, ACK, problemas de Mem, verificação de falhas etc. Não quer dizer que você também não terá problemas específicos com o Zookeeper etc. no Kafka, mas há menos partes móveis para gerenciar. Dito isto, você recebe uma troca Polyglot com o RMQ e não com Kafka. Se você deseja transmitir, use Kafka. Se você deseja uma entrega simples de pacotes de alto volume ou IoT, use o Kafka. É sobre consumidores inteligentes. Se você deseja flexibilidade de msg e maior confiabilidade com custos mais altos e possivelmente alguma complexidade, use o RMQ.

Se você possui necessidades de roteamento complexas e deseja uma GUI integrada para monitorar o broker, o RabbitMQ pode ser o melhor para o seu aplicativo. Caso contrário, se você estiver procurando por um intermediário de mensagens para lidar com alta taxa de transferência e fornecer acesso ao histórico do fluxo, Kafka é provavelmente a melhor escolha.

O Apache Kafka é uma escolha popular para alimentar pipelines de dados. O Apache kafka adicionou o fluxo kafka para suportar casos de uso etl populares. O KSQL simplifica a transformação de dados dentro do pipeline, preparando mensagens para pousar de maneira limpa em outro sistema. O KSQL é o mecanismo SQL de streaming do Apache Kafka. Ele fornece uma interface SQL interativa fácil de usar e poderosa para processamento de fluxo no Kafka, sem a necessidade de escrever código em uma linguagem de programação como Java ou Python. O KSQL é escalável, elástico, tolerante a falhas e em tempo real. Ele suporta uma ampla variedade de operações de streaming, incluindo filtragem de dados, transformações, agregações, junções, janelas e sessões.

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

O Rabbitmq não é uma escolha popular para sistemas etl, e sim para aqueles em que exige sistemas simples de mensagens com menos rendimento.

Percebo que essa é uma pergunta antiga, mas um cenário em que o RabbitMQ pode ser uma escolha melhor é quando se lida com a redação de dados.

Com o RabbitMQ, por padrão, depois que a mensagem é consumida, ela é excluída. Com o Kafka, por padrão, as mensagens são mantidas por uma semana. É comum definir isso por um período muito maior, ou mesmo nunca excluí-los.

Embora os dois produtos possam ser configurados para reter (ou não reter) mensagens, se a conformidade com o CCPA ou o GDPR for uma preocupação, eu usaria o RabbitMQ.

O Kafka é melhor que o RabbitMQ em termos de produtividade, durabilidade e latência. Se você espera transações com menos de 10k / s, pode optar pelo RabbitMQ, mas isso também depende da sua implementação.

Eu implementei o Kafka em nosso produto, onde estávamos lidando com transações de mais de 70k / seg. A latência era em média 15ms, com poucos picos atingindo até 40ms. O tamanho do tópico era 100kb.

PFB mais pontos de dados no KAFKA e RabbitMQ: Apache Kafka inclui o próprio broker, que é realmente a parte mais conhecida e mais popular dele, e foi projetado e comercializado com destaque para cenários de processamento de fluxo. Além disso, o Apache Kafka adicionou recentemente o Kafka Streams, que se posiciona como uma alternativa às plataformas de streaming como Apache Spark, Apache Flink, Apache Beam / Google Cloud Data Flow e Spring Cloud Data Flow. A documentação faz um bom trabalho ao discutir casos de uso populares, como rastreamento de atividades do site, métricas, agregação de logs, processamento de fluxo, fornecimento de eventos e logs de confirmação. Um desses casos de uso descritos é o sistema de mensagens, que pode gerar alguma confusão. Então, vamos descompactar isso um pouco e ter alguma clareza sobre quais cenários de mensagens são melhores para o Kafka, como:

Transmita de A para B sem roteamento complexo, com taxa de transferência máxima (100k / s +), entregue em ordem particionada pelo menos uma vez. Quando seu aplicativo precisa acessar o histórico do fluxo, entregue em ordem particionada pelo menos uma vez. O Kafka é um armazenamento de mensagens durável e os clientes podem obter uma "repetição" do fluxo de eventos sob demanda, em oposição aos intermediários de mensagens mais tradicionais, onde uma vez que uma mensagem é entregue, ela é removida da fila. Fornecimento de eventos de processamento de fluxo O RabbitMQ é uma solução de mensagens de uso geral, geralmente usada para permitir que os servidores da Web respondam às solicitações rapidamente, em vez de serem forçados a executar procedimentos com muitos recursos enquanto o usuário aguarda o resultado. Também é bom para distribuir uma mensagem para vários destinatários para consumo ou para equilibrar cargas entre trabalhadores sob carga alta (20k + / s). Quando seus requisitos vão além da taxa de transferência, o RabbitMQ tem muito a oferecer: recursos para entrega confiável, roteamento, federação, HA, segurança, ferramentas de gerenciamento e outros recursos. Vamos examinar alguns cenários melhores para o RabbitMQ, como:

Seu aplicativo precisa trabalhar com qualquer combinação de protocolos existentes, como AMQP 0-9-1, STOMP, MQTT, AMQP 1.0. Você precisa de um controle / garantias de consistência mais refinada por mensagem (filas de mensagens não entregues, etc.). No entanto, Kafka recentemente adicionou melhor suporte para transações. Seu aplicativo precisa de variedade ponto a ponto, solicitar / responder e publicar / assinar mensagens Roteamento complexo para consumidores, integrar vários serviços / aplicativos com lógica de roteamento não trivial O RabbitMQ também pode abordar efetivamente vários dos casos de uso fortes de Kafka acima, mas com o ajuda de software adicional. O RabbitMQ é frequentemente usado com o Apache Cassandra quando o aplicativo precisa acessar o histórico do fluxo ou com o plug-in LevelDB para aplicativos que precisam de uma fila “infinita”, mas nenhum recurso é fornecido com o próprio RabbitMQ.

A resposta curta é "confirmação de mensagem". O RabbitMQ pode ser configurado para exigir confirmações de mensagens. Se um receptor falhar, a mensagem retornará à fila e outro receptor poderá tentar novamente. Embora você possa fazer isso no Kafka com seu próprio código, ele funciona com o RabbitMQ imediatamente.

Na minha experiência, se você possui um aplicativo que possui requisitos para consultar um fluxo de informações, Kafka e KSql são sua melhor aposta. Se você deseja um sistema de filas, é melhor usar o RabbitMQ.

A resposta mais votada cobre a maior parte, mas eu gostaria de destacar o ponto de vista do caso de uso. O kafka pode fazer o mq do coelho, a resposta é sim, mas o mq do coelho pode fazer tudo o que o kafka faz, a resposta é não. Então, o que o rabbit mq não pode fazer que separa o kafka é o processamento de mensagens distribuídas. Com isso, leia agora a resposta mais votada e fará mais sentido. Para elaborar, use um caso de uso em que você precise criar um sistema de mensagens com taxa de transferência super alta, por exemplo, "curtidas" no facebook e Você tenha escolhido o rabbit mq para isso. Você criou uma troca e uma fila e um consumidor em que todos os editores (nesse caso, usuários do FB) podem publicar mensagens de 'curtidas'. Como seu rendimento é alto, você criará vários encadeamentos no consumidor para processar mensagens em paralelo, mas ainda será limitado pela capacidade de hardware da máquina em que o consumidor está sendo executado. Supondo que um consumidor não seja suficiente para processar todas as mensagens - o que você faria? Você pode adicionar mais um consumidor à fila - não, você não pode fazer isso. Você pode criar uma nova fila e vincular essa fila à troca que publica a mensagem 'likes'; a resposta não é porque você terá as mensagens processadas duas vezes. Esse é o principal problema que o kafka resolve. Permite criar partições distribuídas (Fila no rabbit mq) e consumidor distribuído que conversam entre si. Isso garante que suas mensagens em um tópico obtenham processos pelos consumidores distribuídos em vários nós (Máquinas). Os agentes Kafka garantem que as mensagens sejam equilibradas em todas as partições desse tópico. Grupo de consumidores verifique se todos os consumidores conversam entre si e a mensagem não é processada duas vezes. Mas, na vida real, você não enfrentará esse problema, a menos que seu throughput seja muito alto, porque o rabbit mq também pode processar dados muito rapidamente, mesmo com um consumidor.