导出 (0) 打印
全部展开

Files d'attente, rubriques et abonnements Service Bus

更新时间: 2014年4月

注:本页面内容可能不完全适用中国大陆地区运营的 Windows Azure服务。如要了解不同地区 Windows Azure 服务的差异, 请参考本网站.

Microsoft Azure Service Bus prend en charge un ensemble de technologies basées sur le cloud et de middleware orienté messages incluant une mise en file d'attente fiable des messages et une messagerie de publication et d'abonnement durable.Ces fonctionnalités de messagerie « répartie » peuvent être vues comme asynchrones ou comme des fonctionnalités de messagerie découplée qui prennent en charge la publication et l'abonnement, le découplage temporel et les scénarios d'équilibrage de charge à l'aide de la fabrique de messagerie Service Bus.La communication découplée présente de nombreux avantages ; par exemple, les clients et les serveurs peuvent se connecter selon leurs besoins et effectuer leurs opérations de manière asynchrone.

Trois modèles de messagerie constituent l'essentiel des fonctionnalités de messagerie répartie dans Service Bus, à savoir les files d'attente, les rubriques/abonnements et les règles/actions

Files d'attente

Les files d'attente proposent une remise de messages de type Premier entré, premier sorti (FIFO) à un ou plusieurs consommateurs concurrents.Autrement dit, les messages sont généralement reçus et traités par les récepteurs dans l'ordre temporel dans lequel ils ont été ajoutés à la file d'attente, et chaque message est reçu et traité par un seul consommateur de messages.Un grand avantage de l'utilisation de files d'attente est de réaliser le « découplage temporel » des composants de l'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.De plus, le producteur n'a pas à attendre une réponse du consommateur pour pouvoir continuer à traiter et à envoyer des messages.

Un avantage associé est le « nivellement de charge », qui permet aux producteurs et aux consommateurs d'envoyer et de recevoir des messages à différents débits.Dans beaucoup d'applications, la charge du système change avec le temps ; cependant, le temps de traitement requis pour chaque unité de travail est généralement constant.Se servir d'une file d'attente en tant qu'intermédiaire entre les producteurs et les consommateurs de messages signifie que l'application de consommation doit être simplement configurée de manière à pouvoir gérer la charge moyenne au lieu de la charge de pointe.La profondeur de la file d'attente augmente et diminue en fonction de la charge entrante.Cela économise de l'argent par rapport au volume d'infrastructure nécessaire pour desservir la charge de l'application.Lorsque la charge augmente, des processus de travail peuvent être ajoutés pour lire les messages de la file d'attente.Chaque message est traité par un seul processus de travail.De plus, cet équilibrage de la charge basé sur l’extraction permet une utilisation optimale des ordinateurs de travail, même s'ils ont différentes capacités de traitement, puisqu'ils extraient les messages à leur propre débit maximal.Ce modèle est souvent nommé « consommateur concurrent ».

L'utilisation de files d'attente pour servir d'intermédiaires entre les producteurs et les consommateurs de messages fournit un couplage souple inhérent entre les composants.Comme les producteurs et les consommateurs ne sont pas conscients les uns des autres, un consommateur peut être mis à niveau sans que cela ait de l'effet sur le producteur.

La création d'une file d'attente s'effectue en plusieurs étapes.Les opérations de gestion pour les entités de messagerie Service Bus (files d'attente et rubriques) sont effectuées via la classe Microsoft.ServiceBus.NamespaceManager, qui est générée en fournissant l'adresse de base de l'espace de noms Service Bus et les informations d'identification de l'utilisateur. NamespaceManager fournit une méthode pour créer, énumérer et supprimer les entités de messagerie.Après la création d'un objet Microsoft.ServiceBus.TokenProvider à partir du nom d'émetteur et de la clé partagée, et d'un objet de gestion de l'服务命名空间, vous pouvez utiliser la méthode Microsoft.ServiceBus.NamespaceManager.CreateQueue(Microsoft.ServiceBus.Messaging.QueueDescription) pour créer la file d'attente.Par exemple :

// Create management credentials
TokenProvider credentials = TokenProvider.CreateSharedSecretTokenProvider(IssuerName, IssuerKey);
// Create namespace client
namespaceManager namespaceClient = new namespaceManager(ServiceBusEnvironment.CreateServiceUri("sb", ServiceNamespace, string.Empty), credentials);

Vous pouvez alors créer un objet file d'attente et une fabrique de messagerie avec l'URI Service Bus en tant qu'argument.Par exemple :

QueueDescription myQueue;
myQueue = namespaceClient.CreateQueue("TestQueue");
MessagingFactory factory = MessagingFactory.Create(ServiceBusEnvironment.CreateServiceUri("sb", ServiceNamespace, string.Empty), credentials); 
QueueClient myQueueClient = factory.CreateQueueClient("TestQueue");

Vous pouvez alors envoyer des messages vers la file d’attente.Par exemple, si vous avez une liste de messages répartis nommée MessageList, le code est similaire au code suivant :

for (int count = 0; count < 6; count++)
{
    var issue = MessageList[count];
    issue.Label = issue.Properties["IssueTitle"].ToString();
    myQueueClient.Send(issue);
}

Vous pouvez recevoir des messages de la file d'attente, comme suit :

while ((message = myQueueClient.Receive(new TimeSpan(hours: 0, minutes: 0, seconds: 5))) != null)
    {
        Console.WriteLine(string.Format("Message received: {0}, {1}, {2}", message.SequenceNumber, message.Label, message.MessageId));
        message.Complete();

        Console.WriteLine("Processing message (sleeping...)");
        Thread.Sleep(1000);
    }

En mode ReceiveAndDelete, l'opération de réception est au coup à coup, c'est-à-dire que lorsque le Service Bus reçoit la requête, il marque le message comme étant utilisé et le renvoie à l'application. Le mode ReceiveAndDelete est le modèle le plus simple et fonctionne au mieux pour les scénarios dans lesquels l'application peut tolérer de ne pas traiter un message en cas d'échec.Pour comprendre ceci, imaginez un scénario dans lequel le consommateur émet la requête de réception, puis se bloque avant de la traiter.Puisque le Service Bus marque le message comme étant utilisé, quand l'application redémarrera et recommencera à utiliser des messages, elle aura manqué le message qui était utilisé avant le blocage.

Dans le mode PeekLock, l'opération de réception se déroule en deux étapes, ce qui rend possible la prise en charge d'applications qui ne peuvent pas tolérer les messages manquants.Lorsque le Service Bus reçoit la requête, il découvre le message suivant à utiliser, le verrouille pour éviter que d'autres consommateurs le reçoivent, puis le renvoie à l'application.Après que l'application a fini le traitement du message (ou qu'elle l'a stocké de manière fiable pour un traitement ultérieur), elle effectue la deuxième étape du processus de réception en appelant Microsoft.ServiceBus.Messaging.BrokeredMessage.Complete sur le message reçu.Lorsque le Service Bus voit Complete, il marque le message comme étant utilisé.

Si l'application ne peut pas traiter le message pour une raison ou une autre, elle peut appeler la méthode Microsoft.ServiceBus.Messaging.BrokeredMessage.Abandon sur le message reçu (au lieu de Complete).Cela permet au Service Bus de déverrouiller le message et de le rendre de nouveau disponible à la réception, soit pour le même consommateur, soit pour un autre consommateur simultané.Deuxièmement, il y a un délai d'expiration associé au verrouillage et, si l'application échoue dans le traitement du message avant l'expiration du délai de verrouillage (par exemple, si l'application se bloque), le Service Bus déverrouille le message et le rend de nouveau disponible à la réception.

Notez que, si l'application se bloque après le traitement du message, mais avant l'émission de la requête Complete, le message est de nouveau remis à l'application à son redémarrage.Ce traitement est souvent qualifié de Au moins une fois, c'est-à-dire que chaque message est traité au moins une fois. Toutefois, dans certaines circonstances, le même message peut être remis plus d'une fois.Si le scénario ne peut pas tolérer un traitement dupliqué, une logique supplémentaire est nécessaire dans l'application pour détecter les doublons, ce qui peut être obtenu grâce à la propriété MessageId du message qui reste constante lors des tentatives de remise.C'est ce que l'on appelle un traitement Exactement une fois.

Pour plus d'informations et pour obtenir un exemple de création et d'envoi de messages vers et à partir d'une file d'attente, reportez-vous au Service Bus 中转消息传递 .NET 教程.

Rubriques et abonnements

À l'inverse des files d'attente, dans lesquelles chaque message est traité par un seul consommateur, les rubriques et les abonnements fournissent une forme de communication un-à-plusieurs dans un modèle de « publication/abonnement ».Utile pour s'adapter à un très grand nombre de destinataires, chaque message publié est rendu disponible pour chaque abonnement inscrit à la rubrique.Les messages sont envoyés à une rubrique et remis à un ou plusieurs abonnements associés, en fonction des règles de filtrage qui peuvent être définies par abonnement.Les abonnements peuvent utiliser des filtres supplémentaires pour restreindre les messages qu'ils souhaitent recevoir.Les messages sont envoyés à une rubrique de la même manière qu'ils sont envoyés à une file d'attente, mais ils ne sont pas reçus directement de la rubrique.À la place, ils sont reçus des abonnements.Un abonnement de rubrique ressemble à une file d'attente virtuelle qui reçoit les copies des messages qui sont envoyés à la rubrique.Les messages sont reçus d'un abonnement de la même manière qu'ils sont reçus d'une file d'attente.

Pour comparaison, la fonctionnalité d'envoi de messages d'une file d'attente mappe directement vers une rubrique, et sa fonctionnalité de réception de messages mappe vers un abonnement.Entre autres, cela signifie que les abonnements prennent en charge les mêmes modèles que ceux décrits plus tôt dans cette section par rapport aux files d'attente :consommateur simultané, découplage temporel, nivellement de la charge et équilibrage de la charge.

La création d'une rubrique est un processus similaire à la création d'une file d'attente, comme l'illustre l'exemple de la section précédente.Créez l'URI de service, puis utilisez la classe NamespaceManager pour créer le client d'espace de noms.Vous pouvez alors créer une rubrique à l'aide de la méthode Microsoft.ServiceBus.NamespaceManager.CreateTopic(System.String).Par exemple :

TopicDescription dataCollectionTopic = namespaceClient.CreateTopic("DataCollectionTopic");

Ensuite, ajoutez les abonnements comme vous le souhaitez :

SubscriptionDescription myAgentSubscription = namespaceClient.CreateSubscription(myTopic.Path, "Inventory");
SubscriptionDescription myAuditSubscription = namespaceClient.CreateSubscription(myTopic.Path, "Dashboard");

Vous pouvez alors créer un client de rubrique.Par exemple :

MessagingFactory factory = MessagingFactory.Create(serviceUri, tokenProvider);
TopicClient myTopicClient = factory.CreateTopicClient(myTopic.Path)

À l'aide de l'expéditeur du message, vous pouvez échanger des messages avec la rubrique, comme indiqué dans la section précédente.Par exemple :

foreach (BrokeredMessage message in messageList)
{
    myTopicClient.Send(message);
    Console.WriteLine(
    string.Format("Message sent: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
}

Comme pour les files d'attente, les messages sont reçus à partir d'un abonnement à l'aide d'un objet SubscriptionClient et non d'un objet QueueClient.Créez le client d'abonnement, en transmettant le nom de la rubrique, le nom de l'abonnement et (éventuellement) le mode de réception comme paramètres.Par exemple, avec l'abonnement Inventaire :

// Create the subscription client
MessagingFactory factory = MessagingFactory.Create(serviceUri, tokenProvider); 

SubscriptionClient agentSubscriptionClient = factory.CreateSubscriptionClient("IssueTrackingTopic", "Inventory", ReceiveMode.PeekLock);
SubscriptionClient auditSubscriptionClient = factory.CreateSubscriptionClient("IssueTrackingTopic", "Dashboard", ReceiveMode.ReceiveAndDelete); 

while ((message = agentSubscriptionClient.Receive(TimeSpan.FromSeconds(5))) != null)
{
    Console.WriteLine("\nReceiving message from Inventory...");
    Console.WriteLine(string.Format("Message received: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
    message.Complete();
}          

// Create a receiver using ReceiveAndDelete mode
while ((message = auditSubscriptionClient.Receive(TimeSpan.FromSeconds(5))) != null)
{
    Console.WriteLine("\nReceiving message from Dashboard...");
    Console.WriteLine(string.Format("Message received: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
}

Important重要提示
Comme spécifié dans la rubrique 如何:将服务发布到 Service Bus 注册表, Microsoft.ServiceBus.ServiceRegistrySettings permet d'indiquer si vous souhaitez que le service soit détectable dans Service Bus.Si votre service est privé, seuls les utilisateurs qui connaissent l'URI spécifique peuvent se connecter.S'il est public, n'importe qui peut parcourir la hiérarchie du Service Bus et trouver votre écouteur.Cependant, les files d'attente, les rubriques et les abonnements ne peuvent pas être exposés via le Registre de service.

Règles et actions

Dans de nombreux scénarios, les messages qui ont des caractéristiques spécifiques doivent être traités de manière spécifique.Pour activer ceci, vous pouvez configurer les abonnements de manière à ce qu'ils trouvent les messages qui ont les propriétés souhaitées, puis à ce qu'ils apportent 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.Ceci est effectué à l'aide de filtres d'abonnement.De telles modifications sont appelées Actions de filtre.Lors de la création d'un abonnement, vous pouvez fournir une expression de filtre qui agit sur les propriétés du message, à la fois les propriétés système (par exemple, Étiquette) et les propriétés de l'application, telles que StoreName dans l'exemple précédent.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.

À l'aide de l'exemple précédent, pour filtrer les messages provenant uniquement de Store1, vous créez l'abonnement Tableau de bord comme suit :

namespaceManager.CreateSubscription("IssueTrackingTopic", "Dashboard", new SqlFilter("StoreName = 'Store1'"));

Avec ce filtre d'abonnement, seuls les messages qui ont la propriété StoreName définie sur Store1 sont copiés dans la file d'attente virtuelle pour l'abonnement Tableau de bord.

Pour plus d'informations concernant les valeurs de filtre 有关 possibles, consultez la documentation sur les classes Microsoft.ServiceBus.Messaging.SqlFilter et Microsoft.ServiceBus.Messaging.SqlRuleAction.Consultez également Brokered Messaging: Advanced Filters.

另请参见

社区附加资源

添加
显示:
© 2014 Microsoft