Prérécupérer les messages Azure Service Bus

  • Article

Lorsque vous activez la fonctionnalité Prérécupérer pour l’un des clients Service Bus officiels, le destinataire acquiert plus de messages que ce que l’application a demandé initialement, jusqu’à concurrence du nombre de prérécupérations spécifié. Au fur et à mesure que les messages sont renvoyés à l’application, le client acquiert d’autres messages en arrière-plan afin de remplir la mémoire tampon de pré-récupération (prefetch).

Activer la pré-récupération

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.

Définissez la propriété du nombre de pré-récupération sur les objets ServiceBusReceiver et ServiceBusProcessor.

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é. Ils déclenchent l’horloge de délai d’expiration du verrouillage. 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 (qui est soumise aux variations d’horloge entre l’horloge du répartiteur et celle de la machine locale).

Si le verrouillage d’un message est arrivé à expiration, l’application doit ignorer le message, et ne doit passer aucun appel d’API sur le message. Si le message n’est pas arrivé à expiration, mais que son expiration est imminente, il est possible de renouveler et de prolonger le verrouillage avec une autre période de verrouillage par défaut. 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. Il se peut que le message soit 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 n’est généralement pas utilisable pendant l’arrivée à expiration des messages, les messages sont prérécupérés de façon répétée, mais ne sont en fait jamais remis dans un état exploitable (correctement verrouillés), et sont finalement déplacés vers la file d’attente de lettres mortes une fois que le nombre de remises maximal a été atteint.

Si une application abandonne explicitement un message, le message peut être à nouveau 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 peut recevoir des messages dans le désordre. Par exemple, l’application peut recevoir un message avec l’ID 2, puis un message avec l’ID 1 (qui a été abandonné plus tôt) de 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, le délai d’expiration du verrouillage ne doit pas être si long que les messages risquent de dépasser leur durée de vie maximum lorsqu’ils sont accidentellement abandonnés, ce qui nécessite d’attendre l’arrivée à expiration du verrouillage des messages pour que ces derniers puissent faire l’objet d’une nouvelle tentative de remise.

Étapes suivantes

Essayez les exemples dans le langage de votre choix pour explorer les fonctionnalités d’Azure Service Bus.

Exemples pour les anciennes bibliothèques de client .NET et Java :

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 bibliothèques du kit de développement logiciel (SDK) Azure les plus récentes, qui offrent 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 ni mises à jour par Microsoft. Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.