Quando um consumidor encontra uma exceção, o ApsaraMQ for RocketMQ reenvia a mensagem com base na política de nova tentativa de consumo para recuperar falhas. Este tópico descreve os casos de uso, o mecanismo de funcionamento, a compatibilidade de versões e as recomendações de uso do recurso de nova tentativa de consumo.
Cenários
A nova tentativa de consumo do ApsaraMQ for RocketMQ resolve principalmente problemas de integridade no consumo de mensagens causados por falhas na lógica de processamento de negócios. Trata-se de uma estratégia de fallback para sua aplicação; não a utilize para controle de fluxo de negócios.
-
Utilize a nova tentativa de mensagem nos seguintes cenários:
O processamento de negócios falha e a falha está relacionada ao conteúdo da mensagem atual. Por exemplo, a resolução da transação para esta mensagem ainda não foi obtida, mas espera-se sucesso após um curto atraso.
A causa da falha de consumo não é sistêmica. Ou seja, a mensagem atual falha devido a um evento raro, e não por uma falha consistente, e as mensagens subsequentes têm alta probabilidade de sucesso. Nesse caso, tentar novamente a mensagem atual evita o bloqueio do processo.
-
Evite a nova tentativa de mensagem nos seguintes cenários:
Utilizar a falha de consumo como uma ramificação condicional na lógica de processamento é inadequado, pois a lógica já prevê ocorrências frequentes dessa ramificação.
Utilizar a falha de consumo para implementar limitação de taxa é inapropriado. A limitação de taxa visa enfileirar temporariamente o tráfego excedente para suavização de picos, e não rotear mensagens para o caminho de nova tentativa.
Objetivo
Ao utilizar middleware orientado a mensagens para desacoplamento assíncrono, um desafio a ser superado é garantir a integridade da cadeia de invocação caso o serviço downstream falhe ao processar mensagens. O ApsaraMQ for RocketMQ, como middleware de mensagens de negócios confiável de nível financeiro, foi projetado intrinsecamente para suportar uma estratégia de transmissão confiável em seu mecanismo de entrega de mensagens. Isso assegura que cada mensagem seja processada conforme esperado pelo negócio por meio de mecanismos completos de confirmação e nova tentativa.
Compreender o mecanismo de confirmação de mensagens e as políticas de nova tentativa de consumo do ApsaraMQ for RocketMQ ajuda você a analisar as seguintes questões:
Como garantir o processamento completo das mensagens: Conhecer a política de nova tentativa auxilia no design da lógica do consumidor para assegurar que cada mensagem seja totalmente processada, evitando mensagens ignoradas e estados de negócios inconsistentes.
Como recuperar o estado da mensagem durante falhas do sistema: Isso esclarece como os estados das mensagens em trânsito são restaurados durante anomalias do sistema (como interrupções) e se pode ocorrer inconsistência de estado.
Política de nova tentativa de consumo
A política de nova tentativa de consumo define o intervalo de nova tentativa e a contagem máxima de tentativas após um consumidor falhar ao processar uma mensagem.
Acionadores de nova tentativa
Falha de consumo, incluindo o retorno de um status de falha ou o lançamento de uma exceção inesperada.
Timeout no processamento da mensagem, incluindo timeout de fila no PushConsumer.
Principais comportamentos de nova tentativa
Máquina de estados de nova tentativa: Controla os estados e transições das mensagens durante a nova tentativa.
Intervalo de nova tentativa: O tempo entre uma falha de consumo (ou timeout) e o momento em que a mensagem fica disponível para reconsumo.
Contagem máxima de novas tentativas: O número máximo de vezes que uma mensagem pode ser tentada novamente.
Diferenças na política de nova tentativa de mensagens
Os mecanismos de nova tentativa e os métodos de configuração variam conforme o tipo de consumidor:
|
Tipo de consumidor |
Máquina de estados de nova tentativa |
Intervalo de nova tentativa |
Contagem máxima de novas tentativas |
|
PushConsumer |
|
Controlado por metadados na criação do grupo de consumidores.
|
Defina via console ou OpenAPI |
|
SimpleConsumer |
|
Defina a duração invisível ao buscar mensagens via API. |
Defina via console ou OpenAPI |
Para obter detalhes sobre as políticas de nova tentativa, consulte Política de nova tentativa de consumo do PushConsumer e Política de nova tentativa de consumo do SimpleConsumer.
Política de nova tentativa de consumo do PushConsumer
Máquina de estados de nova tentativa
Quando o PushConsumer processa mensagens, elas passam pelos seguintes estados:
-
Ready: Estado pronto.
A mensagem está pronta no servidor do ApsaraMQ for RocketMQ e pode ser consumida pelos consumidores.
-
Inflight: Estado de processamento.
Inflight: O cliente consumidor buscou a mensagem e a está processando, mas ainda não retornou um resultado de consumo.
-
WaitingRetry: Estado de nova tentativa pendente, exclusivo para consumidores push.
WaitingRetry: Um estado específico do PushConsumer acionado quando o processamento da mensagem falha ou atinge timeout. Se a contagem atual de novas tentativas não tiver atingido o máximo, a mensagem entra em WaitingRetry. Após o intervalo de nova tentativa, ela retorna ao estado Ready para reconsumo. Os intervalos aumentam progressivamente entre as tentativas para evitar novas tentativas de alta frequência em falhas persistentes.
-
Commit: Estado de confirmação.
Commit: Indica consumo bem-sucedido. A máquina de estados da mensagem termina quando o consumidor retorna uma resposta de sucesso.
-
DLQ: Fila de mensagens mortas.
DLQ: Estado de mensagem morta — o fallback final. Se as novas tentativas excederem a contagem máxima e a retenção de mensagens mortas estiver ativada, a mensagem com falha será enviada para um tópico de mensagens mortas. Você pode consumir mensagens desse tópico para restaurar as operações de negócios. Para mais detalhes, consulte Mensagens mortas.
-
Discard: Descarte.
Discard: Se as novas tentativas excederem a contagem máxima e a retenção de mensagens mortas estiver desativada, a mensagem será descartada.
Exemplo: No diagrama acima, suponha que uma mensagem permaneça em Ready por 5 segundos e leve 6 segundos para ser processada.
Cada ciclo de nova tentativa segue o fluxo Ready → Inflight → WaitingRetry. O intervalo de nova tentativa é o tempo entre uma falha (ou timeout) e o momento em que a mensagem volta ao estado Ready. O tempo real entre duas tentativas de consumo também inclui o tempo de processamento e a duração em Ready. Por exemplo:
Em 0 s, a mensagem entra em Ready.
Devido à velocidade de processamento do consumidor, o consumo começa em 5 s. Após 6 segundos (em 11 s), ocorre uma exceção e o cliente retorna falha.
A nova tentativa não pode começar imediatamente — é necessário aguardar o intervalo de nova tentativa.
Em 21 s, a mensagem volta ao estado Ready.
O cliente inicia o reconsumo 5 segundos depois.
Portanto, o intervalo real entre duas tentativas de consumo é: tempo de processamento + intervalo de nova tentativa + duração em Ready = 21 s.
Intervalos de nova tentativa
-
Mensagens não ordenadas: O intervalo de nova tentativa utiliza uma abordagem de tempo escalonado, conforme abaixo:
Tentativa de nova tentativa
Intervalo de nova tentativa
Tentativa de nova tentativa
Intervalo de nova tentativa
1
10 segundos
9
7 minutos
2
30 segundos
10
8 minutos
3
1 minuto
11
9 minutos
4
2 minutos
12
10 minutos
5
3 minutos
13
20 minutos
6
4 minutos
14
30 minutos
7
5 minutos
15
1 hora
8
6 minutos
16
2 horas
NotaSe as tentativas de nova tentativa excederem 16, todas as tentativas subsequentes usarão um intervalo de 2 horas.
Mensagens ordenadas: Utilizam um intervalo de nova tentativa fixo. Para valores específicos, consulte Limites de parâmetros.
Contagem máxima de novas tentativas
No PushConsumer, a contagem máxima de novas tentativas é controlada pelos metadados do grupo de consumidores. Para modificá-la, consulte Modifique contagem máxima de novas tentativas.
Por exemplo, se a contagem máxima de novas tentativas for 3, a mensagem será entregue até 4 vezes: uma vez originalmente e três vezes via nova tentativa.
Exemplo de uso
Para acionar uma nova tentativa no PushConsumer, basta retornar um código de status de falha de consumo. O SDK captura exceções inesperadas automaticamente.
SimpleConsumer simpleConsumer = null;
// Consumption example: Use PushConsumer to consume normal messages. Return an error on failure to trigger retry.
MessageListener messageListener = new MessageListener() {
@Override
public ConsumeResult consume(MessageView messageView) {
System.out.println(messageView);
// Return FAILURE to trigger automatic retry until the maximum retry count is reached.
return ConsumeResult.FAILURE;
}
};
Visualize logs de nova tentativa de consumo
Para mensagens ordenadas, o PushConsumer realiza novas tentativas no lado do cliente. O servidor não consegue acessar logs detalhados de nova tentativa. Se o rastreamento de mensagens mostrar falha na entrega de uma mensagem ordenada, verifique os logs do cliente consumidor para obter informações sobre a contagem máxima de novas tentativas e dados do cliente.
Para o caminho dos logs do cliente, consulte Configuração de log.
Pesquise estas palavras-chave nos logs do cliente para localizar rapidamente detalhes de falhas de consumo:
Message listener raised an exception while consuming messages
Failed to consume fifo message finally, run out of attempt timesPolítica de nova tentativa de consumo do SimpleConsumer
Máquina de estados de nova tentativa
Quando o SimpleConsumer processa mensagens, elas passam pelos seguintes estados:
-
Ready: Estado pronto.
A mensagem está pronta no servidor do ApsaraMQ for RocketMQ e pode ser consumida pelos consumidores.
-
Inflight: Estado de processamento.
Inflight: O cliente consumidor buscou a mensagem e a está processando, mas ainda não retornou um resultado de consumo.
-
Commit: Estado de confirmação.
Commit: Indica consumo bem-sucedido. A máquina de estados da mensagem termina quando o consumidor retorna uma resposta de sucesso.
-
DLQ: Fila de mensagens mortas.
DLQ: Estado de mensagem morta — o fallback final. Se as novas tentativas excederem a contagem máxima e a retenção de mensagens mortas estiver ativada, a mensagem com falha será enviada para um tópico de mensagens mortas. Você pode consumir mensagens desse tópico para restaurar as operações de negócios. Para mais detalhes, consulte Mensagens mortas.
-
Discard: Descarte.
Discard: Se as novas tentativas excederem a contagem máxima e a retenção de mensagens mortas estiver desativada, a mensagem será descartada.
Diferentemente do PushConsumer, o SimpleConsumer utiliza um intervalo de nova tentativa pré-alocado. Ao buscar uma mensagem, o consumidor define um parâmetro InvisibleDuration — o tempo máximo permitido para processamento. Em caso de falha, o próximo intervalo de nova tentativa reutiliza esse valor sem necessidade de configuração adicional.
Como o InvisibleDuration é pré-alocado, ele pode diferir significativamente do tempo real de processamento. É possível modificá-lo via API.
Por exemplo, se você definir inicialmente o tempo de processamento como 20 ms, mas o processamento real exceder esse valor, estenda o InvisibleDuration para evitar novas tentativas prematuras.
Para modificar o InvisibleDuration, as seguintes condições devem ser atendidas:
O processamento da mensagem não atingiu timeout.
O status de consumo não foi confirmado.
Conforme mostrado abaixo, o novo InvisibleDuration entra em vigor imediatamente, reiniciando o temporizador de invisibilidade a partir do momento da chamada da API.
Intervalo de nova tentativa
Intervalo de nova tentativa = InvisibleDuration − Tempo real de processamento
O SimpleConsumer controla os intervalos de nova tentativa por meio do InvisibleDuration. Por exemplo, se o InvisibleDuration for 30 ms e o processamento falhar após 10 ms, a próxima tentativa ocorrerá após 20 ms. Se o processamento não terminar dentro de 30 ms e nenhum resultado for retornado, a mensagem atingirá timeout e será tentada novamente imediatamente (intervalo de 0 ms).
Contagem máxima de novas tentativas
No SimpleConsumer, a contagem máxima de novas tentativas é controlada pelos metadados do grupo de consumidores no momento da criação. Para modificá-la, consulte Modifique contagem máxima de novas tentativas.
Por exemplo, se a contagem máxima de novas tentativas for 3, a mensagem será entregue até 4 vezes: uma vez originalmente e três vezes via nova tentativa.
Exemplo de uso
Para acionar uma nova tentativa no SimpleConsumer, basta aguardar.
// Consumption example: Use SimpleConsumer to consume normal messages. To trigger retry, remain silent and let the message time out. The server will automatically retry.
List<MessageView> messageViewList = null;
try {
messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
messageViewList.forEach(messageView -> {
System.out.println(messageView);
// On failure, ignore the message. It will become visible again and be retried.
});
} catch (ClientException e) {
// If pull fails due to throttling or other system issues, retry the receive request.
e.printStackTrace();
}Modifique contagem máxima de novas tentativas
Utilize os métodos a seguir para alterar a contagem máxima de novas tentativas para PushConsumer e SimpleConsumer.
Se seu cliente utilizar o protocolo Remoting, a contagem máxima real de novas tentativas seguirá a configuração do lado do cliente, e esta configuração não terá efeito. Se seu cliente utilizar gRPC, a configuração aqui se aplica.
As estratégias de nova tentativa (backoff exponencial ou intervalo fixo) aplicam-se apenas a clientes gRPC e não têm efeito em clientes Remoting.
gRPC SDK
Modifique via OpenAPI: Atualize grupo de consumidores
-
Modifique via console:
Para acessar a configuração:
Na página Instances, clique em nome da instância desejada.
No painel de navegação à esquerda, clique em Groups. Na página Groups, clique em Create Group.
Na caixa de diálogo Create Group, defina Group ID (1–60 caracteres), Delivery Order (Concurrent Delivery ou Ordered Delivery) e Description. Expanda Advanced Settings para configurar a política de nova tentativa como Exponential Backoff, defina Maximum Retry Count (padrão: 16) e alterne Retain Dead-letter Messages (padrão: desativado; se desativado, mensagens que excederem a contagem de novas tentativas serão descartadas).
Remoting SDK
Modifique via parâmetro do Remoting SDK: Defina a propriedade maxReconsumeTimes do consumidor.
Melhores práticas
Utilize novas tentativas com critério — Evite usá-las para limitação de taxa
Conforme mencionado em Cenários, a nova tentativa de mensagem é adequada para falhas raras de negócios, e não para falhas sistêmicas ou contínuas, como limitação de taxa.
-
Exemplo incorreto:
Se a taxa de consumo acionar limitação, retorne falha e aguarde a nova tentativa.
-
Exemplo correto:
Se a taxa de consumo acionar limitação, adie a busca de mensagens e consuma posteriormente.
Perguntas frequentes sobre nova tentativa de mensagens
Como definir o timeout de consumo de mensagens?
Protocolo gRPC
-
SimpleConsumer: O intervalo de timeout varia de 10 segundos a 12 horas.
Exemplo de código:
private long minInvisiableTimeMillsForRecv = Duration.ofSeconds(10).toMillis(); private long maxInvisiableTimeMills = Duration.ofHours(12).toMillis(); PushConsumer: O padrão é 230 minutos e não pode ser modificado.
Protocolo Remoting
consumer.setConsumeTimeout(15); // Unit: minutes. Range: 1–180 minutes