Qual é a diferença entre o Kafka e o Redis?
O Redis é um armazenamento de dados de chave-valor na memória, enquanto o Apache Kafka é um mecanismo de processamento de fluxo. No entanto, é possível comparar as duas tecnologias porque você pode usar ambas para criar um sistema de publicação e assinatura (pub/sub) de mensagens. Na arquitetura de nuvem moderna, as aplicações são desacopladas em blocos de construção menores e independentes chamados de serviços. As mensagens pub/sub fornecem notificações instantâneas de eventos para esses sistemas distribuídos. O Kafka é compatível com um sistema baseado em pull em que publicadores e assinantes compartilham uma fila de mensagens comum da qual os assinantes efetuam pull das mensagens, conforme necessário. O Redis é compatível com um sistema baseado em push em que o publicador distribui mensagens para todos os assinantes quando ocorre um evento.
Como funcionam: pub/sub do Kafka vs. do Redis
O Apache Kafka é uma plataforma de transmissão de eventos que possibilita que várias aplicações transmitam dados de maneira independente umas das outras. Essas aplicações, chamadas produtores e consumidores, publicam e assinam informações que entram e saem de determinadas partições de dados chamadas tópicos.
Por sua vez, o Redis foi criado como um banco de dados na memória compatível com a transferência de dados de baixa latência entre aplicações. Ele armazena todas as mensagens na RAM, e não em um disco rígido, para reduzir o tempo de leitura e gravação de dados. Assim como o Kafka, vários consumidores podem se inscrever em um fluxo do Redis para recuperar mensagens.
Embora seja possível usar os dois para um sistema de publicação e assinatura de mensagens, o Kafka e o Redis funcionam de forma diferente.
Fluxo de trabalho do Kafka
O Apache Kafka conecta produtores e consumidores por meio de clusters de computação. Cada cluster consiste em vários agentes do Kafka que residem em servidores diferentes.
O Kafka cria tópicos e partições para estes propósitos:
- Tópicos para agrupar dados semelhantes pertencentes a um assunto de interesse, como e-mail, pagamento, usuários e compra
- Partições entre diferentes agentes para replicação de dados e tolerância a falhas
Os produtores publicam mensagens para o agente. Ao receber uma mensagem, o agente categoriza os dados em um tópico e os armazena em uma partição. Os consumidores se conectam ao tópico relevante e extraem dados da partição.
Fluxo de trabalho do Redis
O Redis funciona com uma arquitetura de cliente-servidor como um sistema de banco de dados NoSQL. Produtores e consumidores são fracamente acoplados e não precisam se conhecer ao enviar mensagens.
O Redis usa chaves e nós primários-secundários para estes propósitos:
- Teclas para agrupar mensagens semelhantes. Por exemplo, “e-mail” é uma chave que aponta para o armazenamento de dados que contém somente mensagens de e-mail.
- Nós primários-secundários para replicação de mensagens.
Quando um produtor envia uma mensagem a um nó específico, o Redis entrega a mensagem a todos os assinantes conectados verificando a chave da mensagem. O consumidor deve sempre iniciar e manter uma conexão ativa com o servidor Redis para receber mensagens. Isso é conhecido como semântica de entrega conectada.
Leia sobre sistema de publicação e assinatura de mensagens »
Tratamento de mensagens: pub/sub do Kafka vs. do Redis
O Apache Kafka fornece aos desenvolvedores sistemas de mensagens distribuídos altamente escaláveis. Por sua vez, o Redis oferece estruturas de dados avançadas que permitem que a aplicação envie dados para vários nós rapidamente. Ambos os sistemas têm várias diferenças nos mecanismos de enfileiramento de mensagens.
Tamanho da mensagem
O Kafka e o Redis funcionam melhor quando enviam pacotes de dados pequenos entre consumidores e assinantes.
O Redis,especificamente, não foi criado para lidar com grandes tamanhos de dados sem comprometer o throughput. Ele também não é capaz de armazenar grandes quantidades de dados, pois a RAM tem uma capacidade menor do que o armazenamento em disco.
Por sua vez, o Kafka pode oferecer suporte a mensagens razoavelmente grandes, apesar de não ter sido criado especificamente para isso. O Kafka pode lidar com mensagens de até 1 GB, se ele compactar a mensagem e você configurá-la para armazenamento hierárquico. Em vez de armazenar todas as mensagens no armazenamento local, ele usa armazenamento remoto para armazenar os arquivos de log concluídos.
Entrega de mensagens
Os consumidores do Kafka efetuam pull dos dados da fila de mensagens. Cada consumidor do Kafka acompanha a mensagem que leu com um deslocamento, que é atualizado para recuperar a mensagem subsequente. Os consumidores podem detectar e rastrear mensagens duplicadas.
Já o Redis envia automaticamente a mensagem aos assinantes conectados. Os assinantes do Redis aguardam passivamente as mensagens recebidas pelo servidor. Como é uma configuração de entrega que ocorre no máximo uma vez, os assinantes do Redis não conseguem detectar mensagens duplicadas.
Retenção de mensagens
O Kafka retém as mensagens depois que os consumidores as leem. Portanto, se a aplicação cliente perder os dados recuperados, ela poderá solicitar esses dados novamente da partição na qual está inscrita. Ao definir a política de retenção de mensagens, os usuários podem determinar por quanto tempo o Kafka reterá os dados.
Por sua vez, o Redis não armazena mensagens depois que elas são entregues. Se nenhum assinante estiver conectado ao fluxo, o Redis descartará as mensagens. As mensagens descartadas não poderão ser recuperadas, mesmo que o assinante se conecte ao Redis posteriormente.
Tratamento de erros
Tanto o Kafka como o Redis permitem que as aplicações reduzam a entrega não confiável de mensagens, mas o fazem de forma diferente.
O tratamento de erros no Redis se concentra na interação entre a aplicação cliente e os serviços do Redis. Com o Redis, os desenvolvedores podem lidar com circunstâncias como tempo limite do cliente, buffer de memória excedido e limites máximos do cliente. Por causa da arquitetura de banco de dados de pares de chave-valor, o Redis não consegue fornecer um tratamento robusto de erros de mensagens como o Kafka.
Os desenvolvedores do Kafka podem armazenar eventos errôneos em uma fila de mensagens não entregues, tentar novamente ou redirecioná-las para permitir a entrega consistente de mensagens às aplicações clientes. Os desenvolvedores também podem usar a API Kafka Connect para reiniciar automaticamente as tarefas do conector em determinados erros.
Diferenças de performance: pub/sub do Kafka vs. do Redis
No geral, o Apache Kafka supera o Redis no sistema de publicação e assinatura de mensagens porque o Kafka foi criado especificamente para transmissão de dados. O Redis tem vários casos de uso diferentes em que não é possível usar o Kafka.
Paralelismo
Paralelismo é a capacidade de vários consumidores receberem a mesma mensagem simultaneamente.
O Redis não é compatível com o paralelismo.
Por sua vez, o Kafka permite que a mesma mensagem seja distribuída para vários consumidores simultaneamente. Normalmente, os consumidores dos grupos de consumidores do Kafka se revezam para recuperar novas mensagens de uma partição. Se houver apenas um único consumidor em vários grupos de consumidores, ele recuperará todas as mensagens. Ao aproveitar essa configuração e a replicação de partições, é possível atribuir um consumidor a cada grupo de consumidores em cada réplica de partição. Com isso, todos os consumidores podem recuperar uma sequência de mensagens similar.
Throughput
O throughput mede o número de mensagens que cada sistema consegue processar por segundo.
O Kafka geralmente tem um throughput maior do que o pub/sub do Redis. O Kafka lida com volumes de dados muito maiores porque não precisa esperar que cada assinante receba a mensagem antes de passar para a outra. Em vez disso, ele armazena as mensagens atuais em um cache e armazenamento de memória, otimizando a velocidade de leitura.
Porém, a performance do Kafka poderá diminuir se os consumidores não recuperarem a mensagem com rapidez suficiente, pois as mensagens não lidas no cache acabam sendo removidas. Nesse caso, os consumidores precisarão ler o disco, que é mais lento.
No entanto, o Redis deve aguardar o reconhecimento de cada consumidor, o que diminui consideravelmente seu throughput com mais nós conectados. Uma solução alternativa é enviar várias solicitações com um processo chamado pipelining, mas isso reduz a latência de mensagens.
Latência
Tanto o Kafka como o Redis são adequados para processamento de dados de baixa latência. O Redis oferece um tempo de envio de mensagens menor, que varia em milissegundos, enquanto o Kafka tem uma média de dezenas de milissegundos.
Considerando que o Redis lê e grava dados principalmente na RAM, ele naturalmente supera a velocidade do Kafka. Porém, o Redis pode não manter operações de dados de latência ultrabaixa ao lidar com mensagens maiores. Entretanto, o Kafka precisa de mais tempo para replicar partições em diferentes unidades físicas para persistência de dados, o que aumenta a sobrecarga no tempo de entrega das mensagens.
É possível otimizar a latência para o Redis e o Kafka, mas você deve fazer isso com cuidado. Por exemplo, é possível compactar as mensagens do Kafka para diminuir a latência, mas os produtores e consumidores precisam de mais tempo para descompactá-las.
A latência no Redis pode ser causada por vários fatores, como ambiente operacional, operações de rede, comandos lentos ou bifurcações. Para reduzir os atrasos de bifurcação, o Redis recomenda executar o sistema de entrega de pub/sub em instâncias modernas do EC2 com base em uma máquina virtual de hardware (HVM).
Tolerância a falhas
O Kafka grava todos os dados no disco de armazenamento de um agente principal e os replica em diferentes servidores. Quando um servidor falha, vários assinantes recuperam os dados das partições de backup.
Diferentemente do Kafka, o Redis não faz backup dos dados por padrão, e os usuários devem habilitar o atributo manualmente. O Redis usa armazenamento de dados na memória, perdendo todos os dados quando é desligado. Para evitar isso, os desenvolvedores ativam a persistência do Redis Database (RDB) para capturar periodicamente snapshots dos dados da RAM e armazená-los em disco.
Quando usar: pub/sub do Kafka vs. do Redis
O Apache Kafka é a melhor opção para desenvolver aplicações que transmitem grandes conjuntos de dados e exigem alta capacidade de recuperação. Ele foi inicialmente desenvolvido como um único pipeline de dados distribuído capaz de lidar com as trilhões de mensagens que passam. O Kafka replica partições em diferentes servidores para evitar a perda de dados quando um nó falha. As organizações usam o Kafka para oferecer suporte à comunicação em tempo real entre aplicações, dispositivos móveis da Internet das Coisas (IoT) e microsserviços. Também é a melhor opção para agregação de logs, processamento de fluxos e outras tarefas de integração de dados baseadas na nuvem.
Entretanto, o Redis fornece distribuição de eventos de latência ultrabaixa para aplicações que exigem transferência instantânea de dados, mas toleram pequenas perdas de dados. O Redis é bastante usado como cache de sessão para armazenar dados acessados com frequência ou enviar mensagens urgentes. Também é adequado para armazenar dados de jogos, comércio eletrônico ou mídias sociais para permitir uma experiência de usuário mais estável.
Resumo das diferenças: Kafka vs. pub/sub do Redis
| Apache Kafka |
Redis |
|
| Tamanho da mensagem |
Compatível com tamanho de mensagem de até 1 GB com compactação e armazenamento em camadas. |
Compatível com tamanho de mensagem menor. |
| Entrega de mensagens |
Os assinantes efetuam pull de mensagens da fila. |
O servidor Redis envia mensagens por push para assinantes conectados. |
| Retenção de mensagens |
Retém as mensagens após a recuperação. |
Não retém mensagens. |
| Tratamento de erros |
Tratamento robusto de erros no nível do sistema de mensagens. Fila de mensagens não entregues, nova tentativa de evento e redirecionamento. |
É necessário lidar com as exceções do Redis no nível da aplicação com tempos limite, limites de clientes e capacidade de buffer de memória. |
| Paralelismo |
O Kafka é compatível com o paralelismo. Vários consumidores podem recuperar a mesma mensagem simultaneamente. |
Não é compatível com o paralelismo. |
| Throughput |
Tem maior throughput devido à leitura/gravação assíncrona. |
Throughput mais baixo porque o servidor Redis precisa esperar por uma resposta antes de enviar a mensagem a outro assinante. |
| Latência |
Baixa latência. Um pouco mais lento que o Redis por causa da replicação de dados por padrão. |
Latência ultrabaixa ao distribuir mensagens de tamanho menor. |
| Tolerância a falhas |
Faz backup automático de partições para diferentes agentes. |
Não faz backup por padrão. Os usuários podem habilitar a persistência do Redis manualmente. Risco de uma pequena perda de dados. |
Como a AWS pode oferecer suporte a seus requisitos do Kafka e do Redis?
A Amazon Web Services (AWS) fornece uma infraestrutura escalável e gerenciada para dar suporte às suas necessidades de sistema de publicação e assinatura (pub/sub) de mensagens.
Use o Amazon Managed Streaming for Apache Kafka (Amazon MSK) para ingerir e processar facilmente grandes volumes de dados em tempo real. É possível criar um barramento de dados com acesso privado para fornecer nós de transmissão de alta disponibilidade em escala. Você também pode se conectar perfeitamente a outros serviços da AWS, como o AWS IoT Core, Amazon Virtual Private Cloud (Amazon VPC) e Amazon Managed Service for Apache Flink.
Use o Amazon MemoryDB para fornecer armazenamento em memória de alta disponibilidade para suas workloads do Redis. É possível executar feeds de dados de transmissão de alta simultaneidade para ingerir a atividade do usuário. E você pode oferecer suporte a milhões de solicitações por dia para aplicações de mídia e entretenimento.
Em vez do Redis ou do Kafka, também é possível usar o Amazon Simple Notification Service (Amazon SNS) para criar um sistema de publicação e assinatura de mensagens. Você pode enviar mensagens de suas aplicações diretamente para clientes ou outras aplicações de modo escalável e econômico. O Amazon SNS oferece vários atributos, tais como:
- mensagens de alto throughput, com base em push e de muitos para muitos entre sistemas distribuídos, microsserviços e aplicações sem servidor orientadas por eventos.
- Criptografia de mensagens e privacidade de tráfego.
- Recursos de fanout em todas as categorias da AWS. Isso inclui análises, computação, contêineres, bancos de dados, Internet das Coisas (IoT), machine learning (ML), segurança e armazenamento.
Comece a usar pub/sun, Redis e Kafka na AWS ao criar uma conta hoje mesmo.
