Phenquestions
Observe que esta não é uma lição introdutória. Leia O que é Apache Kafka e como ele funciona antes de continuar com esta lição para obter uma visão mais profunda.
Tópicos em Kafka
Um Tópico em Kafka é algo para onde uma mensagem é enviada. Os aplicativos de consumo que estão interessados naquele tópico puxam a mensagem para dentro desse tópico e podem fazer qualquer coisa com esses dados. Até um determinado momento, qualquer número de aplicativos de consumidor pode puxar esta mensagem qualquer número de vezes.
Considere um tópico como a página de blog do Ubuntu da LinuxHint. As lições são colocadas para a eternidade e qualquer número de leitores entusiastas pode vir e ler essas lições quantas vezes quiser ou passar para a próxima lição como desejarem. Esses leitores também podem se interessar por outros tópicos do LinuxHint.
Particionamento de Tópico
O Kafka foi projetado para gerenciar aplicativos pesados e enfileirar um grande número de mensagens que são mantidas dentro de um tópico. Para garantir alta tolerância a falhas, cada tópico é dividido em várias partições de tópico e cada partição de tópico é gerenciada em um nó separado. Se um dos nós cair, outro nó pode atuar como o líder do tópico e pode servir de tópicos para os consumidores interessados. Veja como os mesmos dados são gravados em várias partições de tópico:
Partições de tópico
Agora, a imagem acima mostra como os mesmos dados são replicados em várias partições. Vamos visualizar como diferentes partições podem atuar como líderes em diferentes nós / partições:
Particionamento do Kafka Broker
Quando um cliente grava algo em um tópico em uma posição para a qual a Partição no Broker 0 é o líder, esses dados são replicados entre os corretores / nós para que a mensagem permaneça segura:
Replicação em partições de corretor
Mais partições, maior rendimento
Kafka faz uso de Paralelismo para fornecer um rendimento muito alto para aplicativos de produtor e consumidor. Na verdade, da mesma forma, ele também mantém seu status de ser um sistema altamente tolerante a falhas. Vamos entender como o alto rendimento é alcançado com o paralelismo.
Quando um aplicativo Produtor grava alguma mensagem em uma partição no Broker 0, o Kafka abre vários encadeamentos em paralelo para que a mensagem possa ser replicada em todos os Brokers selecionados ao mesmo tempo. No lado do consumidor, um aplicativo consumidor consome mensagens de uma única partição por meio de um encadeamento. Quanto maior o número de partições, mais threads de consumo podem ser abertos para que todos eles possam trabalhar em paralelo também. Isso significa que quanto maior o número de partições em um cluster, mais paralelismo pode ser explorado, criando um sistema de rendimento muito alto.
Mais partições precisam de mais gerenciadores de arquivos
Assim você estudou acima como podemos aumentar o desempenho de um sistema Kafka apenas aumentando o número de partições. Mas precisamos ter cuidado com o limite que estamos caminhando para.
Cada partição de tópico no Kafka é mapeada para um diretório no sistema de arquivos do servidor broker onde está sendo executado. Dentro desse diretório de log, haverá dois arquivos: um para o índice e outro para os dados reais por segmento de log. Atualmente, no Kafka, cada corretor abre um identificador de arquivo para o índice e o arquivo de dados de cada segmento de log. Isso significa que se você tiver 10.000 partições em um único Broker, isso resultará em 20.000 manipuladores de arquivos em execução em paralelo. Embora se trate apenas da configuração do Broker. Se o sistema no qual o Broker está implantado tiver uma configuração alta, isso dificilmente será um problema.
Risco com alto número de partições
Como vimos nas imagens acima, Kafka faz uso da técnica de replicação intra-cluster para replicar uma mensagem de um líder para as partições de réplica que estão em outros Brokers. Os aplicativos de produtor e consumidor leem e gravam em uma partição que atualmente é a líder dessa partição. Quando um corretor falha, o líder desse corretor ficará indisponível. Os metadados sobre quem é o líder são mantidos no Zookeeper. Com base nesses metadados, Kafka atribuirá automaticamente a liderança da partição a outra partição.
Quando um Broker é encerrado com um comando de limpeza, o nó do controlador do cluster Kafka moverá os líderes do broker de encerramento em série i.e. um por vez. se considerarmos que mover um único líder leva 5 milissegundos, a indisponibilidade dos líderes não perturbará os consumidores, pois a indisponibilidade é por um período muito curto de tempo. Mas se considerarmos quando o Broker é morto de maneira impura e este Broker contém 5.000 partições e, dessas, 2.000 eram os líderes de partição, atribuir novos líderes para todas essas partições levará 10 segundos, o que é muito alto quando se trata de aplicativos sob demanda.
Conclusão
Se considerarmos um pensador de alto nível, mais partições em um cluster Kafka levam a uma maior taxa de transferência do sistema. Tendo essa eficiência em mente, também é preciso considerar a configuração do cluster Kafka que precisamos manter, a memória que precisamos atribuir a esse cluster e como podemos gerenciar a disponibilidade e latência se algo der errado.
Leia mais posts baseados no Ubuntu aqui e muito mais sobre o Apache kafka também.
