O Apache Kafka utiliza o ZooKeeper para armazenar metadados essenciais, coordenar brokers, gerenciar tópicos e monitorar consumidores. Esta abordagem permite a distribuição e tolerância a falhas em um cluster. A estrutura de armazenamento inclui nós znodes que mantêm informações sobre tópicos, partições, brokers, controladores e grupos de consumidores.

Estrutura Hierárquica no ZooKeeper

O Kafka organiza seus dados em caminhos específicos no ZooKeeper, como /brokers para informações de brokers e /consumers para detalhes de consumidores. Cada caminho contém znodes que podem ser persistentes ou temporários, refletindo o estado do cluster.

Detalhes de Registro de Tópicos

Os tópicos são registrados em znodes como /brokers/topics/[nome_do_topico], onde se armazena a distribuição das partições entre os brokers. O conteúdo é um documento JSON que mapeia IDs de partições para listas de IDs de brokers.

{
  "versao": 1,
  "particoes": {
    "particao_0": [3, 1, 2],
    "particao_1": [1, 2, 0],
    "particao_2": [2, 0, 3]
  }
}

Estado das Partições

Cada partição de um tópico tem um znode de estado em /brokers/topics/[nome_do_topico]/partitions/[id_da_particao]/state. Este nó contém informações sobre o líder, réplicas sincronizadas (ISR) e contagens de épocas.

{
  "epoca_controlador": 1,
  "lider": 3,
  "versao": 1,
  "epoca_lider": 0,
  "isr": [3, 0, 1]
}

Informações de Registro de Brokers

Cada broker no cluster é identificado por um ID único e registrado em /brokers/ids/[id_do_broker]. Este znode é temporário e contém detalhes como host, porta e carimbo de tempo.

{
  "porta_jmx": -1,
  "carimbo_tempo": "1633072800000",
  "versao": 1,
  "host": "servidor1",
  "porta": 9092
}

Época do Controlador

O znode /controller_epoch mantém um número inteiro que indica a contagem de eleições do controlador central no cluster Kafka. Ele é incrementado sempre que o controlador é alterado ou falha.

Registro do Controlador

O controlador central é registrado em /controller, contendo o ID do broker atual como controlador e um carimbo de tempo da última alteração.

{
  "versao": 1,
  "id_broker": 0,
  "carimbo_tempo": "1633072800000"
}

Grupos de Consumidores e Balanceamento

Os consumidores se registram no ZooKeeper para facilitar o balanceamento de carga. Dentro de um grupo de consumidores, cada mensagem de um tópico é anviada para apenas um consumidor, garantindo a distribuição. O número total de threads de consumo deve ser igual ou menor que o número de partições para evitar threads ociosas.

Exemplo: Considere um tópico com 4 partições (P0, P1, P2, P3) e 3 consumidores (C0, C1, C2). Se cada consumidor tiver uma thread, a distribuição pode ser: C0 consome P0 e P1, C1 consome P2, C2 consome P3. Se houver mais threads, alguns consumidores podem ficar inativos.

Algoritmo de Balanceamento de Consumidores

Quando consumidores entram ou saem de um grupo, as partições são redistribuídas. O processo envolve ordenar partições e consumidores, calcular um fator de multiplicidade e alocar partições proporcionalmente. Para tópico com partições P0 a P3 e consumidores C0 e C1, o fator M é 2 (arredondado para cima), resultando em C0 = [P0, P1] e C1 = [P2, P3].

Registro de Consumidores

Cada consumidor é identificado por um ID único, registrado em /consumers/[id_grupo]/ids/[id_consumidor]. Este znode temporário contém assinaturas de tópicos e configurações de padrão.

{
  "versao": 1,
  "assinatura": {
    "topico_exemplo": 1
  },
  "padrao": "lista_branca",
  "carimbo_tempo": "1633072800000"
}

Propriedade de Consumidores

O caminho /consumers/[id_grupo]/owners/[nome_topico]/[id_particao] mapeia partições para consumidores específicos, facilitando a recuperação em caso de falhas. Watches são configurados para monitorar mudanças e acionar o reequilíbrio.

Offsets de Consumidores

Os offsets consumidos por cada grupo são armazenados em /consumers/[id_grupo]/offsets/[nome_topico]/[id_particao]. Este znode persistente rastreia o maior offset processado, permitindo a continuidade após falhas.

Realocação de Partições

Para redistribuir partições entre brokers, o Kafka usa o znode /admin/reassign_partitions. Ele define um esquema JSON para especificar novas réplicas para partições específicas.

{
  "versao": 1,
  "particoes": [
    {
      "topico": "Topico_A",
      "particao": 1,
      "replcias": [0, 2, 3]
    }
  ]
}

Eleição de Réplicas Preferidas

O caminho /admin/preferred_replica_election é usado para acionar eleições de líderes para partições, garantindo que a réplica preferida seja selecionada como líder quando disponível.

{
  "versao": 1,
  "particoes": [
    {
      "topico": "Topico_B",
      "particao": 0
    }
  ]
}

Exclusão de Tópicos

A exclusão de tópicos é gerenciada através de /admin/delete_topics, onde uma lista de nomes de tópicos é especificada para remoção.

{
  "versao": 1,
  "topicos": ["topico_antigo1", "topico_antigo2"]
}

Configurações de Tópicos

Configurações adicionais para tópicos são armazenadas em /config/topics/[nomme_do_topico], permitindo ajustes dinâmicos sem reiniciar o cluster.