5 min read

Redis vs Kafka vs RabbitMQ

Redis vs Kafka vs RabbitMQ

Ao usar a comunicação assíncrona para Microsserviços, é comum usar um agente de mensagens.

Um broker garante que a comunicação entre diferentes microsserviços seja confiável e estável, que as mensagens sejam gerenciadas e monitoradas dentro do sistema e que as mensagens não sejam perdidas.

Existem alguns agentes de mensagens que você pode escolher, variando em escala e recursos de dados. Esta postagem do blog comparará os três corretores mais populares: RabbitMQ, Kafka e Redis.

Comunicação de microsserviços: síncrona e assíncrona

Existem duas maneiras comuns de comunicação entre os microsserviços: síncrona e assíncrona.

Em uma comunicação síncrona, o chamador aguarda uma resposta antes de enviar a próxima mensagem e opera como um protocolo REST sobre HTTP.

Ao contrário, na comunicação Assíncrona, as mensagens são enviadas sem esperar resposta. Isso é adequado para sistemas distribuídos e geralmente requer um intermediário de mensagens para gerenciar as mensagens.

O tipo de comunicação que você escolher deve considerar diferentes parâmetros, como: a estrutura seus microsserviços, qual infraestrutura você possui, latência, escala, dependências e a finalidade da comunicação.

A comunicação assíncrona pode ser mais complicada de estabelecer e requer a adição de mais componentes, mas as vantagens de usar a comunicação assíncrona para microsserviços superam os contras.

Vantagens da comunicação assíncrona

Em primeiro lugar, a comunicação assíncrona não é bloqueante por definição.

Ele também suporta melhor dimensionamento do que as operações síncronas.

Terceiro, no caso de falhas de microsserviço, os mecanismos de comunicação assíncrona fornecem várias técnicas de recuperação e geralmente são melhores para lidar com erros relacionados à falha.

Além disso, ao usar brokers em vez de um protocolo REST, os serviços que recebem comunicação não precisam realmente se conhecer.

Um novo serviço pode até ser introduzido depois de um antigo estar funcionando por um longo tempo, ou seja, melhores serviços de desacoplamento.

Por fim, ao escolher as operações assíncronas, você aumenta sua capacidade de criar uma descoberta central, monitoramento, balanceamento de carga ou até mesmo um aplicador de políticas no futuro.

Isso fornecerá a você habilidades para flexibilidade, escalabilidade e mais recursos em seu código e construção de sistema.

Escolhendo o corretor de mensagens certo

A comunicação assíncrona geralmente é gerenciada por meio de um agente de mensagens.

Ao escolher um corretor para executar suas operações assíncronas, você deve considerar algumas coisas:

  1. Escala do intermediário — O número de mensagens enviadas por segundo no sistema.
  2. Persistência de dados — A capacidade de recuperar mensagens.
  3. Capacidade do consumidor — Se o corretor é capaz de gerenciar consumidores um-para-um e/ou um-para-muitos.

Um a um

Um para muitos

Veja os melhores e mais recentes serviços disponíveis para descobrir qual provedor é o mais forte nessas três categorias.

Comparando diferentes agentes de mensagens

RabbitMQ (AMQP)

Escala: com base na configuração e nos recursos, a estimativa aqui é de cerca de 50 mil msg por segundo.

Persistência: mensagens persistentes e transitórias são suportadas.

Consumidores um-para-um vs um-para-muitos: ambos.

O RabbitMQ foi lançado em 2007 e é um dos primeiros mediadores de mensagens comuns a serem criados. É um código aberto que entrega mensagens por meio de métodos ponto a ponto, implementando protocolos avançados de enfileiramento de mensagens (AMQP). Ele foi projetado para suportar lógica de roteamento complexa.

Existem alguns serviços gerenciados que permitem que você o use como SaaS, mas não faz parte da stack nativa de provedores de nuvem principais. O RabbitMQ suporta todas as principais linguagens, incluindo Python, Java, .NET, PHP, Ruby, JavaScript, Go, Swift e muito mais.

Espere alguns problemas de desempenho quando estiver no modo persistente.

Kafka

Escala: pode enviar até um milhão de mensagens por segundo.

Persistência: sim.

Consumidores um -para-um vs um-para-muitos: apenas um-para-muitos (parece estranho à primeira vista, certo?!).

O Kafka foi criado pelo Linkedin em 2011 para lidar com processamento de alta taxa de transferência e baixa latência. Como plataforma de streaming distribuído, o Kafka replica um serviço de publicação-assinatura.

Ele fornece persistência de dados e armazena fluxos de registros que o tornam capaz de trocar mensagens de qualidade.

Kafka gerenciou SaaS no Azure, AWS e Confluent. Eles são todos os criadores e principais colaboradores do projeto Kafka. Kafka suporta todas as principais linguagens, incluindo Python, Java, C/C++, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift e muito mais.

Redis

Escala: pode enviar até um milhão de mensagens por segundo.

Persistência: basicamente, não - é um armazenamento de dados na memória.

Consumidores um-para-um vs um-para-muitos: ambos.

O Redis é um pouco diferente dos outros corretores de mensagens. Em sua essência, o Redis é um armazenamento de dados na memória que pode ser usado como um armazenamento de valor-chave de alto desempenho ou como um agente de mensagens.

Outra diferença é que o Redis não tem persistência, mas despeja sua memória em um disco/DB. Também é perfeito para processamento de dados em tempo real.

Originalmente, o Redis não era um para um e um para muitos. No entanto, desde que o Redis 5.0 introduziu o pub-sub, os recursos aumentaram e um para muitos se tornou uma opção.

Agentes de mensagens por caso de uso

Cobrimos algumas características do RabbitMQ, Kafka e Redis. Todos os três são bestas em sua categoria, mas como descrito, eles operam de maneira bem diferente.

Aqui está uma recomendação para o corretor de mensagens correto a ser usado de acordo com os diferentes casos de uso.

Mensagens de curta duração: Redis

O banco de dados na memória do Redis é quase perfeito para casos de uso com mensagens de curta duração em que a persistência não é necessária. Por fornecer serviços extremamente rápidos e recursos na memória, o Redis é o candidato perfeito para mensagens de retenção curtas em que a persistência não é tão importante e você pode tolerar alguma perda.

Com o lançamento de streams Redis na versão 5.0, também é um candidato para casos de uso de um para muitos, o que definitivamente era necessário devido a limitações e recursos antigos de pub-sub.

Grandes quantidades de dados: Kafka

Kafka é uma fila distribuída de alta taxa de transferência criada para armazenar uma grande quantidade de dados por longos períodos de tempo. Kafka é ideal para um ou muitos casos de uso em que a persistência é necessária.

Roteamento Complexo: RabbitMQ

O RabbitMQ é um corretor mais antigo, porém maduro, com muitos recursos e capacidades que suportam roteamento complexo. Ele ainda suportará comunicação de roteamento complexa quando a taxa necessária não for alta (mais do que algumas dezenas de milhares de msg/seg).

Considere sua stack

A consideração final, é claro, é sua stack atual. Se você estiver procurando por um processo de integração relativamente fácil e não quiser manter corretores diferentes, talvez esteja mais indicado trabalhar com um corretor que já seja suportado por sua stack.

Por exemplo, se você estiver usando o Celery for Task Queue em seu sistema em cima do RabbitMQ, você terá um incentivo para trabalhar com RabbitMQ ou Redis em oposição ao Kafka, que não é suportado e exigiria alguma reescrita.

É importante lembrar que cada ferramenta tem seus prós e contras e trata-se de entendê-los e escolher a ferramenta certa para o trabalho e aquele momento, situação e requisitos específicos.