Détection des doublons

Si une application échoue en raison d’une erreur irrécupérable immédiatement après avoir envoyé un message, et que l’instance d’application redémarrée considère à tort que le message précédent n’a pas été remis, l’opération d’envoi suivante entraîne le réaffichage du même message dans le système.

Il est également possible qu’une erreur se produise sur le client ou le réseau à un moment antérieur, et qu’un message envoyé soit confirmé dans la file d’attente, avec l’accusé de réception non 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 des doublons lève ce type d’incertitude en permettant à l’expéditeur de renvoyer le même message, et à la file d’attente ou la rubrique d’ignorer les copies en double.

Notes

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.

Fonctionnement

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 un MessageId journalisé pendant la fenêtre de temps, le message est signalé comme étant accepté (réussite de l’opération d’envoi), mais le message qui vient d’être envoyé est instantanément ignoré et supprimé. Excepté le MessageId, aucune autre partie du message n’est prise en compte.

Le contrôle de l’identificateur par l’application est essentiel, car lui seul permet à l’application d’associer l’identificateur MessageId à un contexte de processus métier à partir duquel il peut être reconstruit en cas d’échec.

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.

MessageId peut aussi être un GUID, mais associer l’identificateur au processus métier offre l’avantage de fournir une répétabilité prévisible, ce qui permet de tirer pleinement parti de 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, vous devez vous assurer qu’ils ne contiennent pas de propriétés 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 fois 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 des doublons, vous pouvez également configurer la taille de la fenêtre de temps de l’historique de détection des doublons pour laquelle les ID de message sont conservés. Cette valeur est de 10 minutes par défaut 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 la détection des doublons, essayez de garder la fenêtre aussi petite que possible.

Étapes suivantes

Vous pouvez activer la détection des message en doublon 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 la détection des messages en doublon.

Dans les scénarios où le code client ne peut pas renvoyer de message avec le même MessageId que précédemment, il est important de concevoir des messages qui peuvent être retraité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.

• Exemples de bibliothèque de client Azure Service Bus pour .NET (dernière version)
• Exemples de bibliothèque de client Azure Service Bus pour Java (dernière version)
• Exemples de bibliothèque de client Azure Service Bus pour Python
• Exemples de bibliothèque de client Azure Service Bus pour JavaScript
• Exemples de bibliothèque de client Azure Service Bus pour TypeScript

Voyez ici des exemples pour les anciennes bibliothèques de client .NET et Java :

• Exemples de bibliothèque de client Azure Service Bus pour .NET (version héritée)
• Exemples de bibliothèque de client Azure Service Bus pour Java (version héritée)

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.