Dubblettidentifiering

  • Artikel

Om ett program misslyckas på grund av ett allvarligt fel omedelbart efter att det har skickat ett meddelande, och den omstartade programinstansen felaktigt anser att den tidigare meddelandeleveransen inte inträffade, orsakar en efterföljande sändning samma meddelande att visas i systemet två gånger.

Det är också möjligt att ett fel på klient- eller nätverksnivå inträffar en stund tidigare och att ett skickat meddelande checkas in i kön, där bekräftelsen inte returneras till klienten. Det här scenariot lämnar klienten osäker på resultatet av sändningsåtgärden.

Dubblettidentifiering tar bort tvivel från dessa situationer genom att aktivera avsändaren skicka samma meddelande igen, och kön eller ämnet tar bort eventuella duplicerade kopior.

Kommentar

Den grundläggande nivån för Service Bus stöder inte dubblettidentifiering. Standard- och Premium-nivåerna stöder dubblettidentifiering. Skillnader mellan dessa nivåer finns i Service Bus-priser.

Så här fungerar det

Genom att aktivera dubblettidentifiering kan du hålla reda på det programkontrollerade MessageId som skickas till en kö eller ett ämne under en angiven tidsperiod. Om ett nytt meddelande skickas med MessageId som loggades under tidsfönstret rapporteras meddelandet som godkänt (sändningsåtgärden lyckas), men det nyligen skickade meddelandet ignoreras omedelbart och tas bort. Inga andra delar av meddelandet än MessageId beaktas.

Programkontroll av identifieraren är nödvändig, eftersom endast det gör att programmet kan koppla MessageId till en affärsprocesskontext som kan återskapas förutsägbart när ett fel inträffar.

För en affärsprocess där flera meddelanden skickas under hantering av viss programkontext MessageId kan det vara en sammansatt av kontextidentifieraren på programnivå, till exempel ett inköpsordernummer och ämnet för meddelandet, till exempel 12345.2017/betalning.

MessageId Kan alltid vara vissa GUID, men förankring av identifieraren till affärsprocessen ger förutsägbar repeterbarhet, vilket önskas för att använda dubblettidentifieringsfunktionen effektivt.

Viktigt!

  • När partitionering är aktiveratMessageId+PartitionKey används för att fastställa unikhet. När sessioner är aktiverade måste partitionsnyckeln och sessions-ID:t vara desamma.
  • När partitionering är inaktiverat (standard) används endast MessageId för att fastställa unikhet.
  • Information om SessionId, PartitionKeyoch MessageId, finns i Använda partitionsnycklar.

Kommentar

Schemalagda meddelanden ingår i dubblettidentifiering. Om du skickar ett schemalagt meddelande och sedan skickar ett duplicerat icke-schemalagt meddelande tas därför det icke-schemalagda meddelandet bort. På samma sätt tas det schemalagda meddelandet bort om du skickar ett icke-schemalagt meddelande och sedan ett duplicerat schemalagt meddelande.

Fönsterstorlek för duplicerad identifiering

Förutom att bara aktivera dubblettidentifiering kan du också konfigurera storleken på tidsfönstret för dubbletidentifieringshistoriken under vilken meddelande-ID:er behålls. Det här värdet är som standard 10 minuter för köer och ämnen, med ett minsta värde på 20 sekunder till maximalt värde på 7 dagar.

Aktivering av dubblettidentifiering och fönstrets storlek påverkar direkt kön (och ämnets) dataflöde, eftersom alla inspelade meddelande-ID:er måste matchas mot den nyligen skickade meddelandeidentifieraren.

Att hålla fönstret litet innebär att färre meddelande-ID:er måste behållas och matchas, och dataflödet påverkas mindre. För entiteter med högt dataflöde som kräver dubblettidentifiering bör du hålla fönstret så litet som möjligt.

Nästa steg

Du kan aktivera duplicerad meddelandeidentifiering med hjälp av Azure-portalen, PowerShell, CLI, Resource Manager-mallen, .NET, Java, Python och JavaScript. Mer information finns i Aktivera identifiering av duplicerade meddelanden.

I scenarier där klientkoden inte kan skicka ett meddelande på nytt med samma MessageId som tidigare är det viktigt att utforma meddelanden som kan bearbetas på ett säkert sätt. Det här blogginlägget om idempotens beskriver olika tekniker för hur du gör det.

Prova exemplen på det språk du väljer för att utforska Azure Service Bus-funktioner.

Se exempel för äldre .NET- och Java-klientbibliotek här:

Den 30 september 2026 drar vi tillbaka Azure Service Bus SDK-biblioteken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus och com.microsoft.azure.servicebus, som inte följer Riktlinjerna för Azure SDK. Vi kommer också att avsluta stödet för SBMP-protokollet, så du kommer inte längre att kunna använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure SDK-biblioteken, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.

Även om de äldre biblioteken fortfarande kan användas efter den 30 september 2026 får de inte längre officiell support och uppdateringar från Microsoft. Mer information finns i meddelandet om supportavgång.