Partager via

Files d’attente, rubriques et abonnements Service Bus

  • Article

Azure Service Bus prend en charge la mise en file d'attente des messages et la messagerie durable de type publier/s’abonner. Les entités de messagerie qui constituent l’essentiel des capacités de messagerie dans Service Bus sont les files d’attente, les rubriques et abonnements.

Important

Si vous débutez avec Azure Service Bus, lisez Qu’est-ce qu’Azure Service Bus ? avant de passer par cet article.

Files d’attente

Les files d’attente permettent la livraison de messages sur le principe du premier entré, premier sorti (FIFO) à un ou plusieurs destinataires concurrents. Autrement dit, les messages sont en général reçus et traités par les destinataires dans l’ordre dans lequel ils ont été ajoutés à la file d’attente. Chaque message est reçu et traité par un seul consommateur de message.

Image montrant le fonctionnement des files d’attente de service.

Un des principaux avantages de l’utilisation des files d’attente consiste à réaliser le découplage temporel des composants d’application. En d’autres termes, les producteurs (expéditeurs) et les consommateurs (récepteurs) n’ont pas besoin d’envoyer et de recevoir des messages en même temps, car les messages sont stockés durablement dans la file d’attente. En outre, le producteur n’a pas à attendre de réponse du consommateur pour continuer de traiter et d’envoyer d’autres messages.

Un des avantages associés est le nivellement de charge, qui permet aux producteurs et aux consommateurs d’envoyer et de recevoir des messages à des vitesses différentes. Dans de nombreuses applications, la charge système varie au fil du temps. Toutefois, le temps de traitement requis pour chaque unité de travail est généralement constant. L’ajout d’une file d’attente entre les producteurs et les consommateurs des messages fait que l’application de destination doit être en mesure de gérer seulement une charge moyenne, plutôt que la charge de travail maximale. La file d’attente s’allonge et se raccourcit en fonction de la charge entrante. Cette fonctionnalité permet de faire des économies concernant les infrastructures nécessaires pour faire face à la charge de travail de l’application. À mesure que la charge augmente, d’autres processus de travail peuvent être ajoutés pour lire les éléments de la file d’attente. Chaque message est traité par un seul des processus de travail. De plus, cet équilibrage de la charge basé sur le tirage (pull) permet d’optimiser l’utilisation des ordinateurs de travail, même si les ordinateurs de travail dotés d’une puissance de traitement tirent les messages au maximum de leur capacité. Ce modèle est souvent appelé modèle consommateur concurrent.

L’utilisation de files d’attente comme intermédiaire entre les producteurs et les consommateurs de message fournit un couplage souple inhérent entre les composants. Producteurs et consommateurs étant indépendants les uns des autres, il est possible de mettre à niveau un consommateur sans que cela affecte le producteur.

Créer des files d’attente

Vous pouvez créer des files d’attente à l’aide de l’une des options suivantes :

Ensuite, envoyez et recevez des messages à l’aide de clients écrits dans des langages de programmation, notamment les suivants :

Modes de réception

Vous pouvez spécifier deux modes différents dans lesquels les consommateurs peuvent recevoir des messages de Service Bus.

  • Réception et suppression. Dans ce mode, lorsque Service Bus reçoit la requête du consommateur, il marque le message comme étant consommé et le retourne à l’application du consommateur. Ce mode est le modèle le plus simple. Il fonctionne mieux pour les scénarios dans lesquels l’application peut tolérer l’absence de traitement d’un message en cas d’échec. Pour comprendre ce comportement, imaginez un scénario selon lequel le consommateur émet la demande de réception et subit un incident avant de la traiter. Comme Service Bus marque le message comme étant consommé, l’application commence à consommer des messages lors du redémarrage. Elle manquera le message qu’elle a consommé avant l’incident. Ce processus est souvent appelé le traitement Maximum une fois.
  • Verrouillage du passage furtif. Dans ce mode, la réception devient une opération en deux étapes, qui autorise une prise en charge des applications ne pouvant pas se permettre de manquer des messages.

    1. Le service recherche le message suivant à consommer, le verrouille pour veiller à ce que d’autres consommateurs ne le reçoivent pas, puis retourne le message à l’application.

    2. Une fois que l’application a terminé le traitement du message, elle demande à Service Bus d’effectuer la deuxième étape du processus de réception. Le service, par conséquent, marque le message comme étant consommé.

      Si l’application ne parvient pas à traiter le message pour une raison quelconque, elle peut demander au service Service Bus d’abandonner le message. Service Bus déverrouille le message et le met à disposition pour être à nouveau reçu, soit par le même consommateur, soit par un consommateur concurrent. De plus, un délai d’attente est associé au verrou. Si l’application ne parvient pas à traiter le message dans le temps imparti, Service Bus déverrouille le message et le rend à nouveau disponible en réception.

      Si l’application subit un incident après le traitement du message, mais avant de demander au service Service Bus de clôturer le message, celui-ci livre à nouveau le message à l’application lorsqu’elle redémarre. Ce processus est souvent appelé le traitement Au moins une fois. Autrement dit, chaque message est traité au moins une fois. Toutefois, dans certaines situations, le même message peut être à nouveau remis. Si votre scénario ne peut pas tolérer le traitement en double, ajoutez une logique supplémentaire dans votre application pour détecter les doublons. Pour plus d’informations, consultez Détection des doublons, appelée processus juste une fois.

      Notes

      Pour plus d’informations sur ces deux modes, consultez la rubrique sur le Règlement des opérations de réception.

Rubriques et abonnements

Une file d’attente autorise le traitement d’un message par un seul consommateur. Contrairement aux files d’attente, les rubriques et les abonnements fournissent une forme de communication de type un-à-plusieurs dans un modèle de publication et abonnement. Cela est utile pour la mise à l’échelle d’un grand nombre de destinataires. Chaque message publié est mis à disposition de tous les abonnements inscrits auprès de la rubrique. L’éditeur envoie un message à une rubrique et un ou plusieurs abonnés reçoivent une copie du message.

Image montrant une rubrique Service Bus avec trois abonnements.

Les éditeurs envoient des messages à une rubrique de la même façon qu’ils envoient des messages à une file d’attente. Toutefois, les consommateurs ne reçoivent pas de messages directement de la rubrique. Au lieu de cela, les consommateurs reçoivent des messages des abonnements de la rubrique. Un abonnement à une rubrique ressemble à une file d’attente virtuelle recevant des copies des messages envoyés à la rubrique. Les consommateurs reçoivent des messages d’un abonnement de la même manière qu’ils reçoivent des messages d’une file d’attente. La fonctionnalité d’envoi de messages d’une file d’attente mappe directement sur une rubrique, et sa fonctionnalité de réception de messages est mappé sur un abonnement. Cette fonctionnalité implique, entre autres, que les abonnements prennent en charge les modèles décrits plus haut dans cette section concernant les files d’attente : consommateurs simultanés, découplage temporel, nivellement et équilibrage de charge.

Les abonnés peuvent définir les messages qu’ils veulent recevoir d’une rubrique. Ces messages sont spécifiés sous la forme d’une ou de plusieurs règles d’abonnement nommées. Chaque règle se compose d’une condition de filtre qui sélectionne des messages spécifiques et contient éventuellement une action qui annote le message sélectionné. Par défaut, un abonnement à une rubrique reçoit tous les messages envoyés à la rubrique. L’abonnement a une règle initiale par défaut avec un filtre « true » (vrai) qui permet à tous les messages d’être sélectionnés dans l’abonnement. La règle par défaut n’a pas action associée. Vous pouvez définir des filtres avec des règles et des actions sur un abonnement pour que l’abonnement reçoive seulement un sous-ensemble des messages envoyés à la rubrique.

Pour plus d’informations sur les filtres, consultez Filtres et actions.

Créer des rubriques et des abonnements

La création d’une rubrique est similaire à la création d’une file d’attente, comme le montre la section précédente. Vous pouvez créer des rubriques et des abonnements à l’aide de l’une des options suivantes :

Ensuite, envoyez des messages à une rubrique et recevez des messages d’abonnements à l’aide de clients écrits dans des langages de programmation, notamment les suivants :

Règles et actions

Dans de nombreux scénarios, les messages ayant des caractéristiques spécifiques doivent être traités différemment. Pour mettre en place ce traitement, vous pouvez configurer des abonnements de sorte qu’ils recherchent les messages présentant les propriétés souhaitées, puis apporter certaines modifications à ces propriétés. Bien que les abonnements Service Bus voient tous les messages envoyés à la rubrique, vous pouvez seulement copier un sous-ensemble de ces messages dans la file d’attente d’abonnement virtuelle. On utilise pour cela des filtres d’abonnement. Ces modifications sont appelées actions de filtrage. Lorsqu’un abonnement est créé, vous pouvez fournir une expression de filtre qui opère sur les propriétés du message. Les propriétés peuvent être à la fois des propriétés système (par exemple, Étiquette) et des propriétés d’application personnalisées (par exemple, StoreName). L’expression de filtre SQL est facultative dans ce cas. Sans expression de filtre SQL, toute action de filtre définie sur un abonnement est effectuée sur tous les messages de cet abonnement.

Pour obtenir un exemple pratique complet, consultez l'exemple TopicFilters sur GitHub. Pour en savoir plus sur les filtres, consultez Actions et filtres de rubrique.

Entités Java message service (JMS) 2.0

Les entités suivantes sont accessibles via l’API Java Message Service (JMS) 2.0.

  • Files d’attente temporaires
  • Rubriques temporaires
  • Abonnements durables partagés
  • Abonnements durables non partagés
  • Abonnements non durables partagés
  • Abonnements non durables non partagés

En savoir plus sur les entités JMS 2.0 et sur la façon de les utiliser.

Entités Express

Les entités rapides ont été créées pour des scénarios de débit élevé et de latence réduite. Avec des entités rapides, si un message est envoyé à une file d'attente ou à une rubrique, il n'est pas immédiatement stocké dans le magasin de messagerie. Au lieu de cela, le message est initialement mis en mémoire cache. Les messages qui restent dans l’entité sont écrits dans le magasin de messages après un certain délai, après quoi ils sont protégés contre la perte en raison d’une panne.

Dans les entités régulières, n’importe quelle opération d’exécution (comme Send, Complete, Abandon, Deadletter) est d’abord conservée dans le magasin, et uniquement après cela, l’opération est signalée au client comme ayant réussi. Dans les entités rapides, une opération d’exécution est d’abord signalée au client comme ayant réussi et après cela, elle est écrite en différé dans le magasin. Par conséquent, en cas de redémarrage d’une machine ou lorsqu’un problème matériel se produit, certaines opérations d’exécution signalées peuvent ne pas être conservées du tout. Cela signifie que le client obtient une latence plus faible et un débit plus élevé avec des entités rapides, au détriment d’une perte de données potentielle et/ou d’un nouvel envoi des messages.

En outre, au fil du temps, de nombreuses optimisations ont été effectuées dans Service Bus, ce qui signifie que les avantages en termes de débit et de latence des entités rapides sont actuellement minimes. De plus, le niveau Premium de Service Bus ne prend pas en charge les entités rapides. En raison de cela, il n’est actuellement pas recommandé d’utiliser cette fonctionnalité.

Étapes suivantes

Essayez les exemples dans la langue de votre choix :

Pour obtenir des exemples qui utilisent les anciennes bibliothèques clientes .NET et Java, utilisez les liens suivants :

Le 30 septembre 2026, nous retirerons les bibliothèques WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus et com.microsoft.azure.servicebus du kit de développement logiciel (SDK) Azure Service Bus, qui ne sont pas conformes aux directives du kit de développement logiciel (SDK) Azure. Nous mettrons également fin à la prise en charge du protocole SBMP. Vous ne pourrez donc plus utiliser ce protocole après le 30 septembre 2026. Migrez vers les dernières bibliothèques du kit de développement logiciel (SDK) Azure, qui offre des correctifs de sécurité critiques et des fonctionnalités améliorées, avant cette date.

Bien que les anciennes bibliothèques puissent toujours être utilisées au-delà du 30 septembre 2026, elles ne seront plus prises en charge officiellement et mises à jour par Microsoft. Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.