Delen via

Duplicaatdetectie

  • Artikel

Als een toepassing mislukt vanwege een fatale fout direct na het verzenden van een bericht en het opnieuw gestarte toepassingsexemplaren ten onrechte denkt dat de bezorging van het vorige bericht niet is opgetreden, zorgt een volgende verzending ervoor dat hetzelfde bericht tweemaal in het systeem wordt weergegeven.

Het is ook mogelijk dat een fout op client- of netwerkniveau een moment eerder optreedt en dat een verzonden bericht in de wachtrij wordt doorgevoerd, waarbij de bevestiging niet is geretourneerd naar de client. In dit scenario blijft de client twijfelachtig over het resultaat van de verzendbewerking.

Dubbele detectie haalt de twijfel uit deze situaties door de afzender hetzelfde bericht opnieuw te laten verzenden en de wachtrij of het onderwerp verwijdert eventuele dubbele kopieën.

Notitie

De Basic-laag van Service Bus biedt geen ondersteuning voor dubbele detectie. De lagen Standard en Premium bieden ondersteuning voor duplicaatdetectie. Zie Service Bus-prijzen voor verschillen tussen deze lagen.

Hoe het werkt

Het inschakelen van detectie van duplicaten helpt bij het bijhouden van de door de toepassing beheerde MessageId van alle berichten die tijdens een opgegeven periode naar een wachtrij of onderwerp worden verzonden. Als er een nieuw bericht wordt verzonden met MessageId dat is geregistreerd tijdens het tijdvenster, wordt het bericht gerapporteerd als geaccepteerd (de verzendbewerking slaagt), maar wordt het zojuist verzonden bericht direct genegeerd en verwijderd. Er worden geen andere onderdelen van het bericht dan de MessageId in overweging genomen.

Toepassingsbeheer van de id is essentieel, omdat alleen de toepassing de MessageId toepassing kan koppelen aan een bedrijfsprocescontext waaruit deze voorspelbaar kan worden gereconstrueerd wanneer er een fout optreedt.

Voor een bedrijfsproces waarin meerdere berichten worden verzonden tijdens het verwerken van een toepassingscontext, kan dit MessageId een samengestelde context-id op toepassingsniveau zijn, zoals een inkoopordernummer en het onderwerp van het bericht, bijvoorbeeld 12345.2017/betaling.

Het MessageId kan altijd een GUID zijn, maar het verankeren van de id aan het bedrijfsproces levert voorspelbare herhaalbaarheid op, wat gewenst is voor het effectief gebruik van de functie voor dubbele detectie.

Belangrijk

  • Wanneer partitionering is ingeschakeld, MessageId+PartitionKey wordt gebruikt om de uniekheid te bepalen. Wanneer sessies zijn ingeschakeld, moeten de partitiesleutel en sessie-id hetzelfde zijn.
  • Wanneer partitionering is uitgeschakeld (standaard), wordt alleen MessageId gebruikt om de uniekheid te bepalen.
  • Zie Het gebruik van partitiesleutels voor meer informatie overSessionId, PartitionKeyen.MessageId
  • Bij het gebruik van partitionering en het verzenden van batches berichten, moet u ervoor zorgen dat ze geen partitie-identificatie-eigenschappen bevatten. Aangezien ontdubbeling afhankelijk is van het expliciet instellen van bericht-id's om de uniekheid te bepalen, wordt het niet aanbevolen om ontdubbeling en batchverwerking samen met partitionering te gebruiken.

Notitie

Geplande berichten worden opgenomen in dubbele detectie. Als u een gepland bericht verzendt en vervolgens een dubbel niet-gepland bericht verzendt, wordt het niet-geplande bericht verwijderd. Als u een niet-gepland bericht verzendt en vervolgens een dubbel gepland bericht, wordt het geplande bericht verwijderd.

Grootte van venster duplicaatdetectie

Naast het inschakelen van dubbele detectie, kunt u ook de grootte van het tijdvenster voor de detectiegeschiedenis van dubbele detectie configureren waarin bericht-id's worden bewaard. Deze waarde wordt standaard ingesteld op 10 minuten voor wachtrijen en onderwerpen, met een minimumwaarde van 20 seconden tot een maximumwaarde van 7 dagen.

Het inschakelen van dubbele detectie en de grootte van het venster heeft rechtstreeks invloed op de doorvoer van de wachtrij (en het onderwerp), omdat alle opgenomen bericht-id's moeten worden vergeleken met de zojuist verzonden bericht-id.

Als u het venster klein houdt, betekent dit dat er minder bericht-id's moeten worden bewaard en overeenkomen, en dat de doorvoer minder wordt beïnvloed. Voor entiteiten met hoge doorvoer waarvoor dubbele detectie is vereist, moet u het venster zo klein mogelijk houden.

Volgende stappen

U kunt dubbele berichtdetectie inschakelen met behulp van Azure Portal, PowerShell, CLI, Resource Manager-sjabloon, .NET, Java, Python en JavaScript. Zie Dubbele berichtdetectie inschakelen voor meer informatie.

In scenario's waarin clientcode een bericht niet opnieuw kan indienen met dezelfde MessageId als voorheen, is het belangrijk om berichten te ontwerpen die veilig opnieuw kunnen worden verwerkt. In dit blogbericht over idempotentie worden verschillende technieken beschreven om dat te doen.

Probeer de voorbeelden in de taal van uw keuze om Azure Service Bus-functies te verkennen.

Bekijk hier voorbeelden voor de oudere .NET- en Java-clientbibliotheken:

Op 30 september 2026 gaan we de Azure Service Bus SDK-bibliotheken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus en com.microsoft.azure.servicebus buiten gebruik stellen, die niet voldoen aan de Azure SDK-richtlijnen. We beëindigen ook de ondersteuning van het SBMP-protocol, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure SDK-bibliotheken, die vóór die datum essentiële beveiligingsupdates en verbeterde mogelijkheden bieden.

Hoewel de oudere bibliotheken nog steeds meer dan 30 september 2026 kunnen worden gebruikt, ontvangen ze geen officiële ondersteuning en updates meer van Microsoft. Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.