Files d’attente et rubriques partitionnées

Azure Service Bus utilise plusieurs répartiteurs de messages pour traiter les messages et plusieurs magasins de messagerie pour stocker des messages. Une file d’attente ou une rubrique conventionnelle est gérée par un répartiteur de messages unique et un magasin de messagerie. Service Bus permet également le partitionnement des files d’attente et des rubriques, ou des entités de messagerie entre plusieurs courtiers de messages et banques de messagerie. Le partitionnement signifie que le débit global d’une entité partitionnée n’est plus limité par les performances d’un seul courtier de messages ou d’une seule banque de messagerie. En outre, une panne temporaire d’un magasin de messagerie ne rend pas une file d’attente ou une rubrique partitionnée indisponible. Les rubriques et les files d’attente partitionnées peuvent contenir toutes les fonctionnalités avancées de Service Bus, comme la prise en charge des transactions et des sessions.

Vous ne pouvez pas modifier l’option de partitionnement sur n’importe quel espace de noms, file d’attente ou rubrique existant. Vous ne pouvez définir l’option que lorsque vous créez l’entité.

Fonctionnement

Chaque file d’attente ou rubrique partitionnée est constituée de plusieurs partitions. Chaque partition est stockée dans une banque de messagerie différente, et gérée par un répartiteur de messages différent. Lorsque vous envoyez un message à une file d’attente ou une rubrique partitionnée, Service Bus affecte le message à l’une des partitions. Service Bus sélectionne la partition de façon aléatoire ou utilise une clé de partition spécifiée par l’expéditeur.

Lorsqu’un client souhaite recevoir un message d’une file d’attente partitionnée ou d’un abonnement à une rubrique partitionnée, Service Bus interroge toutes les partitions pour les messages. Elle retourne le premier message qu’il obtient de l’un des magasins de messagerie vers le récepteur. Service Bus place les autres messages en cache pour les retourner lorsqu’il reçoit plus de requêtes de réception. Un client de réception n’a pas connaissance du partitionnement. Le comportement orienté client d’une file d’attente ou d’un sujet partitionné (par exemple, lecture, achèvement, report, courrier mort, prélecture) est identique au comportement d’une entité normale.

L’opération de lecture sur une entité non partitionnée renvoie toujours le message le plus ancien, mais pas sur une entité partitionnée. Au lieu de cela, elle renvoie le message le plus ancien dans l’une des partitions dont le courtier de messages a répondu en premier. Rien ne garantit que le message retourné est le plus ancien sur toutes les partitions.

Il n’existe aucun coût supplémentaire lors de l’envoi d’un message à, ou lors de la réception d’un message depuis, une file d’attente ou une rubrique partitionnée.

Utilisation de clés de partition

Lorsque vous placez un message dans une file d’attente ou une rubrique partitionnée, Service Bus recherche la présence d’une clé de partition. S’il en trouve une, il sélectionne la partition basée sur cette clé. S’il ne trouve pas de clé de partition, il sélectionne la partition basée sur un algorithme interne.

Utilisation d’une clé de partition

Certains scénarios, tels que les sessions ou les transactions, nécessitent que les messages soient stockés dans une partition spécifique. Tous ces scénarios requièrent l’utilisation d’une clé de partition. Service Bus affecte tous les messages qui utilisent la même clé de partition à la même partition. Si la partition est momentanément indisponible, Service Bus retourne une erreur.

Selon le scénario, différentes propriétés de messages sont utilisées comme clé de partition :

SessionId : si un message a défini la propriété ID de session, Service Bus l’utilise comme clé de partition. De cette façon, le même répartiteur de messages gère tous les messages appartenant à la même session. En utilisant des sessions, Service Bus garantit l’ordre des messages ainsi que la cohérence des états de session.

PartitionKey : si un message a la propriété de clé de partition, mais pas la propriété ID de session définie, Service Bus utilise la valeur de propriété de clé de partition comme clé de partition. Si le message a les deux propriétés d’ID de session et de clé de partition, alors elles doivent être identiques. Si la propriété de clé de partition est définie sur une valeur différente de celle de la propriété d’ID de session, Service Bus retourne une exception d’opération non valide. Utilisez la propriété de clé de partition si un expéditeur envoie des messages transactionnels non sensibles à la session. La clé de partition garantit que le même répartiteur de messagerie gère tous les messages envoyés dans une transaction.

MessageId : si vous créez la file d’attente ou la rubrique avec la fonctionnalité de détection dupliquée et que vous ne définissez pas les propriétés de l’ID de session ou de la clé de partition, la valeur de la propriété ID de message sert de clé de partition. (Les bibliothèques clientes Microsoft attribuent automatiquement un ID de message si l’application d’envoi ne le fait pas.) Dans ce cas, le même répartiteur de messages gère toutes les copies du même message. Cet ID permet à Service Bus de détecter et d’éliminer les messages en double. Si la fonctionnalité de détection des doublons n’est pas activée, Service Bus ne considère pas la propriété d’ID de message comme clé de partition.

Non utilisation d'une clé de partition

Si vous ne spécifiez pas de clé de partition, Service Bus distribue les messages de façon cyclique à toutes les partitions de la file d’attente ou du sujet partitionné. Si la partition choisie n’est pas disponible, Service Bus attribue le message à une partition différente. De cette façon, l'opération d'envoi réussit malgré l'indisponibilité temporaire d'un stockage de messagerie. Toutefois, vous n’obtenez pas l’ordre garanti fourni par une clé de partition.

Pour une discussion plus approfondie sur le compromis entre la disponibilité (pas de clé de partition) et la cohérence (en utilisant une clé de partition), consultez Disponibilité et cohérence dans Event Hubs. À l’exception de l’ID de partition qui n’est pas exposé aux utilisateurs, ces informations s’appliquent également aux entités Service Bus partitionnées.

Afin de donner à Service Bus assez de temps pour placer le message en file d’attente dans une partition différente, la valeur de délai d’attente spécifiée par le client qui envoie le message doit être supérieure à 15 secondes. La valeur par défaut de 60 secondes est recommandée.

Une clé de partition « épingle » un message à une partition spécifique. Si la banque de messagerie qui contient cette partition n’est pas disponible, Service Bus retourne une erreur. En l’absence de clé de partition, Service Bus peut choisir une partition différente et l’opération réussit. Par conséquent, ne fournissez pas de clé de partition, sauf si nécessaire.

Rubriques avancées

Utiliser des transactions avec des entités partitionnées

Les messages que vous envoyez dans le cadre d’une transaction doivent spécifier une clé de partition. La clé peut correspondre à l’une des propriétés suivantes : ID de session, clé de partition ou ID de message. Tous les messages que vous envoyez dans le cadre de la même transaction doivent spécifier la même clé de partition. Si vous essayez d’envoyer un message sans une clé de partition dans une transaction, Service Bus renvoie une exception d’opération non valide. Si vous essayez d’envoyer plusieurs messages dans la même transaction avec des clés de partition différentes, Service Bus renvoie une exception d’opération non valide. Par exemple :

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    ServiceBusMessage msg = new ServiceBusMessage("This is a message");
    msg.PartitionKey = "myPartitionKey";
    await sender.SendMessageAsync(msg); 
    ts.Complete();
}
committableTransaction.Commit();

Si vous définissez l’une des propriétés qui servent de clé de partition, Service Bus épingle le message à une partition spécifique. Ce comportement se produit si vous utilisez ou non une transaction. Ne spécifiez pas de clé de partition si ce n’est pas nécessaire.

Utiliser des transactions dans des sessions avec des entités partitionnées

Pour envoyer un message transactionnel à une rubrique ou une file d’attente prenant en charge la session, définissez la propriété ID de session sur le message. Si vous spécifiez la propriété de clé de partition, elle doit être identique à la propriété ID de session. Si ces propriétés diffèrent, Service Bus renvoie une exception d’opération non valide.

Contrairement aux files d'attente ou aux sujets réguliers (non partitionnées), vous ne pouvez pas utiliser une transaction unique pour envoyer plusieurs messages à différentes sessions. Si vous tentez cette opération, Service Bus retourne une exception d’opération non valide. Par exemple :

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    ServiceBusMessage msg = new ServiceBusMessage("This is a message");
    msg.SessionId = "mySession";
    await sender.SendMessageAsync(msg); 
    ts.Complete();
}
committableTransaction.Commit();

Transfert automatique des messages avec des entités partitionnées

Service Bus prend en charge le transfert automatique des messages à partir de, vers ou entre les entités partitionnées. Vous pouvez activer cette fonctionnalité lors de la création ou de la mise à jour des files d’attente et abonnements. Pour plus d’informations, consultez Activer le transfert de messages. Si le message spécifie une clé de partition (ID de session, clé de partition ou ID de message), cette clé de partition est utilisée pour l’entité de destination.

Considérations et recommandations

• Fonctionnalités de cohérence élevée : si une entité utilise des fonctionnalités telles que des sessions, une détection en double ou un contrôle explicite de la clé de partitionnement, les opérations de messagerie sont toujours acheminées vers une partition spécifique. Si le trafic d’une des partitions est élevé, ou si le magasin sous-jacent est défectueux, ces opérations échouent et la disponibilité s’en trouve réduite. Dans l’ensemble, la cohérence est encore beaucoup plus élevée que les entités non partitionées. Seul un sous-ensemble du trafic rencontre des problèmes, contrairement à tout le trafic. Pour plus d’informations, consultez cette discussion sur la disponibilité et la cohérence.
• Gestion : les opérations, comme la création, la mise à jour et la suppression, doivent être exécutées sur toutes les partitions de l’entité. Si une partition est défectueuse, l’échec de ces opérations peut en résulter. Pour l’opération Get, des informations, telles que le nombre de messages, doivent être agrégées à partir de toutes les partitions. Si une partition est défectueuse, l’état de disponibilité de l’entité est signalé comme étant limité.
• Scénarios de message à faible volume : dans ce cas, surtout lorsque vous utilisez le protocole HTTP, vous devez peut-être effectuer plusieurs opérations de réception afin d’obtenir tous les messages. Pour les demandes de réception, le serveur frontal effectue une réception sur toutes les partitions et met en cache toutes les réponses qu’il reçoit. Une demande de réception suivante sur la même connexion bénéficie de cette mise en cache et des latences de réception sont inférieures. Toutefois, si vous disposez de plusieurs connexions ou si vous utilisez HTTP, une nouvelle connexion est établie pour chaque demande. Par conséquent, il n’y a aucune garantie qu’elle atterrit sur le même nœud. Si tous les messages existants sont verrouillés et mis en cache sur un autre serveur frontal, l’opération de réception renvoie la valeur null. Les messages peuvent arriver à expiration et vous pouvez les recevoir à nouveau. La persistance du protocole HTTP est recommandée. Lors de l’utilisation d’un partitionnement dans des scénarios de faible volume, les opérations de réception peuvent prendre plus de temps que prévu. Par conséquent, n’utilisez pas le partitionnement dans ces scénarios. Supprimez toutes les entités partitionnées, puis recréez-les avec le partitionnement désactivé pour améliorer les performances.
• Parcourir/Afficher l’aperçu des messages  : cette opération ne renvoie pas toujours le nombre de messages demandé. Deux raisons courantes expliquent ce comportement. L’une des raisons est que la taille agrégée de la collection de messages dépasse la taille maximale. Autre raison, dans les files d’attente ou rubriques partitionnées, une partition peut ne pas avoir suffisamment de messages pour terminer le nombre de messages demandé. En général, si une application souhaite afficher ou parcourir un nombre spécifique de messages, elle doit appeler l’opération d’aperçu à plusieurs reprises jusqu’à ce qu’elle obtienne ce nombre de messages, ou il n’y a plus de messages à afficher. Pour plus d’informations, y compris des exemples de code, consultez Parcours des messages.

Limites des entités partitionnées

Actuellement, Service Bus impose les limitations suivantes sur les files d’attente et sujets partitionnés :

• Les rubriques et files d’attente partitionnées ne prennent pas en charge l’envoi de messages appartenant à des sessions différentes dans une transaction unique.
• Service Bus permet actuellement un maximum de 100 files d’attente ou sujets partitionnés par espace de noms pour les niveaux de base et standard. Chaque file d’attente ou rubrique partitionnée est comptabilisée dans le quota de 10 000 entités par espace de noms.

Étapes suivantes

Vous pouvez activer le partitionnement en utilisant le portail Azure, PowerShell, l’interface CLI, un modèle Resource Manager, .NET, Java, Python et JavaScript. Pour plus d’informations, consultez Activer le partitionnement (De base/Standard).

Pour en savoir plus sur les concepts fondamentaux de la spécification de messagerie AMQP (Advanced Message Queuing Protocol) 1.0, consultez le guide du protocole AMQP 1.0.