Détection des doublons

  • Article

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, 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.

Notes

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.

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

Le 30 septembre 2026, les bibliothèques WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus et com.microsoft.azure.servicebus du SDK Azure Service Bus qui ne sont pas conformes aux directives du SDK Azure seront retirées. Le protocole SBMP ne sera plus non plus pris en charge, donc vous ne pourrez plus l’utiliser après le 30 septembre 2026. Avant cette date, effectuez une migration vers les bibliothèques du SDK Azure les plus récentes, qui offrent des correctifs de sécurité critiques et des fonctionnalités améliorées.

Même si les anciennes bibliothèques pourront toujours être utilisées au-delà du 30 septembre 2026, elles ne recevront plus de support officiel ni de mises à jour de Microsoft. Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.