Si la consommation d'un message échoue, une nouvelle tentative est automatiquement déclenchée. Si l'échec persiste après le nombre maximal de tentatives, le message devient un message non livrable (dead-letter). ApsaraMQ for RocketMQ vous permet de stocker ces messages dans une rubrique spécifique pour une récupération ultérieure ou une analyse rétrospective. Cette rubrique décrit les cas d'utilisation, les stratégies de gestion des messages non livrables, les limites, les méthodes de configuration et les notes d'utilisation associées.
Cas d'utilisation
-
Gestion standard des messages non livrables
Après l'échec des nouvelles tentatives, stockez les messages non livrables dans une rubrique dédiée. Créez un groupe de consommateurs distinct pour traiter ces messages afin de gérer les erreurs ou d'analyser les causes des échecs.
-
Mauvaise utilisation courante des messages non livrables
L'acheminement des messages non livrables à travers plusieurs couches ou leur réinjection dans la rubrique d'origine peut les faire entrer à nouveau dans la boucle de nouvelles tentatives, provoquant ainsi un effet d'avalanche.
Stratégie de gestion des messages non livrables
Quand un message devient non livrable
Un message qui n'est pas consommé avec succès après avoir atteint le nombre maximal de tentatives cesse d'être distribué et devient un message non livrable.
Règles de conservation des messages non livrables
ApsaraMQ for RocketMQ Par défaut, les messages non livrables ne sont pas conservés et sont supprimés une fois qu'ils passent dans cet état.
Activez la conservation des messages non livrables dans la console. Une fois activée, ces messages sont stockés dans une rubrique spécifique appelée rubrique de messages non livrables. Pour plus de détails, consultez Configurer les règles de conservation des messages non livrables.
Les messages non livrables sont stockés dans la rubrique dédiée comme de nouveaux messages. Leurs propriétés évoluent comme suit :
ID du message : Un nouvel ID est généré lors du stockage du message dans la rubrique de messages non livrables.
Les attributs définis par l'utilisateur, le corps du message et les autres informations fournies restent inchangés.
La période de conservation commence au moment où le message entre dans la rubrique de messages non livrables. Par exemple, si un message est envoyé au serveur à 13:00:00 et que sa consommation échoue deux heures plus tard (à 15:00:00) après les tentatives, sa période de conservation débute à 15:00:00.
Limites
La rubrique de messages non livrables doit être une rubrique de messages normaux ou une rubrique de messages ordonnés. Les rubriques de messages transactionnels et les rubriques de messages planifiés ne peuvent pas servir de rubriques de messages non livrables.
N'utilisez pas la rubrique du message d'origine comme rubrique de messages non livrables (pour éviter les boucles de nouvelles tentatives et les effets d'avalanche). Si le système détecte que la rubrique de destination correspond à la rubrique d'origine lors du transfert, le message est supprimé.
Les messages non livrables provenant de différentes rubriques peuvent être stockés dans la même rubrique de messages non livrables.
La suppression d'un groupe de consommateurs n'entraîne pas la suppression de la rubrique de messages non livrables associée.
Si une rubrique est référencée par une stratégie de messages non livrables, supprimez cette stratégie avant de pouvoir supprimer la rubrique.
Configurer les règles de conservation des messages non livrables
Configurez la conservation des messages non livrables dans la console ApsaraMQ for RocketMQ.
Pour accéder à ce paramètre :
Sur la page Instances, cliquez sur le nom de l'instance cible.
Dans le volet de navigation de gauche, cliquez sur Groups. Sur la page Groups, cliquez sur Create Group.
Dans la boîte de dialogue Create Group, développez la section Advanced Settings pour configurer la Consumption Retry Policy (par défaut : backoff exponentiel), le Maximum Retry Count (par défaut : 16) et l'option Retain Dead-letter Messages. Lorsque cette option est désactivée, les messages dépassant la limite de tentatives sont supprimés.
Métriques d'observabilité pour les messages non livrables
Descriptions des métriques
|
Type de métrique |
Métrique |
|
rocketmq_send_to_dlq_messages : Nombre de messages passant en statut non livrable par minute |
|
|
Utilisation des métriques
ApsaraMQ for RocketMQ prend en charge la configuration d'alertes pour les messages non livrables. Cela vous aide à détecter les anomalies avant qu'elles n'affectent vos activités métier et à identifier leur source en examinant les métriques du tableau de bord.
-
Scénario 1 : Afficher le nombre de messages passant en statut non livrable par minute
Dans le Dashboard, vérifiez la jauge Messages entering dead-letter status per minute. Vous pouvez également utiliser Cloud Monitor pour configurer une alerte sur Messages entering dead-letter status per minute (GroupId & Topic).
-
Scénario 2 : Vérifier le nombre de messages non livrables non traités
Une fois les messages non livrables stockés dans une rubrique dédiée, affichez la métrique Consumption backlog pour cette rubrique dans le Dashboard. Vous pouvez aussi utiliser Cloud Monitor pour créer une alerte sur Message backlog (GroupId & Topic).
Bonnes pratiques
Comment les consommateurs peuvent récupérer les informations de la rubrique d'origine
-
Option 1 : Mappez chaque rubrique de messages non livrables à sa rubrique d'origine selon une correspondance un-à-un.
Par exemple, si la rubrique d'origine est testTopic, nommez la rubrique de messages non livrables DLQ-testTopic.
-
Option 2 : Intégrez le nom de la rubrique d'origine dans un attribut personnalisé du message. Exemple :
messageBuilder.addProperty("originalTopic","testTopic")
Séparer le traitement des messages non livrables de la logique métier principale
Les messages non livrables sont ceux qui ont échoué même après les nouvelles tentatives dans les flux métier normaux. Traitez-les séparément pour éviter de perturber les opérations régulières.
La rubrique de messages non livrables doit être différente de la rubrique du message d'origine. Réutiliser la rubrique d'origine peut entraîner la réintégration des messages non livrables dans la boucle de consommation, bloquant ainsi les groupes de consommateurs normaux et déclenchant un effet d'avalanche.
N'utilisez pas les groupes de consommateurs de votre flux de production principal pour consommer les messages non livrables. Cela pourrait interférer avec le traitement normal des messages.