Partager via

Sessions de message

Les sessions Azure Service Bus permettent un traitement conjoint et ordonné de séquences de messages connexes. Les sessions peuvent être utilisées dans des modèles premier entré, premier sorti (FIFO) et demande-réponse. Cet article explique comment utiliser des sessions pour implémenter ces modèles lors de l’utilisation de Service Bus.

Remarque

Le niveau de base de Service Bus ne prend pas en charge les sessions. Les niveaux Standard et Premium prennent en charge les sessions. Pour connaître les différences entre ces niveaux, voir Tarification de Service Bus.

Modèle premier entré, premier sorti (FIFO)

Pour obtenir le traitement FIFO dans le traitement des messages à partir de files d’attente ou d’abonnements Service Bus, utilisez des sessions. Service Bus n’est pas prescriptif quant à la nature de la relation entre les messages, et ne définit pas non plus un modèle particulier pour déterminer où une séquence de messages démarre ou se termine.

Un expéditeur peut lancer une session lors de l’envoi de messages dans une rubrique ou une file d’attente en définissant la propriété ID de session sur un identificateur unique défini par l’application. Au niveau du protocole AMQP 1.0 , cette valeur est mappée à la propriété group-id .

Dans les files d’attente ou abonnements prenant en compte la session, les sessions entrent en action quand au moins un message existe avec l’ID de session. Une fois qu’une session existe, il n’y a pas de temps ou d’API défini pour le moment où la session expire ou disparaît. Théoriquement, un message peut être reçu pour une session aujourd'hui, le message suivant dans un an, et si l'ID de session correspond, la session est considérée comme étant la même du point de vue du Service Bus.

En règle générale, toutefois, une application définit l’emplacement où un ensemble de messages connexes démarre et se termine. Service Bus n’impose aucune règle spécifique. Par exemple, votre application peut définir la propriété Label pour le premier message comme démarrage, pour les messages intermédiaires en tant que contenu et pour que le dernier message se termine. La position relative des messages de contenu peut être calculée comme étant égale à la différence entre la valeur SequenceNumber du message actuel et la valeur SequenceNumber du message présentant la valeur start.

Important

Lorsque les sessions sont activées sur une file d’attente ou un abonnement, les applications clientes ne peuvent plus envoyer/recevoir de messages réguliers. Les clients doivent envoyer des messages dans le cadre d’une session en définissant l’ID de session et reçus en acceptant la session. Les clients peuvent toujours voir une file d’attente ou un abonnement sur lequel les sessions sont activées. Consultez la navigation des messages.

Les API pour les sessions existent sur les clients de file d’attente et d’abonnement. Il existe deux façons de recevoir des sessions et des messages : le modèle impératif, où vous contrôlez manuellement quand et comment les messages sont reçus et le modèle basé sur le gestionnaire, ce qui simplifie les choses en gérant automatiquement la boucle et le traitement des messages.

Pour obtenir des exemples, utilisez des liens dans la section Exemples .

Fonctionnalités de session

Les sessions fournissent une démultiplexation simultanée des flux de messages entrelacés tout en préservant et garantissant la livraison ordonnée.

Diagramme montrant comment la fonctionnalité Sessions conserve une livraison ordonnée.

Un client crée un récepteur de session pour accepter une session. Lorsque le client accepte et démarre une session, le client conserve un verrou exclusif sur tous les messages ayant l’ID de session de cette session dans la file d’attente ou dans l’abonnement. Il détient des verrous exclusifs sur tous les messages avec l'ID de session qui arrivent plus tard.

Le verrou est libéré lorsque vous appelez des méthodes de fermeture sur le récepteur ou lorsque le verrou expire. Il existe également des méthodes sur le récepteur pour renouveler les verrous. Au lieu de cela, vous pouvez utiliser la fonctionnalité de renouvellement automatique de verrou où vous pouvez spécifier la durée pendant laquelle vous souhaitez continuer à renouveler le verrou. Le verrou de session doit être traité comme un verrou exclusif sur un fichier, ce qui signifie que l’application doit fermer la session dès qu’elle n’en a plus besoin et/ou ne s’attend pas à d’autres messages.

Lorsque plusieurs destinataires simultanés extraient des données de la file d’attente, les messages appartenant à une session spécifique sont envoyés au destinataire concerné qui détient actuellement le verrouillage pour cette session. Avec cette opération, un flux de messages entrelacés dans une file d’attente ou un abonnement est correctement démultiplexé vers différents récepteurs et ces récepteurs peuvent également être hébergés sur différents ordinateurs clients, car la gestion des verrous se produit du côté du service, à l’intérieur de Service Bus.

L’illustration précédente montre trois récepteurs de session simultanés. Une session avec SessionId = 4 n’a pas de client actif, propriétaire, ce qui signifie qu’aucun message n’est remis à partir de cette session spécifique. Une session agit de plusieurs manières comme une sous-file d’attente.

Le verrou de session détenu par le récepteur de session est un terme générique pour les verrous de message utilisés par le mode de validation du peek-lock. Un seul récepteur peut avoir un verrou sur une session. Un destinataire peut avoir de nombreux messages en cours d'acheminement, mais les messages sont reçus dans l'ordre. L’abandon d’un message entraîne le retour du même message avec l’opération de réception suivante.

État de session de message

Lorsque les flux de travail sont traités dans des systèmes cloud à haute échelle et à haute disponibilité, le gestionnaire de flux de travail associé à une session particulière doit être en mesure de récupérer après des défaillances inattendues et peut reprendre le travail partiellement terminé sur un autre processus ou ordinateur à partir duquel le travail a commencé.

La fonctionnalité d’état de session permet une annotation définie par l’application d’une session de message à l’intérieur du répartiteur, afin que l’état de traitement enregistré par rapport à cette session devienne instantanément disponible lorsque la session est acquise par un nouveau processeur.

Du point de vue service Bus, l’état de session de message est un objet binaire opaque qui peut contenir des données de la taille d’un message, qui est de 256 Ko pour Service Bus Standard et de 100 Mo pour Service Bus Premium. L’état de traitement relatif à une session peut être conservé à l’intérieur de l’état de session, ou l’état de session peut pointer vers un emplacement de stockage ou un enregistrement de base de données qui contient ces informations.

Les méthodes de gestion de l’état de session, SetStateet GetState, sont disponibles sur l’objet récepteur de session. Une session qui n’avait auparavant pas d’état de session retourne une référence Null pour GetState. L’état de session défini précédemment peut être effacé en passant null à la SetState méthode sur le récepteur.

L’état de session reste tant qu’il n’est pas effacé (renvoyant null), même si tous les messages d’une session sont consommés.

L’état de session conservé dans une file d’attente ou dans un abonnement compte pour le quota de stockage de cette entité. Une fois que l'application a terminé une session, il est donc recommandé que l'application nettoie son état conservé afin d’éviter les coûts de gestion externe.

Impact du nombre de livraisons

La définition du nombre de remises par message dans le contexte des sessions varie légèrement de la définition en l’absence de sessions. Voici un tableau récapitulant quand le nombre de livraisons est incrémenté.

Scénario Est-ce que le nombre de livraisons du message est incrémenté ?
La session est acceptée, mais le verrou de session expire (en raison du délai d’expiration) Oui
La session est acceptée, les messages de la session ne sont pas terminés (même s’ils sont verrouillés) et la session est fermée Non
La session est acceptée, les messages sont terminés, puis la session est explicitement fermée N/A (il s’agit du flux standard. Ici, les messages sont supprimés de la session)

Modèle requête-réponse

Le modèle de demande-réponse est un modèle d’intégration bien établi qui permet à l’application expéditeur d’envoyer une demande et permet au destinataire de renvoyer correctement une réponse à l’application expéditeur. Ce modèle a généralement besoin d’une file d’attente ou d’une rubrique de courte durée pour que l’application envoie des réponses. Dans ce scénario, les sessions fournissent une solution alternative simple avec une sémantique comparable.

Plusieurs applications peuvent envoyer leurs demandes à une file d’attente de requêtes unique, avec un paramètre d’en-tête spécifique défini pour identifier de manière unique l’application expéditeur. L’application réceptrice peut traiter les demandes entrantes dans la file d’attente et envoyer des réponses sur la file d’attente activée pour la session, en définissant l’ID de session sur l’identificateur unique envoyé par l’expéditeur sur le message de demande. L’application qui a envoyé la requête peut ensuite recevoir des messages sur l’ID de session spécifique et traiter correctement les réponses.

Remarque

L’application qui envoie les demandes initiales doit connaître l’ID de session et l’utiliser pour accepter la session afin que la session sur laquelle elle attend la réponse soit verrouillée. Il est judicieux d’utiliser un GUID qui identifie de façon unique l’instance de l’application en tant qu’ID de session. Il ne doit y avoir aucun gestionnaire de session ou un délai d’attente spécifié sur le récepteur de session pour la file d’attente afin de s’assurer que les réponses sont disponibles pour être verrouillées et traitées par des récepteurs spécifiques.

Séquencement et sessions

Le numéro de séquence garantit 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 trois messages dans la file d’attente et deux consommateurs.

  1. Le consommateur 1 récupère le message 1.
  2. Le consommateur 2 récupère le message 2.
  3. Le consommateur 2 termine le traitement du message 2 et récupère le message 3, tandis que le consommateur 1 n’est pas encore terminé avec le traitement du message 1.
  4. Le consommateur 2 termine le traitement du message 3, mais le consommateur 1 n’est toujours pas terminé avec le traitement du message 1.
  5. 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.

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 appartiennent ensemble, qui peuvent être le message 1, 4 et 8 dans un ensemble, et 2, 3 et 6 dans un autre ensemble.

Expiration du message

Pour les files d’attente ou les abonnements aux rubriques activés pour la session, les messages sont verrouillés au niveau de la session. Si la durée de vie (TTL) de l’un des messages expire, tous les messages liés à cette session sont soit supprimés, soit marqués comme lettres mortes en fonction du paramètre de lettres mortes activé lors de l'expiration des messages sur l’entité. En d’autres termes, s’il existe un seul message dans la session qui a dépassé le TTL, tous les messages de la session expirent. Les messages expirent uniquement s’il existe un écouteur actif. Pour plus d’informations, consultez Expiration du message.

Échantillons

Vous pouvez activer les sessions de messages lors de la création d’une file d’attente à l’aide du portail Azure, de PowerShell, de l’interface CLI, du modèle Resource Manager, du .NET, de Java, de Python et de JavaScript. Pour plus d’informations, consultez Activer les sessions de messages.

Essayez les exemples dans le langage de votre choix pour explorer les fonctionnalités d’Azure Service Bus.

Contenu connexe