Vamos direto ao ponto: São coisas diferentes, se você está comparando ambos ou está querendo decidir entre eles, você não entendeu algum deles ou não entendeu nenhum dos dois.
Mentiras ditas sobre RabbitMQ
Ao longo dos últimos anos eu ouvi barbaridades, das coisas mais descabidas possíveis e imagináveis. Nessa parte eu quero trabalhar essa desinformação com informações úteis.
1 | Com Kafka você trabalha de forma reativa, e com RabbitMQ você precisa pegar mensagens.
Mentira!
Sob o aspecto de reatividade ambos trabalham de forma idêntica com um canal pre-estabelecido sob um socket usando um protocolo específico.
Ambos trabalham de forma reativamente.
Essa afirmação absurda não existe.
RabbitMQ ainda possui prefetch que define o backlog de mensagens no consumidor para que o Broker envie mensagens para o cliente antes mesmo dele consumir, é uma estratégia para reduzir a latência do transporte da mensagem. As próximas X mensagens sempre estão na memória do consumidor porque já foram trafegadas diretamente.
O RabbitMQ possui um método, no AMQP, chamado BasicGET que é adotado para tecnologias sem compatibilidade. A documentação diz que seu uso não deve ser adotado caso possua um provider que suporte consumidores.
2 | RabbitMQ não é resiliente enquanto Kafka é resiliente
Mentira!
O RabbitMQ é tão resiliente quando um banco de dados como SQL Server, MySQL, Oracle, PostgreSQL. No entanto há peculiaridades aqui. A resiliência depende de você conhecer e apertar os parafusos certos, assim como um banco de dados:
- Publicar mensagens de forma resiliente
- Armazenar mensagens de forma resiliente
- Consumir mensagens de forma resiliente
Um ponto negativo da documentação é que todo Get Started do RabbitMQ com C# tem todas as configurações de resiliência desabilitadas. Basta ler um pouquinho mais que tudo está explicado lá.
3 | RabbitMQ armazena mensagens apenas em memória e se o servidor reiniciar, perdemos as mensagens
Mentira!
De um lado Kafka é uma stream, ou seja a natureza da stream é não apagar as mensagens após consumidas, em vez disso, move-se um offset, um ponteiro.
Já com filas, as mensagens são apagadas porque essa é a natureza de uma fila.
Em 2021 RabbitMQ também passou a suportar streams, dando a ele a capacidade de se comportar como Kafka, com a graciosidade.
Mesmo falando de filas, o RabbitMQ possui persistência nativa, exigindo configurações, já que uma das capacidades dele é exatamente permitir que você não use persistência, isso pode ser útil em casos extremos de performance que combina muito bem com a streams.
KAFKA – CUSTO – BRL UDS EUR
Deploy padrão do Kafka
no Azure HDInsight sugere:
- Head node: 2 nós
- “A6”
- 4 Cores
- 28 GB RAM
- 285 GB de armazenamento temporário
- $0.648/hora
- Worker node: 1 nó
- “A6”
- 4 Cores
- 28 GB RAM
- 285 GB de armazenamento temporário
- $0.648/hora
- Zookeeper node: 3 nós
- “A5”
- 2 Cores
- 14 GB RAM
- 135 GB de armazenamento temporário
- $0.324/hora
Custo estimado mensal com base nessas configurações: USD 2,128.68 na cotação de 09/07/2023, equivalente a R$ 10.371,78
Update JUNHO/2024
Hoje recebi um e-mail bem curioso
Original
Tradução
Kafka vs RabbitMQ é uma comparação descabida, mas feita por todo o mercado, por quê?
O primeiro problema é olhar pela perspectiva “do que eles resolvem” em vez de olhar para “o que eles fazem”.
Uma plataforma de stream, é muito interessante para Big Data, para trocar dados em volume. É eficiente no processamento, mas não é nada flexível.
Um message broker é um middleware especializado em armazenar de forma segura e distribuir mensagens, controlando processamento.
Note que há diferenças substanciais entre os objetivos de cada um.
O RabbitMQ tem foco nas aplicações que consomem, enquanto
O que eu preciso para subir mais uma instância, visando consumir mais mensagens de um topico (kafka) / fila (rabbitmq), de forma que esses consumidores não recebam mensagens duplicadas:
Kafka: Criar novas partitions no tópico, via alguma interface como CLI, por exemplo.
RabbitMQ: Basta subir o mesmo processo (consumidor) mais uma vez, no mesmo servidor, ou em outro servidor.
Qual a importância do planejamento do tamanho/formato da mensagem?
Kafka/RabbitMQ Streams – O planejamento precisa ser feito com muita cautela, abusando do conservadorismo. As Streams possuem um período de descarte muito longo, e em alguns casos sequer existe. Por isso é importante assegurar que mensagens antigas poderão, eventualmente, ser reprocessadas (senão não faz sentido o esforço para mantê-las, e ao mesmo tempo não serviriam para nada).
RabbitMQ Queues – O ciclo de vida da mensagem é extremamente curto, e por isso a flexibilidade e a tolerância a mudanças de formato é muito maior. Uma troca de formato pode ser feita durante um momento de zero processamento, mas pode também duplicar a fila e o consumidor por algum tempo (minutos ou horas) enquanto as mensagens no formato antigo ainda estão sendo processadas. Uma vez terminado o processo, o conjunto antigo de filas e consumidor podem ser removidos.
Migrando de Kafka para RabbitMQ no SimpleBet: Por que e como ?
Nesse estudo de caso David Lucia explica quais os motivos e quais problemas fizeram com que a Simplebet tenha optado por sair do Kafka e adotar RabbitMQ e qual o resultado desse movimento para ele e para seus clientes.
Qual é a diferença entre Kafka e RabbitMQ?1
Kafka é uma plataforma de streaming de eventos distribuída que facilita o throughput bruto, focada em um log append-only distribuído que pode ser clusterizado para um maior grau de disponibilidade. Isso difere do RabbitMQ, um message broker distribuído de código aberto que facilita a entrega de mensagens em cenários de roteamento complexos de maneira eficiente. Os recursos do RabbitMQ podem ser expandidos por meio do uso de plug-ins ativados no servidor. Eles também podem ser distribuídos e configurados para serem confiáveis no caso de falha do servidor ou da rede.
Quando você deve usar Kafka vs RabbitMQ?1
O log append-only do Kafka permite que os desenvolvedores acessem stream history e façam processamento direto da stream, enquanto o design do message broker do RabbitMQ se destaca em casos de uso que têm necessidades de roteamento específicas e garantias por mensagem. No entanto, o RabbitMQ está desenvolvendo um novo modelo de estrutura de dados para append-only que fechará a lacuna nos casos de uso de streaming.
Quais são os diferentes casos de uso para Kafka e RabbitMQ?1
Kafka é ideal para casos de uso de big data que exigem o melhor rendimento, enquanto RabbitMQ é ideal para entrega de mensagens de baixa latência, garantias por mensagem e roteamento complexo.
Como eles se comparam cara a cara?2
- RabbitMQ não pode ser usado como data store; Kafka pode.
- No RabbitMQ, o ordenação não é garantida, uma vez que temos vários consumidores. Kafka garante a ordem para uma partição em um tópico.
- As mensagens não podem ser reprocessadas no RabbitMQ – elas precisam ser reenviadas. Fazemos isso com o padrão Message Outbox. O Kafka armazena os dados na ordem em que são recebidos e oferece suporte à reprodução de mensagens com a ajuda de offsets. No entanto, ele apresenta outras vantagens e desvantagens em torno da compactação de dados, por quanto tempo manter os dados na stream, o que fazer se os dados necessários já tiverem sido expurgados da stream, etc.
- O RabbitMQ não oferece suporte a transações nativamente, ele usa acknowledgments. Kafka oferece suporte a transações.
- O RabbitMQ tem um ótimo suporte para .NET – ele supera completamente Kafka nesse aspecto. Kafka trata o suporte .NET como uma prioridade secundária.
- O RabbitMQ possui boas ferramentas para gerenciamento no Windows. Kafka não.
- O RabbitMQ implementa o AMQP. Essas grades de proteção o ajudam a cair em um poço de sucesso. Com Kafka, você terá que implementar muitos desses padrões e disciplinas sozinho.
- O RabbitMQ não precisa de um processo externo em execução. O Kafka requer a instância em execução do Zookeeper para o gerenciamento. Zookeeper é responsável por designar uma instância para o tópico.
- Fora da caixa, RabbitMQ está atrás no suporte a multithreading em comparação com Kafka – mas não muito. Uma vez que NServiceBus funciona com RabbitMQ e tem um bom suporte para multithreading, é um problema menor para RabbitMQ. Em ambos os mundos, o ordenação não é garantido se os consumidores forem dimensionados ou tiverem registros de busca usando várias threads.
- O RabbitMQ possui vários plug-ins para atender às suas necessidades. Kafka não é tão maduro e, portanto, não tem tantas opções de plugins.
Ainda não ficou claro? Calma!
Apache Kafka® is an event streaming platform. What does that mean?
Kafka combines three key capabilities so you can implement your use cases for event streaming end-to-end with a single battle-tested solution:
To publish (write) and subscribe to (read) streams of events, including continuous import/export of your data from other systems.
To store streams of events durably and reliably for as long as you want.
To process streams of events as they occur or retrospectively.
And all this functionality is provided in a distributed, highly scalable, elastic, fault-tolerant, and secure manner. Kafka can be deployed on bare-metal hardware, virtual machines, and containers, and on-premises as well as in the cloud. You can choose between self-managing your Kafka environments and using fully managed services offered by a variety of vendors.
Uma plataforma de eventos, processa eventos em escala.
Um message broker media comunicação entre partes.
Você consegue fazer quase tudo com todos eles, mas vamos a algumas diferenças importantes:
- Roteamento avançado não é uma habilidade do Kafka. No Kafka, quem publica, o faz em um tópico. Quem consome, consome um tópico.
- No RabbitMQ esse conceito é diferente. Quem publica, publica em uma exchange, e quem consome, consome de uma fila. Essa separação é usada de forma às exchanges serem uma abstração de roteamento para ou multiplicar a mensagem e copiá-la para diversas filas de interessados, ou para simplesmente descartar a mensagem porque ninguém tem interesse nela.
- O RabbitMQ usa AMQP um standard interoperável, Kafka não.
- A durabilidade da mensagem no Kafka demanda muito planejamento e discussão sobre os modelos dos eventos que estarão nele. Quanto mais tempo os eventos permanecerem na stream, maior é sua demanda por retrocompatibilidade. Se a mensagem está na stream e não pode ser reprocessada, você criou um elefante branco.
- Já ao final do processamento de uma mensagem com RabbitMQ nós deletamos essa mensagem do Message Broker, então nosso nível de retrocompatibilidade só precisa durar enquanto houverem mensagens da versão antiga na fila. E isso tende a levar no máximo segundos, horas e no máximo dias (em casos muito esquisitos).
- O foco em latência e mediação de mensagens entre serviços, permite com que filas anônimas sejam criadas, possibilita o uso de RPC em escala, sem necessidade de lidar com partitions , viabiliza o uso de RPC. São diversos benefícios interessantes e comportamentos diferentes do Kafka.
Existe algum cenário em que faz sentido os 2 juntos?
Sim, um exemplo que me vêm à cabeça é o exemplo de agregadores de preços de passagens aéreas.
Há demandas do sistema financeiro que também fazem sentido para cada caso uma solução.
Fonte:
- Understanding the Differences Between RabbitMQ vs Kafka | BRIAN MCCLAIN NOVEMBER 16, 2020
- Is Kafka or RabbitMQ the right messaging tool for you? | Yogi Aradhye | Jul 9, 2019
Qual a sua opinião sobre o SQL Server Service Broker? Você acha que seria adequado utilizar o mesmo para realizar a comunicação entre APIs?
Muito obrigado e parabens pelo seu trabalho!
Ignore a ordem, não há uma prioridade nos argumentos, mas vou mostrar meu ponto sobre o assunto.
1) Lembra que a Microsoft é a mesma que fez o MSMQ. Ela não tem um bom histórico e reputação experiência no design desse tipo de tarefa.
Mas vamos ignorar isso.
2) De forma genérica, trazer essa responsabilidade para um banco de dados, é deturpar o papel de um banco de dados.
3) Outro ponto é que estamos limitando a implementação, a um vendor sem um standard, em comparação com RabbitMQ
4) Do ponto de vista do mercado, o SQL Server Service Broker nem está no radar sobre esse assunto.
5) Os serviços de nuvem da Microsoft relacionados a mensageria, estão muito mais próximos do RabbitMQ, como o Azure Service Bus que é uma implementação AMQP, e o Azure Event Hub (que se não me engano é compatível com AMQP), e não há um serviço gerenciado do SQL Server Service Broker que não esteja em preview.
6) Sobre o SQL Server Service Broker no Azure, ele está em preview ainda. E somente agora.
7) A documentação é clara em apontar que para ele só existem filas. Não está claro quais são os controles envolvidos nisso, to há algum tempo caçando isso e não há essa documentação detalhada.
Mesmo se eu ignorasse todos os 7 pontos que listei acima, minha opinião é de que estamos falando de um serviço pobre. Ele simplesmente, com essa visão de apenas filas, não atende às demandas de mensageria, e na minha opinião nem deveria ter o nome de Service Broker, porque ele está mais para MSMQ over SQL Server.
Não vejo espaço para ele no mercado, nem em projetos pequenos, nem no futuro. Precisaria ser reinventado do zero. Mas a Microsoft é boa nisso. O próprio SQL Server é um exemplo dessa capacidade de reinventar um produto.
O ponto-chave, é que ele está atrelado ao banco SQL Server e isso é nocivo.
* Um serviço de mensageria deve ser independente, deve seguir um padrão interoperável que permita que possa ser substituído.
* Não deve obrigar a uma instalação de SQL Server, nem Oracle, nem postgres ou mysql.
* Deve ser independente.
* Banco de dados? Pode ter um provider, pode ter uma abstração que use alguns bancos como storage.
* Mas se tiver, vai degradar a performance e se assegurar na performance do banco.
Um message broker é desenhado para ser independente, porque a natureza mais simples e especializada faz com que ele consiga oferecer muito mais performance, muito mais throughput que bancos de dados. Mas é uma troca, ele precisa ser mais simples para conseguir isso. Então ele não pode ser tão simples ao ponto de não atender às demandas de negócio, mas também não pode ser tão complexo que se pareça um banco de dados.
Nessa disputa, por hora não há espaço para o SQL Server Service Broker.
Essa é minha OPINIÃO, espero ter ajudado. Se tiver mais dúvidas, é só comentar!
—
PS: Eu acredito que você não se convencerá com meus argumentos.
Assim meu conselho é que você estude e implemente todos e compare você mesmo.
Depois olhe para cases de sucesso de uso de cada uma das soluções.
Se os seus testes não apontarem a precariedade do SQL Server Service Broker, a ausência de bons cases vai te ajudar a elucidar a questão.
Muito obrigado, muito obrigadoo mesmo por sua resposta, mas um ponto ainda não está claro:
– Vejo em suas postagens no que se refere ao RabbitMQ, que você sempre se refere a “Resiliência”, e que pelo que pude entender, facilmente pode-se ter uma mensagem persistente, evitando a perda da mesma em caso de reinicialização do rabbitmq ou servidor.
Mas como você visualiza essa questão de resiliência no SQL Server Broker? Essas mensagens seriam salvas no banco?
Como você vê essa questão?
Novamente obrigado por sua atenção, me ajudou muito, todo seu material sempre me ajuda muito.
– Vejo em suas postagens no que se refere ao RabbitMQ, que você sempre se refere a “Resiliência”, e que pelo que pude entender, facilmente pode-se ter uma mensagem persistente, evitando a perda da mesma em caso de reinicialização do rabbitmq ou servidor.
A parte do “facilmente pode-se ter uma mensagem persistente” não é verdade.
Se perde mensagem por ignorância, não conhecimento, tentar aprender por tutorial.
A ferramenta está lá.
As configurações para resiliência estão lá.
Quem se lasca, é por pura ignorância, falta de compreensão, ou até mesmo preguiça.
Em geral é a forma de estudar que é o problema.
Um restart do RabbitMQ, até um crash do servidor onde o rabbitmq está instalado, não causa perda de mensagens se você fizer as configurações certas. Eu já demonstrei isso algumas vezes em algumas lives.
Mas como você visualiza essa questão de resiliência no SQL Server Broker? Essas mensagens seriam salvas no banco?
Não sei, SQL Server Service Broker não é uma solução que esteja no meu radar para que eu me dedique a ela.
Eu olhei a documentação esses dias por conta da sua mensagem apenas.
Mas nunca ganhou relevância ao meu olhar, e sinceramente do mercado também.
Se você quer saber mais sobre RabbitMQ, aqui é o lugar.
Se quiser saber mais sobre o SQL Server Service Broker… seria legal achar um lugar que tenha alguém que pelo menos tenha tentado usar.
Aqui, por hora, não há espaço para o SQL Server Service Broker. Já tenho assuntos demais para fazer upgrade hehehehe
– Acredito que a facilidade venha justamente do que você citou “As configurações para resiliência estão lá.”, ja assisti suas lives a respeito e li o post “Como perder mensagens com RabbitMQ”, e meu entendimento foi que tendo uma fila durável, mensagens persistentes e manual ack (e outros pontos citados por você como cuidados com TTL agressivo) as mensagens não são perdidas, eu estou aprendendo RabbitMQ nesse exato momento e seguindo essas configurações citadas reinicie o meu computador, o próprio Rabbitmq e as mensagens estavam presentes, não foram perdidas, eu achei muito fácil no “Hello World” que estou fazendo para aprender, apenas tomei cuidado de entender o básico, foi baseado nesse ponto que me referi a facilidade.
– Entendido, mas suas palavras sobre o SQL Server Broker me ajudaram muito, ficou claro a baixa relevância do mesmo, eu apenas estava lendo sobre as opções da microsoft e fiquei confuso com o uso do mesmo.
Novamente agradecido por toda sua paciência e atenção! Um grande abraço!