Dubblettidentifiering

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

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

Dubblettidentifiering tar bort tveksamheterna från dessa situationer genom att avsändaren skickar samma meddelande igen, och kön eller ämnet tar bort eventuella dubbletter.

Så här fungerar det

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

Programkontroll av identifieraren är viktig, eftersom det bara gör att programmet kan koppla MessageId till en affärsprocesskontext från vilken det förutsägbart kan rekonstrueras när ett fel inträffar.

För en affärsprocess där flera meddelanden skickas under hantering av viss programkontext kan MessageId vara en sammansatt kontextidentifierare på programnivå, till exempel ett inköpsordernummer och meddelandets ämne, till exempel 12345.2017/payment.

MessageId kan alltid vara ett GUID, men att fästa identifieraren för affärsprocessen ger förutsägbar repeterbarhet, vilket önskas för att använda funktionen för dubblettidentifiering effektivt.

Fönsterstorlek för dubblettidentifiering

Förutom att bara aktivera dubblettidentifiering kan du även konfigurera storleken på tidsperioden för dubblettidentifieringshistoriken då meddelande-ID:n bevaras. 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 det högsta värdet på 7 dagar.

Om du aktiverar dubblettidentifiering och fönstrets storlek påverkas köns (och ämnets) dataflöde direkt, eftersom alla registrerade meddelande-ID:n måste matchas mot den nyligen skickade meddelandeidentifieraren.

Att hålla fönstret litet innebär att färre meddelande-ID:n 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 se till att fönstret är så litet som möjligt.

Nästa steg

Du kan aktivera identifiering av duplicerade meddelanden med Azure Portal, PowerShell, CLI, Resource Manager mall, .NET, Java, Python och JavaScript. Mer information finns i Aktivera identifiering av dubblettmeddelanden.

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.

• Azure Service Bus exempel på klientbibliotek för .NET (senaste)
• Azure Service Bus klientbiblioteksexempel för Java (senaste)
• Azure Service Bus klientbiblioteksexempel för Python
• Azure Service Bus klientbiblioteksexempel för JavaScript
• Azure Service Bus klientbiblioteksexempel för TypeScript

Hitta exempel för äldre .NET- och Java-klientbibliotek nedan:

• Azure Service Bus exempel på klientbibliotek för .NET (äldre)
• Azure Service Bus klientbiblioteksexempel för Java (äldre)