Ordningsföljd och tidsstämplar för meddelanden
Sekvensering och tidsstämpling är två funktioner som alltid är aktiverade på alla Service Bus-entiteter och visar SequenceNumber egenskaperna och EnqueuedTimeUtc för mottagna eller bläddrade meddelanden.
För de fall där den absoluta ordningen på meddelanden är betydande och/eller där en konsument behöver en tillförlitlig unik identifierare för meddelanden stämplar mäklaren meddelanden med ett gapfritt, vilket ökar sekvensnumret i förhållande till kön eller ämnet. För partitionerade entiteter utfärdas sekvensnumret i förhållande till partitionen.
Löpnummer
Värdet SequenceNumber är ett unikt 64-bitars heltal som tilldelats ett meddelande eftersom det accepteras och lagras av asynkron meddelandekö och fungerar som intern identifierare. För partitionerade entiteter återspeglar de översta 16 bitarna partitionsidentifieraren. Sekvensnummer rullar över till noll när intervallet 64-bitars eller 48-bitars (exklusive 16 bitar för partitionsidentifieraren) är slut.
Sekvensnumret kan vara betrott som en unik identifierare eftersom det tilldelas av en central och neutral auktoritet och inte av klienter. Det representerar också den sanna ankomstordningen och är mer exakt än en tidsstämpel som ett orderkriterium, eftersom tidsstämplar kanske inte har en tillräckligt hög upplösning vid extrema meddelandefrekvenser och kan bli föremål för (dock minimal) klocksnedvridning i situationer där koordinatorägarskapet övergår mellan noder.
Den absoluta ankomstordern är till exempel viktig i affärsscenarier där ett begränsat antal erbjudna varor betjänas enligt principen först till kvarn medan leveranserna varar. konsertbiljettförsäljning är ett exempel.
Tidsstämpel
Tidsstämplingsfunktionen fungerar som en neutral och pålitlig auktoritet som korrekt fångar upp UTC-tiden för ett meddelandes ankomst, vilket återspeglas i EnqueuedTimeUtc egenskapen. Värdet är användbart om ett affärsscenario beror på tidsgränser, till exempel om ett arbetsobjekt skickades ett visst datum före midnatt, men bearbetningen ligger långt efter kvarvarande kö.
Kommentar
Sekvensnummer i sig garanterar köordningen och extraktorordningen för meddelanden, men inte bearbetningsordningen, vilket kräver sessioner.
Anta att det finns 5 meddelanden i kön och 2 konsumenter. Konsument 1 hämtar meddelande 1. Konsument 2 hämtar meddelande 2. Konsument 2 slutför bearbetningen av meddelande 2 och hämtar meddelande 3 medan konsument 1 inte är klar med bearbetning av meddelande 1 ännu. Konsument 2 slutför bearbetningen av meddelande 3 men konsument 1 är fortfarande inte klar med bearbetning av meddelande 1 ännu. Slutligen slutför konsument 1 bearbetningsmeddelande 1. Därför bearbetas meddelandena i den här ordningen: meddelande 2, meddelande 3 och meddelande 1. Om du behöver meddelande 1, 2 och 3 för att bearbetas i ordning måste du använda sessioner.
Så om meddelanden bara behöver hämtas i ordning behöver du inte använda sessioner. Om meddelanden behöver bearbetas i ordning använder du sessioner. Samma sessions-ID ska anges för meddelanden som hör ihop, vilket kan vara meddelande 1, 4 och 8 i en uppsättning, och 2, 3 och 6 i en annan uppsättning.
Mer information finns i Service Bus-meddelandesessioner.
Schemalagda meddelanden
Du kan skicka meddelanden till en kö eller ett ämne för fördröjd bearbetning, till exempel för att schemalägga ett jobb som ska bli tillgänglig för bearbetning av ett system vid en viss tidpunkt. Den här funktionen har en tillförlitlig distribuerad tidsbaserad schemaläggare.
Schemalagda meddelanden materialiseras inte i kön förrän den definierade kötiden. Innan den tiden kan schemalagda meddelanden avbrytas. Annullering tar bort meddelandet.
Du kan schemalägga meddelanden med någon av våra klienter på två sätt:
- Använd det vanliga skicka-API:et
ScheduledEnqueueTimeUtc, men ange egenskapen för meddelandet innan du skickar det. - Använd API:et för schemameddelande, skicka både det normala meddelandet och den schemalagda tiden. API:et returnerar det schemalagda meddelandets
SequenceNumber, som du senare kan använda för att avbryta det schemalagda meddelandet om det behövs.
Schemalagda meddelanden och deras sekvensnummer kan också identifieras med hjälp av meddelandebläddring.
För SequenceNumber ett schemalagt meddelande är endast giltigt medan meddelandet är i schemalagt tillstånd. När meddelandet övergår till aktivt tillstånd läggs meddelandet till i kön som om det hade sparats i det aktuella ögonblicket, vilket inkluderar tilldelning av en ny SequenceNumber.
Eftersom funktionen är förankrad i enskilda meddelanden och meddelanden bara kan anges en gång stöder Service Bus inte återkommande scheman för meddelanden.
Kommentar
- Meddelandekåtgång innebär inte att meddelandet skickas samtidigt. Den kommer att skickas, men den faktiska sändningstiden beror på köns arbetsbelastning och dess tillstånd.
- På grund av prestandaöverväganden är aktivering och annullering av schemalagda meddelanden oberoende åtgärder utan ömsesidig låsning. Om ett meddelande håller på att aktiveras och avbryts samtidigt kommer aktiveringsprocessen inte att ångras och meddelandet aktiveras fortfarande. Dessutom kan detta potentiellt leda till ett negativt antal schemalagda meddelanden. För att minimera det här konkurrenstillståndet rekommenderar vi att du undviker att schemalägga aktiverings- och annulleringsåtgärder i nära följd.
Använda schemalagda meddelanden med arbetsflöden
Det är vanligt att se långvariga affärsarbetsflöden som har en explicit tidskomponent för dem, till exempel 5-minuters timeouter för 2-faktorautentisering, timslånga tidsgränser för användare som bekräftar sin e-postadress och komponenter för flera dagar, vecka eller månad i domäner som bank och försäkring.
Dessa arbetsflöden startas ofta av bearbetningen av vissa meddelanden, som sedan lagrar vissa tillstånd och sedan schemalägger ett meddelande för att fortsätta processen vid ett senare tillfälle. Ramverk som NServiceBus och MassTransit gör det enklare att integrera alla dessa element tillsammans.
Relaterat innehåll
Mer information om Service Bus-meddelanden finns i följande avsnitt: