Qual é a diferença entre o Kafka e o Redis OSS?
O Redis OSS é um armazenamento de dados de chaves e valores na memória, enquanto o Apache Kafka é um mecanismo de processamento de fluxos. 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 OSS oferece suporte a um sistema baseado em push em que o editor distribui mensagens para todos os assinantes quando ocorre um evento.
Como funcionam: pub/sub do Kafka vs. Redis OSS pub/sub
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.
Enquanto isso, o Redis OSS foi projetado como um banco de dados em memória que oferece suporte à 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 assinar um fluxo do Redis OSS para recuperar mensagens.
Embora você possa usar ambos para mensagens pub/sub, o Kafka e o Redis OSS funcionam de maneiras diferentes.
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 OSS
O Redis OSS é executado com uma arquitetura 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 OSS usa chaves e nós primários-secundários para esses 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 para um nó específico, o Redis OSS entrega essa 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 OSS 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. Redis OSS pub/sub
O Apache Kafka fornece aos desenvolvedores sistemas de mensagens distribuídos altamente escaláveis. Enquanto isso, o Redis OSS oferece estruturas de dados ricas que permitem que uma 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 OSS funcionam melhor quando enviam pacotes de dados pequenos entre consumidores e assinantes.
O Redis OSS, em particular, não foi projetado 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.
Por outro lado, o Redis OSS envia automaticamente a mensagem para os assinantes conectados. Os assinantes do Redis OSS aguardam passivamente pelas mensagens recebidas do servidor. Como é uma configuração de entrega que ocorre no máximo uma vez, os assinantes do Redis OSS não são capazes de 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 outro lado, o Redis OSS não armazena mensagens depois que elas são entregues. Se nenhum assinante estiver conectado ao fluxo, o Redis OSS descartará as mensagens. As mensagens descartadas não podem ser recuperadas, mesmo que o assinante se conecte ao Redis OSS posteriormente.
Tratamento de erros
Tanto o Kafka quanto o Redis OSS permitem que as aplicações reduzam a entrega não confiável de mensagens, mas o fazem de maneira diferente.
O tratamento de erros no Redis OSS se concentra na interação entre a aplicação cliente e os serviços do Redis OSS. Com o Redis OSS, os desenvolvedores podem lidar com circunstâncias como tempos limite do cliente, buffer de memória excedido e limites máximos do cliente. Por causa de sua arquitetura de banco de dados de pares de valores-chave, o Redis OSS não pode 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. Redis OSS pub/sub
No geral, o Apache Kafka supera o Redis OSS em mensagens pub/sub porque o Kafka foi projetado especificamente para streaming de dados. O Redis OSS tem vários casos de uso diferentes em que o Kafka não pode ser usado.
Paralelismo
Paralelismo é a capacidade de vários consumidores receberem a mesma mensagem simultaneamente.
O Redis OSS não oferece suporte para 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 maior throughput do que o Redis OSS pub/sub. 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.
Enquanto isso, o Redis OSS deve aguardar o reconhecimento de cada consumidor, o que diminui significativamente 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 quanto o Redis OSS são adequados para processamento de dados de baixa latência. O Redis OSS oferece tempo de mensagens menor, que varia em milissegundos, enquanto o Kafka tem uma média de dezenas de milissegundos.
Considerando que o Redis OSS lê e grava dados principalmente na RAM, ele naturalmente supera o Kafka em velocidade. No entanto, o Redis OSS 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 Redis OSS e 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 OSS pode ser causada por vários fatores, incluindo o ambiente operacional, operações de rede, comandos lentos ou bifurcação. Para reduzir os atrasos na bifurcação, o Redis OSS recomenda executar o sistema de entrega 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.
Ao contrário do Kafka, o Redis OSS não faz backup de dados por padrão, e os usuários devem ativar o recurso manualmente. O Redis OSS usa armazenamento de dados na memória, que perde todos os dados quando desligado. Para evitar isso, os desenvolvedores ativam a persistência do Redis OSS Database (RDB) para capturar periodicamente snapshots dos dados da RAM e armazená-los no disco.
Quando usar: pub/sub do Kafka vs. Redis OSS pub/sub
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.
Enquanto isso, o Redis OSS 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 OSS é comumente usado como um cache de sessão para armazenar dados acessados com frequência ou entregar 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. do Redis
| Apache Kafka |
Redis OSS |
|
| 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 OSS envia mensagens 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. |
Você deve lidar com as exceções do Redis OSS no nível do aplicativo com tempos limite, limites de cliente 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. |
Menor taxa de transferência porque o servidor Redis OSS precisa esperar por uma resposta antes de enviar a mensagem para outro assinante. |
| Latência |
Baixa latência. Um pouco mais lento que o Redis OSS devido à 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 ativar manualmente a persistência do Redis OSS. Risco de uma pequena perda de dados. |
Como a AWS pode oferecer suporte aos seus requisitos de OSS 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 OSS. É 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 OSS ou do Kafka, você também pode usar o Amazon Simple Notification Service (Amazon SNS) para criar um sistema de mensagens pub/sub. 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/sub, Redis OSS e Kafka na AWS criando uma conta hoje mesmo.
