O acúmulo de mensagens ocorre quando o offset confirmado de um grupo de consumidores fica atrás do offset de produção mais recente do broker (high-water mark). A diferença entre esses dois offsets é a contagem de mensagens acumuladas. Uma contagem crescente nem sempre indica um problema — o que importa é se o consumo acompanha a produção. Use este guia para diagnosticar se o acúmulo é normal e resolver casos anormais.
Como funciona o consumo de mensagens
Antes de diagnosticar o acúmulo, entenda o ciclo de consumo de duas fases em cada cliente:
Pull: O cliente busca mensagens do broker.
Process: O cliente executa a lógica de negócios em cada mensagem e, em seguida, confirma o offset do consumidor no broker.
A contagem de mensagens acumuladas equivale à high-water mark do broker menos o offset confirmado do grupo de consumidores. Um valor alto, por si só, não indica problema. Concentre-se na tendência: a diferença está estável, aumentando ou é causada por offsets não confirmados?
Diagnosticar o acúmulo
Para verificar se o acúmulo é normal, analise as métricas do grupo de consumidores no console do ApsaraMQ for Kafka:
Faça logon no console do ApsaraMQ for Kafka.
Na barra de navegação superior, selecione a região onde a sua instância está localizada.
No painel de navegação à esquerda, clique em Instances.
Na página Instances, clique no nome da instância de destino.
Na página Instance Details, clique em Groups no painel de navegação à esquerda.
Na página Groups, localize o grupo de destino e escolha More > Consumer Status na coluna Actions.
Na página Consumer Status, verifique os valores de Last Consumed At, Accumulated Messages e Consumer Offset.
O sistema atualiza esses valores a cada 1 minuto. Clique em Consumption Details e visualize o offset do consumidor para cada partição.
Use a tabela de decisão a seguir para interpretar as métricas:
|
Sintoma |
Diagnóstico |
Ação |
|
O valor de Last Consumed At está próximo do horário atual e Accumulated Messages flutua em uma faixa estável |
Normal — o cliente busca e processa mensagens em um ritmo constante. |
Nenhuma ação é necessária. |
|
Accumulated Messages aumenta continuamente e Consumer Offset permanece inalterado |
Anormal — a thread do consumidor está bloqueada. O cliente parou de processar mensagens e de confirmar offsets. |
Consulte Resolve abnormal accumulation. |
|
Accumulated Messages aumenta continuamente, mas Consumer Offset avança |
Anormal — o consumo está muito lento. O cliente processa mensagens, mas a taxa de processamento é menor que a taxa de produção. O gargalo está na fase de processamento (fase 2), e não na fase de pull. |
Consulte Resolve abnormal accumulation. |
|
As mensagens parecem acumuladas nas partições, mas o processamento downstream está normal |
Provável falso positivo. Se o sistema downstream usar o modo de consumo |
Confirme os offsets manualmente para limpar o acúmulo relatado. |
|
Accumulated Messages aumenta e Consumer Offset avança lentamente, mas o monitoramento da largura de banda do consumidor no nível da instância indica que o throughput atingiu o limite de taxa |
Provável limitação de taxa do consumidor. A instância acionou a limitação de throughput do consumidor. O cliente não está completamente bloqueado: ele ainda busca mensagens, mas em uma taxa restrita, o que causa acúmulo gradual. |
Nesse caso, verifique as métricas de monitoramento da largura de banda do consumidor no nível da instância. Se você confirmar a limitação, considere atualizar a especificação da instância ou reduzir o volume de pull do consumidor. |
|
Accumulated Messages aumenta significativamente em um tópico e o consumo diminui em outros tópicos na mesma instância |
Possível impacto indireto de leituras a frio (cold reads). O acúmulo em um único tópico normalmente não afeta diretamente outros tópicos na mesma instância. No entanto, se o sistema gravou as mensagens acumuladas no disco, a recuperação aciona I/O de disco em vez de leituras na memória (leitura a frio). IOPS de leitura de disco ou throughput altos podem degradar o desempenho geral da instância. |
Nesse caso, verifique as métricas de monitoramento de I/O de disco e de throughput de rede no nível da instância. Se o IOPS de leitura de disco ou o tráfego estiverem anormalmente altos, priorize a redução do acúmulo no tópico afetado. |
Um valor alto de Accumulated Messages nem sempre significa um problema. A contagem exibida depende da taxa de produção e da frequência de confirmação de offset. Por exemplo, se um tópico recebe 10.000 mensagens por segundo e o sistema confirma os offsets uma vez por segundo, a contagem acumulada normalmente flutua em torno de 10.000.
Resolver acúmulo anormal
Depois de confirmar o acúmulo anormal, identifique o gargalo e aumente a taxa de consumo.
Identificar o gargalo
Determine se a thread do consumidor está bloqueada ou apenas lenta:
Thread bloqueada: Se o Consumer Offset não avança, a thread do consumidor provavelmente está travada. Use o
jstack(para aplicações Java) para capturar um thread dump e identificar o ponto de bloqueio. Para mais informações, consulte jstack - Stack Trace.Processamento lento: Se o Consumer Offset avança, mas fica para trás em relação à produção, analise o perfil da lógica de processamento de mensagens na sua aplicação. Procure chamadas de I/O lentas, gravações no banco de dados ou operações de bloqueio na fase de processamento.
Aumentar a taxa de consumo
Use uma ou ambas as seguintes abordagens:
Adicionar consumidores: Adicione mais instâncias de consumidor no mesmo grupo de consumidores, como threads adicionais em um processo existente ou como processos separados. Cada consumidor gerencia uma ou mais partições. Se o número de consumidores já for igual ou superior ao número de partições, adicionar mais consumidores não surte efeito, e os consumidores extras permanecem ociosos.
Aumentar threads de consumo: Use o consumo multithread em cada instância de consumidor. Para detalhes de implementação, consulte a seção "Aumentar a taxa de consumo" em Best practices for consumers.
Na maioria dos casos, o consumo lento de mensagens ou uma thread de consumo bloqueada causa o acúmulo anormal de mensagens. Evite definir durações longas para os parâmetros relacionados na lógica de consumo.
Verificar rebalanceamentos
Se houver mensagens acumuladas e o status do consumidor parecer anormal no console, o grupo de consumidores pode estar em rebalanceamento. Durante um rebalanceamento, o sistema não consome mensagens.
Rebalanceamentos frequentes normalmente resultam da conexão e desconexão de consumidores em alta taxa. Para mais informações, consulte Why do rebalances frequently occur on my consumer client?
Solucionar erros de read tcp i/o timeout
P: O dimensionamento vertical da instância do ApsaraMQ for Kafka resolve erros de read tcp i/o timeout que causam acúmulo de mensagens?
R: O dimensionamento vertical normalmente não resolve diretamente os erros de read tcp i/o timeout. Esse erro geralmente se relaciona a problemas de conectividade de rede ou de configuração do cliente, e não a restrições de recursos no lado do servidor. Antes de considerar o scale-up, siga estas etapas de solução de problemas:
Confirme se a conexão de rede entre o cliente e o broker está estável, e verifique se há perda de pacotes, alta latência ou problemas de conectividade intermitente.
Confira a versão do cliente. Se a versão do cliente for anterior a 0.10.1.0, atualize para uma versão suportada.
Ajuste os parâmetros
max.poll.interval.msesession.timeout.ms. Se esses valores forem muito curtos para processar cada lote de poll, o cliente pode atingir o tempo limite e acionar um rebalanceamento não intencional. Isso interrompe o consumo e aumenta o acúmulo. Portanto, defina esses valores com uma duração que acomode o tempo real de processamento de mensagens.No console do ApsaraMQ for Kafka, acesse a página Consumer Status para verificar se a contagem de acúmulo e as alterações de offset correspondem às expectativas. Considere o dimensionamento vertical apenas se você confirmar que o timeout resulta de um gargalo de recursos no lado do servidor.