ApsaraMQ for RocketMQ:Acúmulo e latência de mensagens

Fase 1: Buscar mensagens do broker

O cliente usa long polling para buscar mensagens em lotes e as armazena em cache em uma fila de buffer local. Essa fase é rápida: mesmo um servidor com especificações modestas (4 vCPUs, 8 GB de memória), com uma única thread e uma única partição, atinge dezenas de milhares de transações por segundo (TPS). Com múltiplas partições, o throughput escala para centenas de milhares de TPS. Gargalos de acúmulo não ocorrem nesta fase.

Fase 2: Processar mensagens na thread de consumo

O cliente envia as mensagens em cache à thread de consumo, que executa a lógica de negócios. A velocidade de processamento depende de dois fatores:

• Duração do consumo: tempo necessário para processar uma única mensagem.

• Concorrência de consumo: quantidade de mensagens processadas em paralelo.

Quando a fila de buffer local enche, o cliente para de buscar novas mensagens no broker. O gargalo reside sempre na Fase 2, determinado pela duração e pela concorrência do consumo. Entre os dois fatores, a duração do consumo tem o maior impacto.

Duração do consumo

A computação interna da CPU geralmente é insignificante comparada às operações de I/O externas. As operações mais comuns limitadas por I/O na lógica de consumo incluem:

• Leituras e gravações em banco de dados (por exemplo, MySQL)

• Leituras e gravações em cache (por exemplo, Redis)

• Chamadas a serviços downstream (por exemplo, chamadas RPC Dubbo, chamadas de API HTTP)

Execute profiling e benchmark de cada chamada externa para estabelecer uma linha de base de desempenho. O acúmulo geralmente começa quando uma dependência downstream fica lenta ou atinge um limite de capacidade.

Exemplo. Um consumidor grava cada mensagem em um banco de dados em 1 ms sob carga normal. Durante um pico de tráfego, o banco de dados atinge seu limite de capacidade e a latência de gravação aumenta para 100 ms por mensagem — uma queda de 100 vezes na taxa de consumo. Aumentar a contagem de threads do cliente não resolve. A solução é escalar o banco de dados.

Concorrência de consumo

A concorrência determina quantas mensagens o cliente processa em paralelo:

Prioridade de ajuste: Escale as threads em um único nó primeiro. Adicione mais nós somente após a utilização total dos recursos de hardware do nó.

Faça benchmark da duração do consumo

Meça a duração base do consumo por meio de testes de estresse e profiling de código. Concentre-se nos seguintes pontos:

1. Elimine problemas no nível de código. Verifique se há complexidade computacional excessiva, loops infinitos ou recursão profunda na lógica de consumo.

2. Minimize o I/O externo. Avalie se cada chamada externa (consulta ao banco de dados, busca em cache, API downstream) é estritamente necessária. Use cache local sempre que possível para eliminar chamadas redundantes.

3. Descarregue operações pesadas. Mova operações complexas e demoradas para processamento assíncrono. Garanta que o design assíncrono não crie condições de corrida — por exemplo, marcar o consumo como concluído antes que a operação assíncrona termine.

Defina a concorrência de consumo

1. Encontre a contagem ideal de threads. Aumente gradualmente as threads em um único nó enquanto monitora CPU, memória e throughput. Identifique o ponto de retornos decrescentes.

2. Calcule o número necessário de nós. Com base no throughput de nó único e no pico de tráfego upstream:

      Number of nodes = Peak traffic / Single-node throughput

Passo 1: Configure alertas

Configure alertas de acúmulo de mensagens pelo recurso de monitoramento e alerta no ApsaraMQ for RocketMQ. Para obter detalhes, consulte Configurar alertas de acúmulo de mensagens.

Passo 2: Diagnostique e resolva

Quando um alerta disparar, identifique se a causa raiz é a duração do consumo ou a concorrência:

Para um guia completo de correção, consulte Lidar com mensagens acumuladas.