Entrar Ainda não tem acesso?
Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

[Dúvida] Quantidade de partições e autoscale de PODs

Referente ao curso Kafka: Fast delegate, evolução e cluster de brokers

por Jeferson Fischer
| 9k xp | 8 posts

Boa tarde!

Estou com uma dúvida de como funcionaria e o que poderia ocorrer no consumo de mensagens em uma aplicação que tenho um numero X de partições e minha aplicação com autoscale habilitado.

Exemplo:

Tenho um tópico configurado com 10 partições e inicialmente 1 POD, que processa as mensagens de forma async usando virtual threads, vai chegar um momento que minha aplicação através das configurações irá escalar para 2 POD, porém o primeiro POD ainda estava consumido. Com o surgimento deste segundo POD irá o ocorrer o rebalancing, onde cada POD ficará com 5 partições.

As dúvidas são:

se durante esse rebalanceamento o partição que estava processando um poll de mensagens irá parar o processamento para que o ocorra o rebalanceamento ou se apenas será atribuidas partições que não estava sendo consumidas no momento para o novo POD?

Ele irá aguardar finalizar o poll para fazer o rebalancing?

por padrão o kafka utiliza a estratégia de rebalanceamento EAGER, caso estive configurado como COOPERATIVE qual seria o comportamento?

grato.

2 respostas
por Lorena Garcia
| 8074.8k xp | 11737 posts
Alura Scuba Team Suporte Educacional

Oii Jeferson, tudo bem?

Rebalanceamento EAGER:

No rebalanceamento padrão (EAGER), quando um novo POD é adicionado, o Kafka interrompe o consumo de mensagens em todos os consumidores do grupo para redistribuir as partições. Isso significa que, sim, durante o rebalanceamento, as partições que estavam sendo processadas podem parar temporariamente até que o novo balanceamento seja concluído. Isso pode causar uma breve interrupção no processamento das mensagens.

Rebalanceamento COOPERATIVE:

Se você configurar o rebalanceamento como COOPERATIVE, o comportamento será diferente. O rebalanceamento cooperativo é mais suave e menos disruptivo. Nesse caso, as partições são movidas de forma incremental e controlada. Isso significa que o Kafka tentará minimizar a interrupção do processamento das mensagens, movendo as partições gradualmente para os novos consumidores.

Exemplo Prático

Vamos considerar seu exemplo com 10 partições e 1 POD inicial que escala para 2 PODs:

  1. EAGER: Quando o segundo POD é adicionado, o Kafka interromperá o consumo em ambos os PODs, redistribuirá as partições (5 para cada um) e, em seguida, retomará o consumo. Isso pode resultar em uma pequena pausa no processamento das mensagens.

  2. COOPERATIVE: O Kafka moverá as partições de forma incremental. Inicialmente, o segundo POD pode começar a consumir algumas das partições enquanto o primeiro POD ainda está processando suas mensagens. Isso reduz a interrupção no consumo.

Então,

  • EAGER: Pode causar interrupções mais perceptíveis, mas é simples e direto.
  • COOPERATIVE: Reduz as interrupções, mas pode ser um pouco mais complexo de gerenciar.

Espero ter ajudado.

Um abraço e bons estudos.

solução!
por Jeferson Fischer
| 9k xp | 8 posts

Olá Lorena, tudo certo e contigo?

Ajudou sim, obrigado. Fiz algumas simulações que confirmaram o que falamos, porém tive alguns problemas usando COOPERATIVE, onde durante o particionamento dois PODs distintos consumiam da mesma partição.

consumo concorrenteAinda vou fazer mais alguns teste para entender esse comportamento. Att.