Phenquestions
Sempre que quisermos integrar corretores de mensagens em nosso aplicativo, o que nos permite escalar facilmente e conectar nosso sistema de forma assíncrona, existem muitos corretores de mensagens que podem fazer a lista a partir da qual você deve escolher um, como:
- RabbitMQ
- Apache Kafka
- ActiveMQ
- AWS SQS
- Redis
Cada um desses corretores de mensagens tem sua própria lista de prós e contras, mas as opções mais desafiadoras são os dois primeiros, RabbitMQ e Apache Kafka. Nesta lição, listaremos pontos que podem ajudar a restringir a decisão de escolher um ou outro. Por fim, é importante ressaltar que nenhum deles é melhor do que outro em todos os casos de uso e depende completamente do que você deseja alcançar, Não há uma resposta certa!
Começaremos com uma introdução simples dessas ferramentas.
Apache Kafka
Como dissemos nesta lição, o Apache Kafka é um log de commit distribuído, tolerante a falhas e escalonável horizontalmente. Isso significa que o Kafka pode executar um termo de divisão e regra muito bem, pode replicar seus dados para garantir a disponibilidade e é altamente escalonável no sentido de que você pode incluir novos servidores em tempo de execução para aumentar sua capacidade de gerenciar mais mensagens.
Produtor e consumidor Kafka
RabbitMQ
RabbitMQ é um corretor de mensagens de uso mais geral e mais simples, que por si só mantém um registro sobre quais mensagens foram consumidas pelo cliente e mantém as outras. Mesmo se por algum motivo o servidor RabbitMQ cair, você pode ter certeza de que as mensagens atualmente presentes nas filas foram armazenadas no Sistema de Arquivos para que, quando RabbitMQ voltar a funcionar novamente, essas mensagens possam ser processadas pelos consumidores de uma maneira consistente.
RabbitMQ trabalhando
Superpotência: Apache Kafka
O principal superpoder de Kafka é que ele pode ser usado como um sistema de fila, mas não é o que se limita a. Kafka é algo mais parecido com um buffer circular que pode escalar tanto quanto um disco na máquina do cluster e, assim, nos permite sermos capazes de reler as mensagens. Isto pode ser feito pelo cliente sem ter que depender do cluster Kafka visto que é totalmente responsabilidade do cliente observar os metadados da mensagem que está lendo no momento e pode revisitar o Kafka mais tarde em um intervalo especificado para ler a mesma mensagem novamente.
Observe que o tempo em que esta mensagem pode ser relida é limitado e pode ser configurado na configuração Kafka. Então, quando esse tempo acabar, não há como um cliente ler uma mensagem mais antiga novamente.
Superpotência: RabbitMQ
O principal superpoder do RabbitMQ é que ele é simplesmente escalonável, é um sistema de enfileiramento de alto desempenho que tem regras de consistência muito bem definidas e capacidade de criar muitos tipos de modelos de troca de mensagens. Por exemplo, existem três tipos de troca que você pode criar no RabbitMQ:
- Troca direta: troca de tópico um para um
- Troca de tema: A tópico é definido no qual vários produtores podem publicar uma mensagem e vários consumidores podem se vincular para ouvir naquele tópico, para que cada um deles receba a mensagem que é enviada para este tópico.
- Fanout exchange: É mais restrito do que a troca de tópicos, pois quando uma mensagem é publicada em fanout exchange, todos os consumidores que estiverem conectados a filas que se ligam ao fanout exchange receberão a mensagem.
Já notei a diferença entre RabbitMQ e Kafka? A diferença é que se um consumidor não estiver conectado a um fanout exchange no RabbitMQ quando uma mensagem foi publicada, ela será perdida porque outros consumidores consumiram a mensagem, mas isso não acontece no Apache Kafka, pois qualquer consumidor pode ler qualquer mensagem como eles mantêm seu próprio cursor.
RabbitMQ é centrado no corretor
Um bom corretor é alguém que garante o trabalho que assume e é nisso que o RabbitMQ é bom. É inclinado para garantias de entrega entre produtores e consumidores, com mensagens transitórias preferidas em relação às duráveis.
O RabbitMQ usa o próprio corretor para gerenciar o estado de uma mensagem e garantir que cada mensagem seja entregue a cada consumidor autorizado.
RabbitMQ presume que os consumidores estão principalmente online.
Kafka é centrado no produtor
O Apache Kafka é centrado no produtor, pois é totalmente baseado em particionamento e um fluxo de pacotes de eventos contendo dados e os transformando em corretores de mensagens duráveis com cursores, suportando consumidores de lote que podem estar offline ou consumidores online que desejam mensagens em baixa latência.
Kafka garante que a mensagem permaneça segura até um determinado período de tempo, replicando a mensagem em seus nós no cluster e mantendo um estado consistente.
Então, Kafka não presumir que qualquer um de seus consumidores está principalmente online e nem se importa.
Ordem de mensagens
Com RabbitMQ, o pedido de publicação é gerenciado de forma consistente e os consumidores receberão a mensagem no próprio pedido publicado. Por outro lado, o Kafka não o faz, pois presume que as mensagens publicadas são pesadas por natureza, de modo que os consumidores são lentos e podem enviar mensagens em qualquer ordem, portanto, ele também não gerencia o pedido por conta própria. Porém, podemos configurar uma topologia semelhante para gerenciar o pedido em Kafka usando o troca consistente de hash ou plugin de fragmentação., ou ainda mais tipos de topologias.
A tarefa completa gerenciada pelo Apache Kafka é atuar como um "amortecedor" entre o fluxo contínuo de eventos e os consumidores, dos quais alguns estão online e outros podem estar offline - apenas consumindo lote de hora em hora ou mesmo diariamente.
Conclusão
Nesta lição, estudamos as principais diferenças (e semelhanças também) entre o Apache Kafka e o RabbitMQ. Em alguns ambientes, ambos mostraram um desempenho extraordinário, como RabbitMQ consumiu milhões de mensagens por segundo e Kafka consumiu vários milhões de mensagens por segundo. A principal diferença arquitetônica é que o RabbitMQ gerencia suas mensagens quase na memória e, portanto, usa um grande cluster (mais de 30 nós), enquanto o Kafka realmente faz uso dos poderes das operações de I / O de disco sequencial e requer menos hardware.
Novamente, o uso de cada um deles ainda depende completamente do caso de uso em um aplicativo. Boas mensagens !
