Como solucionar falhas de conexão na primeira tentativa de um cliente?
O que fazer quando há inconsistência nas relações de assinatura?
O que fazer se um consumidor não estiver consumindo mensagens?
Como definir o offset inicial do consumidor ao criar um novo grupo para assinar um tópico existente?
O que fazer se um consumidor online não consumir mensagens, mas o grupo apresentar acúmulo?
Como visualizar os detalhes de nova tentativa de consumo de mensagens ordenadas?
Como solucionar falhas de conexão na primeira tentativa de um cliente?
Verifique se as configurações abaixo estão corretas:
Confira se o endpoint está especificado corretamente. Obtenha o endpoint na página Instance Details no console do ApsaraMQ for RocketMQ.
-
Execute o comando telnet <Domain name in the endpoint> <Port number> para verificar a conectividade de rede.
Caso sua aplicação esteja implantada on-premises ou seja necessário acesso entre regiões sem usar a Cloud Enterprise Network (CEN), utilize um endpoint público para acessar a instância do ApsaraMQ for RocketMQ. O uso de endpoint público gera taxas de tráfego de saída. Para mais informações, consulte Taxas de acesso à rede pública para instâncias da série 4.x ou Taxas de acesso à rede pública para instâncias da série 5.x.
Se a aplicação estiver em uma instância do Elastic Compute Service (ECS) da Alibaba Cloud, use um endpoint de VPC para acessar a instância do ApsaraMQ for RocketMQ por meio de uma Virtual Private Cloud (VPC). Nesse cenário, garanta que a instância ECS esteja na mesma região da instância do ApsaraMQ for RocketMQ.
Para instâncias da série 5,0 com acesso à rede pública habilitado, confirme se há uma lista de permissões configurada. Por padrão, o acesso público permite conexões de todos os endereços IP. Se existir uma lista de permissões, apenas os IPs listados poderão acessar o ApsaraMQ for RocketMQ.
Valide se o nome do tópico está correto. Certifique-se de que não haja espaços extras ou caracteres especiais e que o tópico tenha sido criado no console.
-
Verifique se o nome de usuário e a senha estão corretos.
Nas instâncias da série 5,0, insira o nome de usuário e a senha da instância. Essas credenciais estão disponíveis na página de detalhes da instância no console.
Para instâncias da série 4,0, insira o AccessKey ID e o AccessKey secret de uma conta Alibaba Cloud ou de um usuário do Resource Access Management (RAM). Garanta que o usuário tenha as permissões necessárias. Para obter um par de AccessKey, consulte Criar um AccessKey.
O que fazer quando há inconsistência nas relações de assinatura?
Faça login no console, acesse a página Groups e visualize as relações de assinatura e as informações dos consumidores do grupo especificado. Modifique o código de assinatura dos consumidores com inconsistências para garantir a uniformidade.
Para etapas detalhadas de solução de problemas, consulte Como solucionar relações de assinatura inconsistentes no ApsaraMQ for RocketMQ?
Como lidar com o acúmulo de mensagens?
O acúmulo de mensagens pode ocorrer pelos seguintes motivos:
Lógica de processamento anormal no consumidor impede o consumo das mensagens.
Pico de tráfego na aplicação produtora faz a taxa de produção superar a de consumo, causando acúmulo.
Aumento no tempo de resposta dos serviços downstream dos quais o consumidor depende bloqueia as threads de consumo.
Quantidade insuficiente de threads de consumo reduz a concorrência e faz a taxa de consumo ficar atrás da taxa de produção.
Analise os logs do cliente ou as informações de pilha para identificar a causa da exceção. Para mais detalhes, consulte Como lidar com o acúmulo de mensagens.
O que fazer se um consumidor não estiver consumindo mensagens?
Faça login no console do ApsaraMQ for RocketMQ e acesse a página Groups. Verifique se o consumidor está online e se a conexão do cliente está normal. Caso o cliente não esteja conectado, analise os logs para identificar e corrigir o erro.
Valide a consistência das relações de assinatura. Se houver inconsistências, localize o cliente consumidor com base nos detalhes da relação de assinatura e modifique o código de assinatura de mensagens desse cliente.
Se uma máquina em um grupo de consumidores falhar, as mensagens são perdidas durante a reinicialização?
Não. O ApsaraMQ for RocketMQ utiliza assinaturas persistentes. As mensagens não são perdidas caso um grupo de consumidores fique offline ou ocorra uma exceção de consumo. Quando o cliente consumidor volta a ficar online, ele retoma o consumo a partir do offset onde parou.
A tag da mensagem pode ficar vazia ao assinar mensagens?
Não. Definir uma tag vazia na assinatura impede que o consumidor receba qualquer mensagem. Para assinar todas as mensagens de um tópico, defina a tag como *. O exemplo de código abaixo ilustra essa configuração:
String topic = "Your Topic";
// Use a tag to filter messages. This subscribes to all messages.
FilterExpression filterExpression = new FilterExpression("*", FilterExpressionType.TAG);
pushConsumer.subscribe(topic, filterExpression);Para mais informações, consulte Filtragem baseada em tags.
Como definir o offset inicial do consumidor ao criar um novo grupo para assinar um tópico existente?
Não é possível definir o offset inicial do consumidor durante a criação do grupo. Por padrão, quando um consumidor inicia pela primeira vez, ele começa a consumir a partir da mensagem mais antiga do tópico, independentemente de estar assinando um tópico novo ou existente.
Após a primeira inicialização do consumidor, redefina o offset no ApsaraMQ for RocketMQ pelo console. Para mais detalhes, consulte Redefinir um offset de consumidor.
O que fazer se um consumidor online não consumir mensagens, mas o grupo apresentar acúmulo?
Verifique o método de assinatura que o grupo de consumidores usa para o tópico. Se o consumidor assinar o tópico com filtragem de mensagens, aquelas que não correspondem às condições do filtro são contabilizadas como acumuladas. Esse comportamento é esperado. Para mais informações, consulte Filtragem de mensagens.
Ao utilizar filtragem SQL ou baseada em tags, caso o grupo apresente acúmulo mesmo sem consumo ativo, o cálculo das mensagens acumuladas segue a lógica abaixo.
Filtragem SQL: Número de mensagens acumuladas = Número de mensagens prontas + Número de mensagens em trânsito - Número de mensagens que não atendem às condições de filtragem
Filtragem baseada em tags: Número de mensagens acumuladas = (Número de mensagens prontas + Número de mensagens em trânsito) × Percentual de mensagens que correspondem às tags
Percentual de mensagens que correspondem às tags = Número de mensagens correspondentes na amostra / Total de mensagens amostradas
O que fazer se o painel mostrar um grande acúmulo de mensagens, mas elas já tiverem sido consumidas no lado do consumidor?
Esse problema pode ocorrer ao usar um SDK de protocolo Remoting com o modo de consumo definido como broadcasting. O servidor determina o acúmulo com base nas informações de offset do consumidor. No entanto, no modo broadcasting, os offsets são mantidos no cliente. Consequentemente, o painel pode exibir incorretamente um acúmulo de mensagens.
Além disso, se o consumidor utilizar filtragem baseada em tags ou SQL, as mensagens que não corresponderem às condições do filtro serão consideradas acumuladas.
Como visualizar os detalhes de nova tentativa de consumo de mensagens ordenadas?
As novas tentativas de consumo de mensagens ordenadas ocorrem localmente no cliente consumidor. Portanto, não é possível consultar as informações específicas de nova tentativa no rastreamento de mensagens do servidor.
Consulte os logs do cliente para obter detalhes sobre as novas tentativas. Utilize as seguintes palavras-chave nos logs:
RocketMQ Remoting SDK:
consumeMessage exception: {} Group: {} Msgs: {} MQ: {}consumeMessage Orderly return not OK, Group: {} Msgs: {} MQ: {}
RocketMQ gRPC SDK:
Prepare to redeliver the fifo message because of the consumption failure, maxAttempt={}, attempt={}, mq={}, messageId={}, nextAttemptDelay={}, clientId={}