Détection dupliquée dans Azure Service Bus

Si une application échoue en raison d’une erreur irrécupérable immédiatement après l’envoi d’un message et que l’instance de l’application redémarrée croit par erreur que la remise de message précédente n’a pas eu lieu, un envoi ultérieur entraîne l’affichage du même message dans le système deux fois.

Il est également possible qu'une erreur se produise au niveau du client ou du réseau un moment plus tôt, et qu'un message envoyé soit placé dans la file d'attente, sans que l'accusé de réception soit retourné au client. Dans ce scénario, le client ne connait pas avec certitude le résultat de l’opération d’envoi.

La détection dupliquée élimine le doute de ces situations en permettant à l’expéditeur de renvoyer le même message, et la file d’attente ou la rubrique ignore toutes les copies dupliquées.

Fonctionnement

Remarque

Le niveau De base de Service Bus ne prend pas en charge la détection des doublons. Les niveaux Standard et Premium prennent en charge la détection des doublons. Pour connaître les différences entre ces niveaux, voir Tarification de Service Bus.

L’activation de la détection des doublons vous aide à effectuer le suivi du MessageId, contrôlé par l’application, de chaque message envoyé dans une file d’attente ou une rubrique pendant une fenêtre de temps spécifiée. Si un nouveau message est envoyé avec MessageId enregistré pendant la fenêtre de temps, Service Bus signale le message comme accepté (l’opération d’envoi réussit), mais le message qui vient d’être envoyé est ignoré et supprimé instantanément. Excepté le MessageId, aucune autre partie du message n’est prise en compte.

Le contrôle, par l’application, de l’identificateur est essentiel, car il permet à l’application d’associer le MessageId à un contexte de processus métier à partir duquel il peut être reconstruit de façon prévisible lorsqu’une défaillance se produit.

Pour un processus métier dans lequel plusieurs messages sont envoyés durant le traitement d’un contexte d’application, le MessageId peut se composer de l’identificateur de contexte de l’application, par exemple un numéro de bon de commande, et de l’objet du message, par exemple, 12345.2017/paiement.

Le MessageId peut toujours être un GUID, mais l’ancrage de l’identificateur dans le processus métier garantit une répétabilité prévisible, ce qui est important pour utiliser efficacement la fonctionnalité de détection des doublons.

Important

  • Lorsque le partitionnement est activé, MessageId+PartitionKey sert à déterminer l’unicité. Lorsque des sessions sont activées, la clé de partition et l’ID de session doivent être identiques.
  • Lorsque le partitionnement est désactivé (par défaut), seul MessageId sert à déterminer l’unicité.
  • Pour plus d’informations sur SessionId, PartitionKey et MessageId, consultez Utilisation de clés de partition.
  • Lorsque vous utilisez le partitionnement et l’envoi de lots de messages, assurez-vous qu’ils ne contiennent aucune propriété d’identification de partition. Étant donné que la déduplication s’appuie sur la définition explicite des ID de message pour déterminer l’unicité, il n’est pas recommandé d’utiliser la déduplication et le traitement par lots avec le partitionnement.

Remarque

Les messages planifiés sont inclus dans la détection en double. Par conséquent, si vous envoyez un message planifié, puis un message dupliqué non planifié, le message non planifié est supprimé. De même, si vous envoyez un message non planifié, puis un message dupliqué planifié, le message planifié est supprimé.

Taille de la fenêtre de détection des doublons

Outre l’activation de la détection en double, vous pouvez également configurer la taille de la fenêtre de temps de l’historique de détection en double pendant laquelle les ID de message sont conservés. Cette valeur est par défaut de 10 minutes pour les files d’attente et les rubriques, avec une valeur minimale de 20 secondes et une valeur maximale de 7 jours.

L’activation de la détection des doublons et la taille de la fenêtre ont un impact direct sur le débit des files d’attente (et des rubriques), car tous les ID de messages enregistrés doivent être vérifiés par rapport à l’identificateur de message qui vient d’être envoyé.

En maintenant la fenêtre à une petite taille, vous avez moins d’ID de messages à conserver et à vérifier, et l’impact sur le débit reste ainsi limité. Pour les entités à débit élevé qui nécessitent une détection en double, conservez la fenêtre aussi petite que possible.

Étapes suivantes

Vous pouvez activer la détection de messages en double à l’aide du portail Azure, de PowerShell, de l’interface CLI, du modèle de Resource Manager, de .NET, de Java, de Python et de JavaScript. Pour plus d’informations, consultez Activer la détection des messages en doublon.

Dans les scénarios où le code client ne peut pas renvoyer un message avec le même MessageId qu’auparavant, concevez des messages qui peuvent être traités en toute sécurité. Ce billet de blog sur l’idempotence décrit diverses techniques permettant de le faire.

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

Voyez ici des 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 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.

  • Last updated on