Découvrir les files d’attente, rubriques et abonnements Service Bus
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, les règles et les actions.
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. Les messages étant stockés durablement dans la file d’attente, les producteurs (expéditeurs) et les consommateurs (destinataires) n’ont pas besoin de traiter les messages simultanément.
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.
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.
Vous pouvez créer des files d’attente en utilisant le portail Azure, PowerShell, l’interface CLI ou les modèles Resource Manager. Ensuite, envoyez et recevez des messages à l’aide de clients écrits en C#, Java, Python et JavaScript.
Modes de réception
Vous pouvez spécifier deux modes différents dans lesquels Service Bus reçoit des messages : Recevoir et supprimer ou Passage furtif.
Recevoir et supprimer
Dans ce mode, quand Service Bus reçoit la demande du consommateur, il marque le message comme étant consommé et le renvoie à l’application 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. Par exemple, imaginez un scénario dans 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. Il manque le message qu’elle a consommé avant le plantage.
Afficher-verrouiller
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.
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.
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.
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.
Les abonnements peuvent utiliser plus de filtres pour limiter les messages qu’ils souhaitent recevoir. 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.
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 uniquement 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.