Resolução

Os consumidores do Apache Kafka normalmente fazem parte de um grupo de consumidores. Cada consumidor do grupo de consumidores recebe mensagens de um subconjunto diferente de partições no tópico quando acontece o seguinte:

• Vários consumidores se inscrevem em um tópico.
• Esses consumidores pertencem ao mesmo grupo de consumidores.

Quando um consumidor não consegue acessar o cluster, o coordenador do grupo remove o consumidor do grupo de consumidores. Esse processo inicia um evento de rebalanceamento que inclui as seguintes ações:

• Os consumidores restantes são dispensados de suas partições.
• O coordenador do grupo redistribui as partições do tópico para os demais consumidores.

Seu grupo de consumidores pode se reequilibrar nas seguintes condições:

• Você transferiu a propriedade da partição de um consumidor para outro em um grupo de consumidores.
• Você adicionou um novo consumidor ao grupo de consumidores.
• Um consumidor fecha, trava ou sai do grupo de consumidores.
• Você modificou os tópicos e ocorre um realinhamento da partição.
• Há um problema de configuração do cliente nas assinaturas de grupos de consumidores. Isso é resultado de uma incompatibilidade entre os tópicos inscritos pelo grupo e o tópico atribuído a cada consumidor individual no grupo.

Os consumidores do mesmo grupo de consumidores não podem continuar consumindo dados até que o evento de rebalanceamento seja concluído. Esse é o comportamento padrão da atribuição de partições. Você pode evitar isso alterando a estratégia de atribuição de partições para CooperativeStickyAssignor.

Para evitar o rebalanceamento contínuo do seu grupo de consumidores, tente o seguinte:

• Diminua o valor max.partition.fetch.bytes ou aumente o valor do tempo limite da sessão (session.timeout.ms) na configuração do consumidor. O consumidor deve chamar poll() com frequência para evitar o tempo limite da sessão e o rebalanceamento subsequente. Se a quantidade de dados retornada por uma única poll() for grande, o consumidor poderá levar muito tempo para processar os dados. Isso significa que o consumidor não chega à próxima iteração do ciclo de pesquisa a tempo de evitar o tempo limite da sessão.
  Observação: definir um valor mais alto para session.timeout.ms reduz a possibilidade de rebalanceamento acidental. No entanto, pode levar mais tempo para detectar uma falha real. Esse parâmetro está relacionado a heartbeat.interval.ms. O parâmetro heartbeat.interval.ms controla a frequência com que o método kafkaConsumer poll() envia uma pulsação ao coordenador do grupo. No entanto, o parâmetro session.timeout.ms controla quanto tempo um consumidor pode ficar sem enviar uma pulsação.
  Por exemplo, suponha que você esteja executando o Apache Kafka 0.10.1 ou posterior e manipulando registros que demoram mais para serem processados. Nesse caso, ajuste max.poll.interval.ms para lidar com maiores atrasos entre a pesquisa de novos registros.
• Certifique-se de que o valor de session.timeout.ms na configuração do consumidor seja menor do que o de group.max.session.timeout.ms na configuração do agente.
• max.poll.interval.ms coloca um limite superior na quantidade de tempo que o consumidor pode ficar inativo antes de buscar mais registros. Por padrão, o valor definido é 5 minutos. Se esse valor for definido para menos de 5 minutos, aumente-o para reduzir a possibilidade de rebalanceamento. Você também pode considerar diminuir max.poll.records junto com max.poll.interval.ms.
• heartbeat.interval.ms é o tempo esperado entre as pulsações e o coordenador do consumidor quando você está usando as instalações de gerenciamento de grupo do Kafka. As pulsações são usadas para garantir que a sessão do consumidor permaneça ativa. Eles facilitam o reequilíbrio quando novos consumidores entram ou saem do grupo. Esse valor deve ser definido como um valor menor que session.timeout.ms. Normalmente, esse valor deve ser definido como um valor que não seja superior a um terço de session.timeout.ms. Você pode optar por reduzir muito o valor heartbeat.interval.ms para controlar o tempo esperado para rebalanceamentos normais.
• Se você realizou uma reatribuição de partição recentemente que envolva alterações nas partições em um dos tópicos inscritos do grupo de consumidores, o grupo de consumidores poderá rebalancear. Isso ocorre porque as partições envolvidas são movidas ou alteradas. Nesse caso, evite reiniciar o coordenador do grupo ou outros corretores do Kafka. Você deve aguardar a conclusão da reatribuição da partição antes de tentar impedir o rebalanceamento do grupo de consumidores. É uma prática recomendada fazer reatribuições de partições durante períodos de baixo tráfego.

Em alguns casos, você pode ver as seguintes informações nos registros do agente Amazon MSK:

[2023-03-01 01:23:45,678] INFO [GroupCoordinator 1]: Preparing to rebalance group amazon.msk.canary.group.broker-1 in state PreparingRebalance with old generation 382660 (__consumer_offsets-21) (reason: Adding new member consumer-amazon.msk.canary.group.broker-1-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx with group instance id None) (kafka.coordinator.group .GroupCoordinator)

Essa mensagem indica que amazon.msk.canary.group.broker-n está no estado PreparingRebalance.

Os grupos amazon.msk.canary.group.broker-n são grupos internos de consumidores que são adicionados ou removidos regularmente para verificar a integridade do cluster e as métricas de diagnóstico. Esses grupos são insignificantes em tamanho e não podem ser excluídos. Você pode ignorar essa mensagem.

Informações relacionadas

Grupo de consumidores preso na preparação do estado de rebalanceamento