Além das mensagens: uma visão geral do Kafka Broker

Um cluster Kafka é, essencialmente, uma coleção de arquivos cheios de mensagens e que abrange muitas máquinas diferentes. Desse modo, a maior parte de seu código envolve amarrar vários desses logs individuais juntos. Ao mesmo tempo, encaminha mensagens de Producers para Consumers de maneira confiável e replica para tolerância a falhas, enquanto lida com elas com elegância.
Dessa maneira, o sistema lida com uma variedade de casos de uso, que vão do streaming de alto rendimento até os casos de missão crítica. Enquanto no streaming apenas as mensagens mais recentes importam, nos casos de missão crítica, as mensagens e sua ordem relativa devem ser preservadas, com as mesmas garantias que você esperaria de um DBMS (sistema de gerenciamento de banco de dados) ou sistema de armazenamento.

Log: Uma Estrutura Eficiente para Reter e Distribuir Mensagens

No coração do sistema de mensagens Kafka, está um log particionado e reproduzível. Por isso, a abordagem estruturada em log é uma ideia simples: uma coleção de mensagens, anexadas na sequência de um arquivo. Como resultado, quando um serviço deseja ler mensagens de Kafka, ele “busca” a posição da última mensagem lida. Em seguida, verifica enquanto lê as mensagens em ordem, ao mesmo tempo em que grava sua nova posição no log.
De fato, isso aproveita as pré-buscas, as camadas de armazenamento em cache e, naturalmente, operações em lote, tornando-os eficientes. Visto que, na verdade, quando você lê mensagens do Kafka, copia os dados diretamente do buffer do disco para o buffer da rede (cópia zero).
Portanto, as operações em lote e sequenciais ajudam no desempenho geral. Além disso, também tornam o sistema adequado para armazenar mensagens de longo prazo. Estruturas de índice constroem a maioria dos intermediadores de mensagens tradicionais, além de serem usadas gerenciar confirmações, filtrar cabeçalhos de mensagens e remover mensagens já lidas. Porém, a desvantagem desses índices é que devem permanecer na memória para ter bom desempenho, o que limita a retenção de forma significativa. Só que o log é O (1) ao ler ou escrever mensagens para uma partição. Portanto, não importa se os dados estão no disco ou em cache na memória.

Kafka garante que as mensagens sejam duráveis

Sem dúvidas, Kafka oferece durabilidade por meio de replicação. Ou seja, as mensagens são gravadas em várias máquinas para que, se uma ou mais delas falhar, as mensagens não serão perdidas. Então, se você configurar um fator de replicação de três, duas máquinas podem falhar sem ocorrer a perda de dados.
Acima de tudo, casos de uso altamente confidenciais exigem a liberação de dados para o disco, de forma síncrona. Mas, essa abordagem deve ser usada com moderação. Já que isso terá um impacto significativo no rendimento, especialmente em ambientes altamente simultâneos. Portanto, se você seguir essa abordagem, aumente o tamanho do lote do Producer para aumentar a eficácia de cada liberação de disco na máquina (lotes de mensagens são liberados juntos).
Além disso, essa abordagem também é útil para implantações em uma única máquina. Uma vez que executa um único nó do ZooKeeper ali mesmo e libera as mensagens para o disco de forma síncrona para resiliência.

Kafka e os Tópicos Compactados

A princípio, por padrão, tópicos Kafka são baseados em retenção: as mensagens são retidas por um tempo configurável. Afinal, é um tipo especial de tópico, que gerencia conjuntos de dados codificados. Ou seja, dados que têm uma chave primária (identificador), que estão em uma tabela de banco de dados. Além disso, esses tópicos retêm apenas os eventos mais recentes, enquanto os antigos, são removidos. Por isso, também suportam exclusões.
Seja como for, tópicos compactados funcionam como árvores, que mesclam estruturas de log simples (árvores LSM). Todavia, Kafka verifica o tópico periodicamente e remove as mensagens antigas, caso tenham sido substituídas (com base em sua chave). Desse modo, é importante notar que este é um processo assíncrono. Portanto, um tópico compactado pode conter algumas mensagens substituídas, que serão compactadas.
Kafka - Um tópico compactado remove as mensagens substituídas

Um tópico compactado remove as mensagens substituídas, que compartilham a mesma chave. Portanto, neste exemplo, para a chave K2, as mensagens V2 e V1 seriam eventualmente compactadas à medida que são substituídos por V3

Assim, tópicos compactados permitem algumas otimizações. Em primeiro lugar, ajudam a desacelerar o crescimento de um conjunto de dados (removendo eventos substituídos). Porém, o fazem de maneira específica para dados, em vez de, digamos, simplesmente remover mensagens com mais de duas semanas. Em segundo lugar, conjuntos de dados menores são mais fáceis de mover entre as máquinas.
Por certo, isso é importante para o processamento de fluxo com estado. Então, digamos que um serviço use o Streams API do Kafka para carregar a versão mais recente do catálogo de produtos em uma tabela. Se acaso um tópico compactado no Kafka armazena este catálogo, o carregamento é mais rápido e eficiente, caso não tenha todo o histórico com versão também (como seria o caso com um tópico regular).

Armazenamento de dados de longo prazo com Kafka

Em resumo, uma das maiores diferenças entre o Kafka e outros sistemas de mensagens é a possibilidade de ser usado como camada de armazenamento. Por isso, na verdade, não é incomum ver tópicos compactados ou baseados em retenção com mais de 100 TB de dados. Mas, o Kafka não é um banco de dados, e sim, um log de commit que não dá ampla funcionalidade de consulta (e há não há planos para que isso mude).
Entretanto, seu contrato simples é muito útil para armazenar conjuntos de dados compartilhados, em grandes sistemas ou arquiteturas de empresas. Por exemplo, o uso de eventos como uma verdadeira fonte compartilhada.
Aliás, os dados podem ser armazenados em tópicos regulares, que são ótimos para auditoria ou Event Sourcing. Ou tópicos compactados, que reduzem a pegada geral. Seja como for, você pode combiná-los e obter o melhor dos dois mundos com preço de armazenamento adicional, para manter e vincular com um serviço do Kafka Streams. Este padrão é o mais recente.

Segurança

Em síntese, o Kafka fornece uma série de recursos de segurança de nível empresarial, tanto para autenticação e quanto para autorização. Dessa maneira, faz a autenticação do cliente por meio de certificados Kerberos ou Transport Layer Security (TLS), garantindo que o cluster Kafka sabe quem está fazendo cada solicitação. Além disso, também existe um sistema de permissões semelhante ao Unix, que controla quais usuários acessam determinados dados. Em princípio, a comunicação da rede pode ser criptografada, permitindo enviar as mensagens com segurança em redes não confiáveis. Finalmente, os administradores podem exigir autenticação para comunicação entre Kafka e ZooKeeper.
Enfim, as cotas de mecanismo podem ser vinculadas a essa noção de identidade. Assim, os recursos de segurança do Kafka são estendidos aos diferentes componentes da plataforma Confluent (Rest Proxy, Confluent Schema Registry, Replicator, etc.).

Resumo

Em suma, Kafka é um pouco diferente da sua tecnologia média de mensagens. Sendo projetado como um componente de infraestrutura distribuído e escalonável, torna-se um backbone ideal através do qual serviços podem trocar e armazenar eventos em buffer. Por isso, obviamente, tem uma série de elementos exclusivos da própria tecnologia. No entanto, se destacam suas habilidades de escala, execução contínua e retenção de conjuntos de dados de longo prazo.
Este artigo é apenas uma pequena parte do e-book “Projetando Sistemas com Orientação a Eventos”. Para acessar a todo o conteúdo agora mesmo e de graça, basta baixar aqui. Aproveite a leitura!
Este artigo é apenas uma pequena parte do ebook completo e gratuito “Projetando Sistemas com Orientação a Eventos”. Aproveite para baixar e ler sempre que quiser ou consultar sempre que precisar.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Share This