Prérécupérer les messages Azure Service Bus
La fonctionnalité de prérécupération récupère les messages en arrière-plan dans une mémoire tampon de prérécupération locale jusqu’au nombre de prérécupérations. Les messages sont servis à partir de la mémoire tampon. Comme cela se produit, de l’espace se libère dans la mémoire tampon, et le récepteur effectuera une prérécupération supplémentaire en arrière-plan.
Pour activer la fonctionnalité Prérécupérer, définissez le nombre de prérécupérations du client de file d’attente ou d’abonnement sur un nombre supérieur à zéro. La définition de cette propriété sur la valeur zéro désactive la prérécupération. S’il existe des messages dans la mémoire tampon de prérécupération après la désactivation de la fonctionnalité, l’application reçoit d’abord ces messages de la mémoire tampon, puis accède au service.
Définir la propriété du nombre de prérécupérations sur les objets ServiceBusReceiverOptions et ServiceBusProcessorOptions.
Notes
Le Kit de développement logiciel (SDK) JavaScript ne prend pas en charge la fonctionnalité Prérécupérer.
Tant que les messages sont disponibles dans la mémoire tampon de prérécupération, tous les appels de réception ultérieurs sont immédiatement satisfaits à partir de la mémoire tampon. La mémoire tampon est réapprovisionnée en arrière-plan à mesure que de l’espace est disponible. Si plus aucun message n’est prêt à être remis, l’opération de réception vide la mémoire tampon, puis attend ou se bloque, comme attendu.
Pourquoi la prérécupération n’est-elle pas l’option par défaut ?
La prérécupération accélère le flux de messages en faisant en sorte qu’un message soit immédiatement récupérable localement avant que l’application le demande. Ce gain de débit résulte d’un compromis que l’auteur de l’application doit effectuer de manière explicite.
Lorsque vous utilisez le mode receive and delete, tous les messages qui sont acquis dans la mémoire tampon de pré-récupération ne sont plus disponibles dans la file d’attente. Les messages restent uniquement dans la mémoire tampon de prérécupération jusqu’à ce qu’ils soient reçus dans l’application. Si l’application se termine avant d’avoir reçu les messages, ces derniers sont irrécupérables (perdus).
Lorsque vous utilisez le mode de réception peek lock, les messages récupérés dans la mémoire tampon de pré récupération sont acquis dans la mémoire tampon dans un état verrouillé. Le minuteur de verrouillage commence à partir du moment où le message est prérécupéré dans la mémoire tampon. Si la mémoire tampon de prérécupération est volumineuse et que le traitement est si long que le verrouillage des messages arrive à expiration pendant que les messages résident dans la mémoire tampon de prérécupération ou même pendant que l’application traite les messages, l’application peut faire face à certains événements déroutants. Il est possible que l’application acquière un message dont le verrouillage est arrivé à expiration ou doit l’être prochainement. Dans ce cas, l’application peut commencer à traiter le message, puis se trouver dans l’impossibilité d’achever le traitement à cause de l’expiration du verrouillage. L’application peut vérifier la propriété LockedUntilUtc, mais gardez à l’esprit qu’il existe un décalage d’horloge entre le broker et l’horloge de l’ordinateur local.
Si le verrouillage arrive silencieusement à expiration dans la mémoire tampon de prérécupération, le message est considéré comme abandonné et redevient récupérable à partir de la file d’attente. Ensuite, le message sera de nouveau récupéré dans la mémoire tampon de prérécupération et placé à la fin. Si la mémoire tampon de prérécupération ne peut généralement pas être traité pendant l’expiration du message, les messages sont prérécupérés de manière répétée, mais jamais effectivement livrés dans un état utilisable (validement verrouillé), et sont finalement déplacés vers la file d’attente de lettres mortes une fois le nombre maximum de livraisons dépassé.
Si une application abandonne explicitement un message, celui-ci pourrait de nouveau être disponible pour récupération depuis la file d’attente. Lorsque la pré-récupération est activée, le message est extrait à nouveau dans la mémoire tampon de pré-récupération et placé à la fin. Comme les messages de la mémoire tampon de prérécupération sont vidés dans l’ordre du premier entré premier sorti (FIFO), l’application pourrait recevoir des messages dans le désordre. Par exemple, l’application pourrait recevoir un message avec l’ID 2, puis un message avec l’ID 1 (qui avait été abandonné plus tôt) depuis la mémoire tampon.
Si vous exigez un haut niveau de fiabilité pour le traitement des messages et que ce traitement demande des efforts et un temps considérables, nous vous recommandons d’utiliser la fonctionnalité Prérécupérer avec prudence ou de ne pas l’utiliser du tout. Si vous avez besoin d’un haut débit et que votre processus de traitement des messages est généralement peu coûteux, la prérécupération entraîne des avantages substantiels en matière de débit.
Le nombre maximal de prérécupérations et la durée de verrouillage configurés sur la file d’attente ou l’abonnement doivent être équilibrés, de sorte que le délai d’expiration du verrouillage dépasse au moins le temps de traitement des messages prévu cumulé pour la taille maximale de la mémoire tampon de prérécupération, plus un message. Dans le même temps, il ne faut pas que la durée du verrouillage soit trop longue pour que les messages puissent dépasser leur durée de vie maximale pendant qu’ils sont verrouillés. Si c’est le cas, ils seraient supprimés s’ils n’ont pas pu être terminés au moment où ils ont été prérécupérés.
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.