Simple Message Queue (formerly MNS):Durée de traitement des messages adaptative

Concepts de base

• Visible : le message est disponible dans la file d'attente. Tout consommateur peut le recevoir et le traiter. Un consommateur désigne un service ou une application qui reçoit et traite les messages.

• Invisible : après qu'un message a été reçu par un seul consommateur, il devient invisible et ne peut pas être reçu par d'autres consommateurs. Cela empêche les autres consommateurs de traiter le même message.

• Période de délai de visibilité : période s'étendant du moment où un message est reçu par un consommateur (invisible pour les autres consommateurs) au moment où il peut à nouveau être reçu par d'autres consommateurs (visible pour les autres consommateurs).

Lorsqu'un message est reçu par un seul consommateur, il devient invisible et ne peut pas être reçu par d'autres consommateurs. Ce statut invisible dépend de la période de délai de visibilité, qui empêche les autres consommateurs de traiter le même message.

Pour plus d'informations sur la période de délai de visibilité, consultez la section Délai de visibilité.

Scénarios

Simple Message Queue (anciennement MNS) spécifie une période de délai de visibilité par défaut pour chaque message. Le compte à rebours commence dès qu'un consommateur reçoit un message. Si le consommateur ne parvient pas à traiter le message dans le délai de visibilité imparti, un autre consommateur risque de le recevoir et de le traiter. Ce délai d'expiration est avantageux car les messages doivent être explicitement supprimés après leur traitement. En cas d'événement anormal, tel qu'un arrêt brutal du processus consommateur, le message peut toujours être traité par un autre consommateur.

Certains utilisateurs définissent une longue période de délai de visibilité par défaut pour une file d'attente afin de garantir qu'un message n'est pas libéré avant que le consommateur n'ait terminé son traitement. Par exemple, la période de délai de visibilité d'une file d'attente est fixée à 6 heures. Un consommateur reçoit et traite le message M1. Si le processus plante ensuite ou si la machine redémarre, le message M1 ne pourra pas être reçu et traité par un autre consommateur pendant au moins 6 heures. L'écriture de code personnalisé pour gérer ces pannes ajoute de la complexité au programme.

Dans les scénarios nécessitant une haute performance en temps réel et des réponses rapides pour chaque message, la consommation de messages doit répondre aux objectifs suivants :

• La période de délai de visibilité de la file d'attente est courte. Si un processus plante, un autre consommateur peut recevoir et traiter le message non traité après l'expiration de ce court délai de visibilité.

• Les messages ne doivent pas expirer pendant le traitement. Par exemple, si un consommateur met plus de 5 minutes pour traiter un message, celui-ci ne doit pas expirer durant cette opération.

Solution

Le SDK C# fourni par Simple Message Queue (anciennement MNS) permet de gérer ce scénario. La solution consiste à vérifier périodiquement si une opération ChangeVisibility est nécessaire pour le message pendant que le consommateur le traite. Une fois le traitement terminé, le consommateur doit toujours supprimer activement le message.

Pour obtenir le lien de téléchargement du SDK C#, consultez la section SDK C++. Si vous rencontrez des problèmes avec la démo, vous pouvez soumettre un ticket.

Les points suivants s'appliquent au programme :

• Avant d'exécuter le programme, vous devez spécifier les paramètres accessId, accessKey et EndPoint.

• Descriptions des variables :

  Variable	Description
  MessageMinimalLife	Durée de vie minimale qu'un message doit avoir lors de son enregistrement. Par exemple, s'il ne reste que 0,1 seconde avant l'expiration du délai d'un message lors de son enregistrement, il n'y a pas assez de temps pour prolonger sa durée de vie avec ChangeVisibility. Par conséquent, MessageMinimalLife garantit que le message survit suffisamment longtemps pour que ChangeVisibility puisse être appelé. Définissez cette valeur selon les besoins de votre charge de travail.
  TimerInterval	Intervalle du minuteur interne dans le Manager. Assurez-vous que le minuteur démarre avant que la durée de vie restante du message n'atteigne MessageMinimalLife. Un intervalle court peut être défini, mais cela entraîne des vérifications plus fréquentes.
  QueueMessageVisibilityTimeout	Période de délai de visibilité par défaut pour un message. Il s'agit d'une propriété de la file d'attente. Chaque fois que ChangeVisibility est appelé, la période de délai de visibilité du message est réinitialisée à QueueMessageVisibilityTimeout. Par conséquent, sa valeur doit être supérieure à TimerInterval + MessageMinimalLife pour garantir que le message n'expire pas.
  MessageTimeout	Délai d'expiration pour un message au sein du Manager. Par exemple, si un consommateur se bloque et qu'un message n'est pas traité après 5 heures (en supposant que 5 heures est beaucoup plus long que le temps de traitement normal), le Manager arrête d'appeler ChangeVisibility pour le message. Il laisse le délai de visibilité du message expirer.

• Description du flux :

  • Après qu'un consommateur a reçu un message, il enregistre d'abord le message, puis le traite, et enfin appelle la méthode deleteMessage du Manager.

  • Lorsqu'un message est enregistré pour la première fois, le Manager utilise le ThreadPool pour planifier une ChangeVisibilityTask afin de vérifier si une opération ChangeVisibility est nécessaire. Le Manager ajoute également le message à sa liste interne de messages.

  • Le minuteur interne du Manager utilise périodiquement Parallel pour démarrer une ChangeVisibilityTask qui vérifie tous les messages de la liste.

  • Les opérations spécifiques liées à Manager.ChangeMessageVisibility (ChangeVisibilityTask) sont illustrées dans l'organigramme.

    L'organigramme est le suivant :