Séquencement et horodatage des messages

  • Article

Le séquencement et l’horodatage sont deux fonctionnalités qui sont toujours activées sur toutes les entités Service Bus et qui sont exposées via les propriétés Sequence​Number et EnqueuedTimeUtc des messages reçus ou parcourus.

Dans les scénarios où le respect de l’ordre absolu des messages est important et/ou dans lesquels un consommateur a besoin de suivre les messages avec un identificateur unique fiable, le répartiteur horodate les messages avec des numéros de séquence incrémentiels continus en lien avec la file d’attente ou la rubrique. Pour les entités partitionnées, le numéro de séquence est déterminé par rapport à la partition.

Numéro de séquence

La valeur SequenceNumber est un entier unique 64 bits assigné à un message accepté et stocké par le broker, car il fonctionne comme son identificateur interne. Pour les entités partitionnées, les 16 premiers bits correspondent à l’identificateur de la partition. Les numéros de séquence retournent à zéro lorsque la plage 64 bits ou 48 bits (à l’exception de la plage 16 bits pour l’identificateur de partition) est dépassée.

Le numéro de séquence peut être considéré comme un identificateur unique fiable, car il est attribué par une autorité centrale et neutre, et non par les clients. Ils représentent également l’ordre d’arrivée réel. Ils sont plus précis qu’un horodatage comme critère de classification, car il est possible que les horodatages n’offrent pas une résolution suffisamment élevée à des débits de messages extrêmes et puissent subir des variations temporelles (toutefois minimes) dans les situations où la propriété du broker change entre les nœuds.

L’ordre d’arrivée absolu est important, notamment, dans des scénarios d’entreprise où un nombre limité de produits vendus sont fournis selon le principe du « premier arrivé, premier servi » jusqu’à épuisement des stocks. La vente de tickets de concert en est un bon exemple.

Timestamp

La fonctionnalité d’horodatage agit comme une autorité neutre et fiable qui capture l’heure UTC exacte de l’arrivée d’un message, reflétée dans la propriété EnqueuedTimeUtc. Cette valeur est utile dans les scénarios d’entreprise dépendant des délais, par exemple, si un élément de travail a été envoyé à une date donnée avant minuit, mais que le traitement est loin dans le backlog de la liste d’attente.

Notes

Le numéro de séquence garantit lui-même l’ordre de mise en file d’attente et l’ordre d’extraction des messages, mais pas l’ordre de traitement, qui nécessite des sessions.

Par exemple, il y a 5 messages dans la file d’attente et 2 consommateurs. Le consommateur 1 récupère le message 1. Le consommateur 2 récupère le message 2. Le consommateur 2 termine le traitement du message 2 et récupère le message 3, tandis que le consommateur 1 n’a pas encore terminé le traitement du message 1. Le consommateur 2 termine le traitement du message 3, mais le consommateur 1 n’a pas encore terminé le traitement du message 1. Enfin, le consommateur 1 termine le traitement du message 1. Ainsi, les messages sont traités dans cet ordre : message 2, message 3 et message 1. Si vous avez besoin que les messages 1, 2 et 3 soient traités dans l’ordre, vous devez utiliser des sessions.

Ainsi, si les messages doivent simplement être récupérés dans l’ordre, vous n’avez pas besoin d’utiliser des sessions. Si les messages doivent être traités dans l’ordre, utilisez des sessions. Le même ID de session doit être défini sur les messages qui sont associés, qui peuvent être les messages 1, 4 et 8 dans un ensemble, et 2, 3 et 6 dans un autre ensemble.

Pour plus d’informations, consultez Sessions de messagerie Service Bus.

Messages planifiés

Vous pouvez envoyer des messages dans une file d’attente ou une rubrique pour les traiter en différé, par exemple, si vous avez besoin de planifier un travail de sorte qu’il soit disponible pour être traité par un système à un moment précis. Cette fonctionnalité permet d’implémenter un planificateur temporel distribué fiable.

Les messages planifiés n’apparaissent réellement dans la file d’attente qu’à l’heure définie de la mise en file d’attente. Avant ce moment, les messages planifiés peuvent être annulés. L’annulation supprime le message.

Vous pouvez planifier des messages en utilisant un de nos clients de deux manières :

  • Utilisez l’API d’envoi standard, mais définissez la propriété Scheduled​Enqueue​Time​Utc sur le message avant l’envoi.
  • Utilisez l’API de message de planification, passez le message normal et l’heure planifiée. L’API retourne le SequenceNumber du message planifié que vous pouvez utiliser ultérieurement pour annuler le message planifié, le cas échéant.

Les messages planifiés et leurs numéros de séquence peuvent également être découverts avec la fonctionnalité de parcours des messages.

La valeur SequenceNumber d’un message planifié est valide uniquement si le message est dans l’état planifié. Quand le message passe à l’état actif, il est ajouté à la file d’attente comme s’il venait d’être mis en file d’attente, ce qui implique l’affectation d’une nouvelle valeur SequenceNumber.

Étant donné que la fonctionnalité s’applique à des messages individuels et que les messages ne peuvent être mis en file d’attente qu’une seule fois, Service Bus ne prend pas en charge les planifications récurrentes des messages.

Remarque

  • L’heure de mise en file d’attente du message ne signifie pas que le message sera envoyé en même temps. Il est mis en file d’attente, mais le temps d’envoi réel dépend de la charge de travail de la file d’attente et de son état.
  • Pour des raisons de performances, l’activation et l’annulation des messages planifiés sont des opérations indépendantes sans verrouillage mutuel. Si un message est en cours d’activation et est annulé simultanément, le processus d’activation n’est pas inversé et le message est quand même activé. De plus, cela peut entraîner un nombre négatif de messages planifiés. Pour réduire cette condition de concurrence, nous vous recommandons d’éviter de planifier des opérations d’activation et d’annulation de manière rapprochée.

Utilisation de messages planifiés avec des workflows

Il est courant de voir des workflows métier de plus longue durée ayant un composant de temps explicite pour eux, tel que des délais d’inactivité de 5 minutes pour l’authentification à 2 facteurs, des délais d’inactivité d’une heure pour les utilisateurs confirmant leur adresse e-mail et des composants de temps d’une durée d’un mois, d’une semaine ou de plusieurs jours dans des domaines tels que les banques et les assurances.

Ces workflows sont souvent lancés par le traitement d’un message, qui stocke ensuite un état, puis planifie un message pour continuer le processus plus tard. Les infrastructures telles que NServiceBus et MassTransit facilitent l’intégration de tous ces éléments ensemble.

Contenu connexe

Pour plus d’informations sur la messagerie Service Bus, consultez les articles suivants :