O acúmulo de mensagens ocorre quando o offset confirmado de um grupo de consumidores fica atrasado em relação ao offset de produção mais recente do broker (high-water mark). A diferença entre esses dois offsets representa a quantidade de mensagens acumuladas. Um número crescente nem sempre indica um problema — o fator determinante é se o consumo acompanha o ritmo da produção. Utilize 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, compreenda o ciclo de consumo em duas fases que ocorre em cada cliente:
Pull: O cliente busca mensagens no broker.
Processamento: 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 isoladamente não sinaliza um problema. Concentre-se na tendência: a diferença está estável, crescendo ou foi causada por offsets não confirmados?
Diagnosticar o acúmulo
Para verificar se o acúmulo é normal, inspecione as métricas do grupo de consumidores no console do ApsaraMQ for Kafka:
Faça login no console do ApsaraMQ for Kafka.
Na barra de navegação superior, selecione a região onde sua instância está localizada.
No painel de navegação à esquerda, clique em Instances.
Na página Instances, clique no nome da instância desejada.
Na página Instance Details, clique em Groups no painel de navegação à esquerda.
Na página Groups, localize o grupo desejado 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.
Esses valores são atualizados em intervalos de 1 minuto. Clique em Details para visualizar o offset do consumidor de cada partição.
Utilize a tabela de decisão a seguir para interpretar as métricas:
|
Sintoma |
Diagnóstico |
Ação |
|
Last Consumed At está próximo da hora atual e Accumulated Messages flutua dentro de uma faixa estável |
Normal — o cliente está buscando e processando 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 confirmar offsets. |
Consulte Resolver acúmulo anormal. |
|
Accumulated Messages aumenta continuamente, mas Consumer Offset avança |
Anormal — o consumo está muito lento. O cliente processa mensagens, porém a taxa de processamento é inferior à taxa de produção. O gargalo encontra-se na fase de processamento (fase 2), não na fase de pull. |
Consulte Resolver acúmulo anormal. |
|
Mensagens parecem acumuladas nas partições, mas o processamento downstream está normal |
Provável falso positivo. Se o sistema downstream utiliza o modo de consumo |
Confirme os offsets manualmente para limpar o acúmulo reportado. |
|
Accumulated Messages aumenta e Consumer Offset avança lentamente, mas o monitoramento de 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 o throttling de throughput de consumo. O cliente não está totalmente bloqueado — ele ainda consegue buscar mensagens, mas com taxa restrita, causando acúmulo gradual. |
Verifique as métricas de monitoramento de largura de banda do consumidor no nível da instância. Se o throttling for confirmado, considere atualizar a especificação da instância ou reduzir o volume de pull do consumidor. |
|
Accumulated Messages cresce significativamente para um tópico, e o consumo desacelera em outros tópicos na mesma instância |
Possível impacto indireto de leituras frias (cold reads). Normalmente, o acúmulo em um único tópico não afeta diretamente outros tópicos na mesma instância. No entanto, se as mensagens acumuladas forem descarregadas no disco, a recuperação aciona E/S de disco em vez de leituras em memória (leitura fria). IOPS ou throughput de leitura de disco elevados podem degradar o desempenho geral da instância. |
Verifique as métricas de monitoramento de E/S de disco e throughput de rede no nível da instância. Se os IOPS de leitura de disco ou o tráfego estiverem anormalmente altos, priorize a redução do acúmulo no tópico afetado primeiro. |
Um valor alto em Accumulated Messages nem sempre significa que há 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 os offsets são confirmados uma vez por segundo, a contagem acumulada normalmente flutuará em torno de 10.000.
Resolver acúmulo anormal
Após confirmar um 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 estiver avançando, a thread do consumidor provavelmente está travada. Use
jstack(para aplicações Java) para capturar um dump de threads e identificar o ponto de bloqueio. Para obter mais informações, consulte jstack - Stack Trace.Processamento lento: Caso o Consumer Offset esteja avançando, mas ficando para trás em relação à produção, faça uma análise de perfil da lógica de processamento de mensagens na sua aplicação. Procure por chamadas de E/S lentas, gravações em banco de dados ou operações bloqueantes durante a fase de processamento.
Aumentar a taxa de consumo
Adote uma ou ambas as abordagens a seguir:
Adicionar consumidores: Inclua mais instâncias de consumidor no mesmo grupo de consumidores, seja como threads adicionais em um processo existente ou como processos separados. Cada consumidor lida com 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 surtirá efeito — os consumidores extras permanecerão ociosos.
Aumentar threads de consumo: Utilize consumo multithread dentro de cada instância de consumidor. Para detalhes de implementação, consulte a seção "Increase consumption rate" em Best practices for consumers.
Na maioria dos casos, o acúmulo anormal de mensagens é causado por consumo lento ou por uma thread de consumo bloqueada. Evite definir durações longas para 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 passando por um rebalanceamento. Durante esse processo, nenhuma mensagem é consumida.
Rebalanceamentos frequentes geralmente ocorrem devido a consumidores conectando-se e desconectando-se em alta velocidade. Para obter 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 pode resolver erros read tcp i/o timeout que causam acúmulo de mensagens?**
R: O dimensionamento vertical normalmente não resolve diretamente os erros read tcp i/o timeout. Esse erro está mais frequentemente relacionado a problemas de conectividade de rede ou configuração do cliente do que a restrições de recursos no lado do servidor. Antes de considerar um scale-up, siga estas etapas de solução de problemas:
Verifique se a conexão de rede entre o cliente e o broker está estável. Procure por perda de pacotes, alta latência ou problemas intermitentes de conectividade.
Confira a versão do cliente. Se for anterior à 0.10.2, atualize para uma versão suportada.
Ajuste os parâmetros
max.poll.interval.msesession.timeout.ms. Se esses valores forem muito curtos em relação ao tempo necessário para processar cada lote de poll, o cliente poderá atingir o tempo limite e acionar um Rebalance não intencional, interrompendo o consumo e aumentando o acúmulo. Defina esses valores com uma duração compatível com o tempo real de processamento das suas mensagens.No console do ApsaraMQ for Kafka, verifique a página Consumer Status para confirmar se a contagem de acúmulo e as alterações de offset correspondem ao esperado. Considere o dimensionamento vertical apenas se tiver confirmado que o tempo limite foi causado por um gargalo de recursos no lado do servidor.