Comment résoudre les échecs de connexion lors de la première connexion d’un client au serveur ?
Que faire si un consommateur ne parvient pas à consommer les messages ?
Le tag du message peut-il être vide lors de l’abonnement aux messages ?
Comment consulter les détails des nouvelles tentatives de consommation de messages ordonnés ?
Comment résoudre les échecs de connexion lors de la première connexion d’un client au serveur ?
Vérifiez que les configurations suivantes sont correctes :
Assurez-vous que l’endpoint est correctement spécifié. Vous pouvez obtenir l’endpoint sur la page Instance Details dans la console ApsaraMQ for RocketMQ.
-
Exécutez la commande telnet <nom de domaine dans l'endpoint> <numéro de port> pour vérifier la connectivité réseau.
Si votre application est déployée sur site ou si vous avez besoin d’un accès interrégional sans pouvoir utiliser Cloud Enterprise Network (CEN) pour construire le réseau, utilisez un endpoint public pour accéder à l’instance ApsaraMQ for RocketMQ. L’utilisation d’un endpoint public entraîne des frais de trafic sortant. Pour plus d’informations, consultez Frais d’accès au réseau public pour les instances de série 4.x ou Frais d’accès au réseau public pour les instances de série 5.x.
Si votre application est déployée sur une instance Alibaba Cloud Elastic Compute Service (ECS), utilisez un endpoint VPC pour accéder à l’instance ApsaraMQ for RocketMQ via un Virtual Private Cloud (VPC). Dans ce scénario, assurez-vous que l’instance ECS se trouve dans la même région que l’instance ApsaraMQ for RocketMQ.
Pour les instances de série 5,0 avec accès au réseau public activé, vérifiez si une liste d’autorisation est configurée. Par défaut, l’accès au réseau public autorise les connexions depuis toutes les adresses IP. Si une liste d’autorisation est configurée, seules les adresses IP incluses dans cette liste peuvent accéder à ApsaraMQ for RocketMQ.
Vérifiez que le nom de la rubrique est correct. Assurez-vous qu’il ne contient pas d’espaces supplémentaires ni de caractères spéciaux et que la rubrique a bien été créée dans la console.
-
Vérifiez que le nom d’utilisateur et le mot de passe sont corrects.
Pour les instances de série 5,0, saisissez le nom d’utilisateur et le mot de passe de l’instance. Vous pouvez les obtenir depuis la page des détails de l’instance dans la console.
Pour les instances de série 4,0, saisissez l’AccessKey ID et l’AccessKey secret d’un compte Alibaba Cloud ou d’un utilisateur Resource Access Management (RAM). Assurez-vous que l’utilisateur dispose des permissions requises. Pour obtenir une paire de clés AccessKey, consultez Créer une AccessKey.
Que faire en cas d’incohérence des relations d’abonnement ?
Connectez-vous à la console, accédez à la page Groups et consultez les relations d’abonnement ainsi que les informations sur les consommateurs pour le groupe spécifié. Modifiez le code d’abonnement des consommateurs dont les relations d’abonnement sont incohérentes afin de garantir leur uniformité.
Pour des étapes de dépannage détaillées, consultez Comment résoudre les incohérences des relations d’abonnement dans ApsaraMQ for RocketMQ ?
Comment gérer l’accumulation de messages ?
L’accumulation de messages peut survenir pour les raisons suivantes :
La logique de traitement des messages du consommateur est anormale, ce qui empêche la consommation des messages.
L’application productrice de messages subit un pic de trafic. Le taux de production dépasse largement le taux de consommation, provoquant une accumulation des messages.
Les services en aval dont dépend le consommateur connaissent des temps de réponse accrus, ce qui bloque les threads de consommation.
Le nombre de threads de consommation est insuffisant. La faible concurrence de consommation fait que le taux de consommation prend du retard par rapport au taux de production.
Examinez les journaux du client ou les informations de pile pour déterminer la cause de l’anomalie. Pour plus d’informations, consultez Gérer l’accumulation de messages.
Que faire si un consommateur ne parvient pas à consommer les messages ?
Connectez-vous à la console ApsaraMQ for RocketMQ et accédez à la page Groups. Vérifiez que le consommateur est en ligne et que la connexion client est normale. Si le client n’est pas connecté, examinez les journaux du client pour identifier et corriger l’erreur.
Vérifiez que les relations d’abonnement sont cohérentes. En cas d’incohérence, localisez le client consommateur sur la base des détails de la relation d’abonnement et modifiez le code d’abonnement aux messages du client.
En cas de panne d’une machine dans un groupe de consommateurs, les messages sont-ils perdus pendant le redémarrage ?
Non. ApsaraMQ for RocketMQ utilise des abonnements persistants. Les messages ne sont pas perdus si un groupe de consommateurs devient hors ligne ou si une exception de consommation se produit. Lorsque le client consommateur revient en ligne, il reprend la consommation à partir du décalage (offset) où il s’était arrêté.
Le tag du message peut-il être vide lors de l’abonnement aux messages ?
Non. Si vous définissez un tag vide lors de l’abonnement aux messages, le consommateur ne recevra aucun message. Pour s’abonner à tous les messages d’une rubrique, définissez le tag sur *. L’exemple de code suivant illustre cette configuration :
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);Pour plus d’informations, consultez Filtrage basé sur les tags.
Comment définir le décalage (offset) initial du consommateur lors de la création d’un nouveau groupe de consommateurs pour s’abonner à une rubrique existante ?
Il n’est pas possible de définir le décalage (offset) initial du consommateur lors de la création d’un groupe de consommateurs. Par défaut, lorsqu’un consommateur démarre pour la première fois, il commence à consommer à partir du message le plus ancien de la rubrique, qu’il s’agisse d’une nouvelle rubrique ou d’une rubrique existante.
Après le premier démarrage du consommateur, vous pouvez réinitialiser le décalage (offset) du consommateur dans la ApsaraMQ for RocketMQ console. Pour plus d’informations, consultez Réinitialiser un décalage (offset) de consommateur.
Que faire si un consommateur en ligne ne consomme pas de messages, mais que le groupe présente une accumulation de messages ?
Vérifiez la méthode d’abonnement utilisée par le groupe de consommateurs pour la rubrique. Si le consommateur s’abonne à la rubrique via un filtrage de messages, les messages qui ne correspondent pas aux conditions de filtrage sont comptabilisés comme accumulés. Il s’agit d’un comportement attendu. Pour plus d’informations, consultez Filtrage des messages.
Si vous utilisez un filtrage SQL ou basé sur les tags et que le groupe présente une accumulation de messages alors qu’aucun message n’est consommé, le nombre de messages accumulés est calculé comme suit.
Filtrage SQL : Nombre de messages accumulés = Nombre de messages prêts + Nombre de messages en cours de traitement - Nombre de messages ne remplissant pas les conditions de filtrage
Filtrage basé sur les tags : Nombre de messages accumulés = (Nombre de messages prêts + Nombre de messages en cours de traitement) × Pourcentage de messages correspondant aux tags
Pourcentage de messages correspondant aux tags = Nombre de messages correspondant aux tags dans l’échantillon / Nombre total de messages échantillonnés
Que faire si le tableau de bord affiche une accumulation importante de messages, alors que les messages sont déjà consommés côté consommateur ?
Ce problème peut survenir si vous utilisez un kit de développement logiciel (SDK) basé sur le protocole Remoting et que vous configurez le mode de consommation sur « diffusion » (broadcasting) côté consommateur. Le côté serveur détermine l’accumulation de messages en fonction des informations de décalage (offset) du consommateur. Or, en mode de consommation par diffusion, les décalages des consommateurs sont maintenus côté client. Par conséquent, le tableau de bord peut afficher à tort une accumulation de messages.
De plus, si le consommateur utilise un filtrage basé sur les tags ou SQL, les messages qui ne correspondent pas aux conditions de filtrage sont considérés comme accumulés.
Comment consulter les détails des nouvelles tentatives de consommation de messages ordonnés ?
Les nouvelles tentatives de consommation de messages ordonnés sont effectuées localement sur le client consommateur. Par conséquent, vous ne pouvez pas interroger les informations spécifiques de nouvelle tentative à partir de la trace des messages côté serveur.
Vous pouvez consulter les informations détaillées de nouvelle tentative dans les journaux du client. Les mots-clés de journal suivants peuvent être utilisés :
SDK RocketMQ Remoting :
consumeMessage exception: {} Group: {} Msgs: {} MQ: {}consumeMessage Orderly return not OK, Group: {} Msgs: {} MQ: {}
SDK RocketMQ gRPC :
Prepare to redeliver the fifo message because of the consumption failure, maxAttempt={}, attempt={}, mq={}, messageId={}, nextAttemptDelay={}, clientId={}