Dans les systèmes distribués, la contention des ressources empêche le traitement immédiat de tous les messages. Les messages prioritaires permettent aux producteurs d'attribuer une priorité numérique à chaque message afin qu'ApsaraMQ for RocketMQ livre en premier les messages les plus urgents lorsque les consommateurs accusent un retard.
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
Version d'instance 5.0-rmq-20260304-1 ou ultérieure.
-
SDK client gRPC :
Java SDK 5.2.0 ou ultérieur.
Autres SDK linguistiques : à venir.
Cas d'utilisation
Lorsque des messages de différents niveaux d'urgence partagent le même consommateur, les messages prioritaires vous permettent de signaler les plus critiques afin que le système les traite en priorité en cas de congestion.
Le tri par priorité ne prend effet qu'en cas d'accumulation de messages, c'est-à-dire lorsque les consommateurs ne parviennent pas à suivre le rythme des producteurs. Si le système n'est pas congestionné, tous les messages sont livrés immédiatement, quelle que soit leur priorité. Si votre charge de travail génère rarement un arriéré, envisagez plutôt d'utiliser des topics distincts pour chaque classe de priorité.
Ordonnancement des ressources de calcul IA
Les ressources GPU (Graphics Processing Unit) et NPU (Neural Processing Unit) sont rares et leur ordonnancement est coûteux. Utilisez les messages prioritaires pour contrôler quelles tâches obtiennent les ressources en premier lors des pics de demande :
Par type de tâche : Attribuez une priorité plus élevée aux requêtes d'inférence en production (temps réel orienté utilisateur) qu'à l'entraînement hors ligne ou aux exécutions de modèles expérimentaux.
Par taille de lot : Les petits travaux de validation rapide peuvent bénéficier d'une priorité élevée pour libérer rapidement les ressources ; les exécutions de préentraînement à grande échelle peuvent voir leur priorité réduite.
Par échéance : Les tâches soumises à des contraintes temporelles strictes, telles que les mises à jour en temps réel pour les modèles de conduite autonome, reçoivent la priorité la plus élevée.
Limitation du débit des API
Lorsque les messages provenant de plusieurs lignes métier (traitement des commandes, synchronisation des statuts, journalisation) partagent le même consommateur sous une limitation de débit tierce au niveau du compte, les messages prioritaires garantissent que les messages liés aux commandes sont traités avant les opérations moins critiques. Cela évite les retards de paiement ou d'activation lorsque la limite de débit est atteinte.
Notifications push marketing
Sur les plateformes sociales ou dans les systèmes de gestion de magasin envoyant des messages à un large public, attribuez une priorité plus élevée aux messages sensibles au temps (comme les échanges de service client en temps réel) et une priorité inférieure aux notifications marketing et en masse.
Fonctionnement
Les producteurs attribuent une priorité numérique à chaque message avant l'envoi. En cas d'accumulation de messages, ApsaraMQ for RocketMQ livre les messages aux consommateurs par ordre de priorité décroissante, selon une approche au mieux.
Le producteur définit la priorité du message à l'aide des propriétés du message, par exemple :
message.setPriority(int level).Le broker écrit chaque message dans une file d'attente spécifique à la priorité au sein du topic. Chaque niveau de priorité correspond à une file d'attente dédiée.
Lorsqu'un consommateur récupère des messages, il puise d'abord dans la file d'attente de priorité la plus élevée.
Le tri par priorité est strict au sein d'un seul nœud broker : les messages à haute priorité y sont toujours consommés en premier. L'ordre global sur plusieurs brokers n'est pas garanti. Dans les déploiements distribués, les brokers sont consommés en parallèle, de sorte que l'effet global constitue une priorisation au mieux.
Limites
Plage de priorité : Entier compris entre 0 et 9, les valeurs les plus élevées indiquant une priorité supérieure.
Plafond au niveau du topic : Chaque topic possède une priorité maximale configurable (par défaut : 9). Pour modifier ce plafond, soumettez un ticket d'assistance ou contactez votre administrateur.
Si les messages à haute priorité arrivent plus vite qu'ils ne sont consommés, les messages à faible priorité peuvent être retardés indéfiniment. ApsaraMQ for RocketMQ atténue ce problème en parcourant les sous-files d'attente lors de chaque cycle de livraison, afin que les messages à faible priorité finissent par être traités. Toutefois, en cas de charge lourde soutenue de la part des producteurs à haute priorité, attendez-vous à des retards significatifs pour le trafic à faible priorité.
Bonnes pratiques
Réduisez maxCacheMessageCount pour PushConsumer
Le PushConsumer précharge les messages dans un cache local avant de les transmettre à l'écouteur de messages. Les messages présents dans ce cache local ne sont pas triés par priorité ; ils sont conservés dans l'ordre où ils ont été récupérés depuis le broker. Si le cache est volumineux, les messages à haute priorité peuvent se trouver derrière des messages à faible priorité déjà présents dans le cache, contournant ainsi le tri par priorité effectué par le broker.
Maintenez une valeur faible pour maxCacheMessageCount afin que les messages non traités restent sur le broker, où le tri par priorité est appliqué, plutôt que de s'accumuler dans le cache local non trié.
Utilisez la livraison concurrente pour les groupes de consommateurs prioritaires
La livraison basée sur la priorité rompt l'ordre d'envoi, ce qui entre en conflit avec la livraison de messages ordonnés. Définissez le paramètre deliveryOrderType du ConsumerGroup sur Concurrently lors de la consommation de messages prioritaires.