Lorsqu'un consommateur échoue à traiter un message après le nombre maximal de tentatives, ApsaraMQ for RocketMQ déplace le message vers une file de messages non livrables (dead-letter queue). Ces messages indiquent généralement un bogue au niveau du consommateur, une défaillance d'une dépendance en aval ou un format de message incompatible. Une fois la cause racine corrigée, renvoyez les messages depuis la console pour qu'ils soient retraités. Si vous ne pouvez pas résoudre le problème immédiatement, exportez les messages pour éviter toute perte de données avant l'expiration de la période de conservation de 3 jours. Pour plus d'informations sur le comportement des nouvelles tentatives, consultez la rubrique Nouvelles tentatives de message.
Caractéristiques principales
| Caractéristique | Détails |
|---|---|
| Portée | Chaque file de messages non livrables appartient à un groupe de consommateurs, et non à une instance de consommateur individuelle. Tous les messages non livrables issus du même groupe aboutissent dans la même file, quel que soit le topic d'origine. |
| Création | Créée à la demande. Aucune file de messages non livrables n'existe pour un groupe tant que ce dernier n'a pas généré de message non livrable. |
| Conservation | Les messages non livrables expirent au bout de 3 jours (la même période de conservation que pour les messages normaux). Les messages expirés sont automatiquement supprimés. |
| Distribution normale | Les messages non livrables ne peuvent pas être consommés via le processus de distribution normal. Renvoyez-les depuis la console après avoir résolu le problème. |
Diagnostiquer les messages non livrables
Lorsque des messages apparaissent dans une file de messages non livrables, identifiez la cause racine avant de les renvoyer :
Vérifiez les journaux du consommateur afin de détecter d'éventuelles exceptions ou erreurs survenues lors du traitement des messages.
Examinez le contenu du message : interrogez le message par son ID et passez en revue son corps ainsi que ses propriétés pour identifier des données malformées ou inattendues.
Vérifiez les dépendances en aval : assurez-vous que les bases de données, les API ou les autres services dont dépend le consommateur étaient disponibles au moment de l'échec.
Passez en revue les paramètres de délai d'attente du consommateur : vérifiez que le consommateur dispose d'un temps suffisant pour traiter les messages avant qu'ils n'atteignent le délai d'attente et ne déclenchent une nouvelle tentative.
Interroger les messages non livrables
ApsaraMQ for RocketMQ propose deux méthodes d'interrogation dans la console :
| Méthode | Entrée | Type de correspondance | Meilleur usage |
|---|---|---|---|
| Par ID de groupe | ID de groupe + plage horaire | Correspondance par plage | Parcourir tous les messages non livrables sur une fenêtre de temps donnée |
| Par ID de message | ID de groupe + ID de message | Correspondance exacte | Localiser un message spécifique |
Étapes
Connectez-vous à la console ApsaraMQ for RocketMQ. Dans le volet de navigation de gauche, cliquez sur Instances.
Dans la barre de navigation supérieure, sélectionnez une région, telle que China (Hangzhou). Sur la page Instances, cliquez sur le nom de l'instance que vous souhaitez gérer.
Dans le volet de navigation de gauche, cliquez sur Dead-letter Queues.
-
Sur la page Dead-letter Queues, sélectionnez une méthode d'interrogation :
-
Query by Group ID : spécifiez un ID de groupe et une plage horaire pour récupérer tous les messages non livrables correspondants.
RemarqueL'heure de génération d'un message non livrable correspond au moment où le message a été intégré à la file de messages non livrables après épuisement de toutes les tentatives, et non au moment de son envoi initial.
Query by Message ID : spécifiez un ID de groupe et un ID de message pour localiser un message précis.
-
Renvoyer les messages non livrables
Après avoir identifié et corrigé la cause racine, renvoyez les messages non livrables depuis la console pour retenter leur consommation.
Les messages ordonnés ne peuvent pas être renvoyés depuis une file de messages non livrables. Exportez-les et traitez-les manuellement.
Les messages renvoyés restent stockés dans la file de messages non livrables et sont automatiquement supprimés à l'expiration de la période de conservation.
Renvoyer un seul message
Interrogez le message non livrable en utilisant l'une des méthodes décrites ci-dessus.
Dans la liste des messages, repérez le message cible et cliquez sur More dans la colonne Actions.
Sélectionnez Resend.
Renvoyer plusieurs messages
Interrogez les messages non livrables par ID de groupe.
Sélectionnez les messages à renvoyer.
Cliquez sur Batch Resend Messages.
Exporter les messages non livrables
Exportez les messages pour les préserver avant l'expiration de la période de conservation de 3 jours. Les fichiers exportés sont au format CSV.
Exporter un seul message
Interrogez le message non livrable en utilisant l'une des méthodes décrites ci-dessus.
Dans la liste des messages, repérez le message cible et cliquez sur More dans la colonne Actions.
Sélectionnez Export Message.
Exporter plusieurs messages
Interrogez les messages non livrables par ID de groupe.
Sélectionnez les messages à exporter.
Cliquez sur Batch Export Messages.
Champs exportés
| Champ | Description |
|---|---|
| instanceId | ID de l'instance |
| topic | Topic auquel appartient le message |
| msgId | ID du message |
| bornHost | URL du producteur ayant produit le message |
| bornTimestamp | Horodatage de production du message |
| storeTimestamp | Horodatage de stockage du message par le broker |
| reconsumeTimes | Nombre de tentatives de consommation échouées |
| properties | Attributs du message au format JSON |
| body | Corps du message, encodé en Base64 |
| bodyCRC | Valeur CRC (Cyclic Redundancy Check) du corps du message |
Étapes suivantes
Nouvelles tentatives de message : découvrez comment les intervalles de nouvelle tentative et le nombre maximal de tentatives déterminent le moment où un message devient un message non livrable.