Phenquestions
Essa visão geral é um pouco abstrata, então vamos colocá-la em um cenário do mundo real, imagine que você precisa monitorar vários servidores da web. Cada um executando seu próprio site, e novos logs são gerados constantemente em cada um deles a cada segundo do dia. Além disso, há vários servidores de e-mail que você também precisa monitorar.
Você pode precisar armazenar esses dados para fins de manutenção de registros e cobrança, que é um trabalho em lote que não requer atenção imediata. Você pode querer executar análises sobre os dados para tomar decisões em tempo real, o que requer uma entrada de dados precisa e imediata. De repente, você se encontra na necessidade de agilizar os dados de uma forma sensata para todas as várias necessidades. Kafka atua como aquela camada de abstração para a qual várias fontes podem publicar diferentes fluxos de dados e um determinado consumidor pode se inscrever nos streams que achar relevantes. Kafka se certificará de que os dados estejam bem ordenados. É o interior do Kafka que precisamos entender antes de chegarmos ao tópico de Particionamento e Chaves.
Tópicos, corretor e partições do Kafka
Kafka Tópicos são como tabelas de um banco de dados. Cada tópico consiste em dados de uma fonte específica de um tipo específico. Por exemplo, a integridade do cluster pode ser um tópico que consiste em informações de utilização de CPU e memória. Da mesma forma, o tráfego de entrada para todo o cluster pode ser outro tópico.
O Kafka foi projetado para ser horizontalmente escalável. Ou seja, uma única instância de Kafka consiste em vários Kafka corretores executando em vários nós, cada um pode lidar com fluxos de dados paralelos ao outro. Mesmo se alguns dos nós falharem, o pipeline de dados pode continuar a funcionar. Um tópico específico pode ser dividido em vários partições. Esse particionamento é um dos fatores cruciais por trás da escalabilidade horizontal do Kafka.
Múltiplo produtores, fontes de dados para um determinado tópico, podem gravar nesse tópico simultaneamente porque cada uma grava em uma partição diferente, em qualquer ponto. Agora, geralmente os dados são atribuídos a uma partição aleatoriamente, a menos que forneçamos uma chave.
Particionamento e pedido
Só para recapitular, os produtores estão gravando dados em um determinado tópico. Esse tópico está realmente dividido em várias partições. E cada partição vive independentemente das outras, mesmo para um determinado tópico. Isso pode levar a muita confusão quando a ordem de dados é importante. Talvez você precise de seus dados em ordem cronológica, mas ter várias partições para seu fluxo de dados não garante uma ordem perfeita.
Você pode usar apenas uma única partição por tópico, mas isso anula todo o propósito da arquitetura distribuída do Kafka. Então, precisamos de alguma outra solução.
Chaves para partições
Os dados de um produtor são enviados para partições aleatoriamente, como mencionamos antes. As mensagens são os blocos reais de dados. O que os produtores podem fazer além de apenas enviar mensagens é adicionar uma chave que vai junto com ele.
Todas as mensagens que vêm com a chave específica irão para a mesma partição. Assim, por exemplo, a atividade de um usuário pode ser rastreada cronologicamente se os dados desse usuário estiverem marcados com uma chave e sempre terminarem em uma partição. Vamos chamar essa partição de p0 e o usuário u0.
A partição p0 sempre pegará as mensagens relacionadas a u0 porque essa chave os une. Mas isso não significa que p0 está apenas vinculado a isso. Ele também pode receber mensagens de u1 e u2 se tiver capacidade para isso. Da mesma forma, outras partições podem consumir dados de outros usuários.
O ponto em que os dados de um determinado usuário não estão espalhados por uma partição diferente, garantindo a ordem cronológica para esse usuário. No entanto, o tópico geral de dados do usuário, ainda pode aproveitar a arquitetura distribuída do Apache Kafka.
Conclusão
Enquanto sistemas distribuídos como o Kafka resolvem alguns problemas mais antigos, como falta de escalabilidade ou ter um único ponto de falha. Eles vêm com um conjunto de problemas que são exclusivos de seu próprio design. Antecipar esses problemas é um trabalho essencial de qualquer arquiteto de sistema. Não só isso, às vezes você realmente precisa fazer uma análise de custo-benefício para determinar se os novos problemas são uma compensação válida para se livrar dos mais antigos. O pedido e a sincronização são apenas a ponta do iceberg.
Felizmente, artigos como esses e a documentação oficial podem ajudá-lo ao longo do caminho.
